I have two goals:

1. All spooky characters which are invisible to authors shall be removed (at least from begin and end), in all cases. I do not want to bother twice if I am using a trim function; I want to shield all applications from all. Since the invisible things are provided without intention on transclusion by authors, I cannot distinct between templates which expect EXHAUSTIVE and templates which can rely on BASIC. If I compare strings I need to get rid of all invisible stuff, always.
2. I want to limit the number of functions. Actually, BOTH is the common case and preserving trailing or heading whitespace is a very rare exception relevant for unnamed parameters only. Named parameters are always trimmed ASCII BOTH. Therefore one function {{#trim:}} is sufficient and rare special cases might use rare special flags.

Attribute lang= should be reserved to human languages, and must not be introduced with another meaning in any task any more.

• It has been a sin to define <source lang="lua">, both conflicting with HTML system.
• The HTML tags and the MW tags create a unique Wikisynta space, and attributes as well as tag names should be consistent.
• lua is ISO 639 code, currently in WMF incubator.

There might be cases where lang= in <pre> will be used by regular text authors for human language, e.g. in multlingual descriptions:

In T361407#11126313, @Krinkle wrote:

While <pre lang may have low adoption in MediaWiki context, it's part of the HTML standard. We could make a breaking change and make <pre lang invoke the syntaxhighlight tag. But would that not inevitably lead to a feature request for how to output <pre lang HTML from wikitext? Setting the language for a piece of content seems a likely use case.

I am opposing to introduce more and more new and cryptic syntax interpretations.

resolved by T151682

Retellling the story of T400212:
The amount of disturbance has exceeded reasonable limits. BETA cannot be used by regulars since huge amounts of IP ranges and networks of regular and innochent providers are blocked. Tools cannot answer any more.

The defense strategy does need a restart, since our tools, services and usage of BETA suffer from significant limitations in productive work.

• robots.txt is pointless. Rather than for a wikipedia no search engine crawler is required here. Do not bother with good behaviour, just bounce back.
• The substring method of Wurgl is sufficient, since it solved the problem.
• If any bot is using a fake agent identification, this particular ID combined with IP range might be used at second stage to avoid collateral damage for humans equipped with that current browser version.

In T400212#11025977, @bd808 wrote:

A robots.txt file is only advisory guidance for well-behaved web bots:

In T400212#11025942, @bd808 wrote:

Possible duplicate of T226688: Block web crawlers from accessing Cloud Services.

Blocking by IP is a good idea for three days while exposed to a DDoS etc., but it is a very bad idea to keep people outside for months and years.

• I have linked a list of UserAgents.
• As long as they identify themselves reasonably, both toolforge.org​ and wmcloud.org should block all known crawlers. Rather than a wikipedia there is nothing to explore for search engines nor archives.

The IP based blocks have a conception of 1999, when a nasty kid is sitting in a roof chamber at a 56k dialup modem. If you block this connection that attack is off.

• Modern attacks use bot nets, and the provider of the unwittingly hijacked end users.
• Crawlers are not supposed to use a static IP over months and years. They might be connected within regular networks and cannot be distinguished by IP from regular humans.
• However, white crawlers do identify themselves by user agent, as proofed above. They are out now, and it works again.

You might find a smarter solution for entire toolforge.org​ and wmcloud.org within this Task.

• The tool has been slowed down by those crawlers, until time-out on all queries.
• This is a much more specific method than blocking IP-ranges.

I am steward of dewiki@BETA, and you have blocked me since March 2025.

• I am using a provider with one million customers in Germany, and 10M end users in Europe. If you block such IP ranges you will hit anybody if you observed that one IP has been used for something bad some months ago.
• I have volatile IP addresses, but you blocked me on all my ranges without interrupt. Pointless to apply for releases every week, then waiting a month for unblocking while already in a different range.

Deutsches Betawiki unerreichbar tells that we cannot develop our templates, modules and gadgets any longer, since all are to be tested before copied into production space.

By default, log/newusers should list manual registration only and might expand to include or filter temp accounts.

On “parser function branches are automatically trimmed”:

• If no exception can be made on parser function swallowing arguments, the partial versions are pointless.
• However, {{#trim:{{{1|}}}}} is progress towards {{#if:trim|{{{1|}}}}} hack and will catch various Unicode chars.

I am implementing wiki stuff on a regular base.

• I do not feel any need to be in line with any current version in the outer world.
• The codes I know are limited to Wiki page transclusion, by #invoke: in the end, providing better outcome than available via wikitext template syntax.
• There is no need to apply this outside of a wikitext page.
• I do not need any code from outside of WMFverse. There might be code examples for a few standard tasks, but they would be ported once into wikitext framework, perhaps with some other solutiuons for unavailable syntax. Much less efforts than upgrading.

There is a doc of 5.1 on my hard disk, and I do know it from cerebral memory.

• A copy should be available at WMF.

In T361407#10626412, @stjn wrote:

Most people are currently typing out things keystroke by keystroke on many wikis

[Citation needed] Please provide a proof.

• People in German Wikipedia acted this way about 2010, but meanwhile our users learnt to use c&p.

Only a very limited number of page authors require <syntaxhighlight>, e.g. those describing new examples in new programming languages etc. Those are technical experts, and if desired they have a wiki user page or text editor page open with frequently needed patterns ready to copy.

• For template documentation we use <syntaxhighlight> on regular base, but we do provide this for new documentation pages via preload page.
• Hint: Once you got an opening <syntaxhighlight> you can gain the closing </syntaxhighlight> by c&p the opener and adding a slash. I did this five seconds ago. To be honest, in this talk I did never type syntaxhighlight but copied it always from Add short-to-type aliases for <syntaxhighlight> and <syntaxhighlight inline> or previous contributions.

Still it is a benefit of five seconds once for the first keystroke-by-keystroke author, but paid over decades by many others consuming minutes every time if they encounter an unknown tag, or search for source text did not match, or bots and scripts failed on replacing.

Oh no, please do not change course every decade.

• German Wikipedia successfully phased out <source> and migrated to <syntaxhighlight> in all namespaces.
• Do not make things more complicated and introduce new aliases.
• Every alias makes things more complicated, more things humans need to keep in mind, patterns to be searched for in pages, patterns to be obeyed by bots and replacing scripts.

Who is typing syntax keystroke by keystroke today? That’s last century style. Nowadays we discovered c&p, source text insertion tools, forms, cheatsheets (cribs) with c&p patterns as individually needed.

• A shortcut is saving five seconds once for one single keystroke-by-keystroke author, but consuming minutes for all following people over decades. Very bad balance.

After some investigations:

• It feels as if the change in preferences form is not stored in database.
• This goes for multiple wikis, even meta:.
• It arrived a few months ago, while older assignments are still present in database (like this one). I guess they could not shift to male/unknown now.
• Translation is not involved.
• Local config is not involved.
• {{gender}} function does work as expected, accessing the unknown property value in database.

However, something is strange with current behaviour, it is not fully consistent. The feeling is like a very delayed cache lag.

• The one and only reliable memorizing of the property is on preferences form, while rendering pages is accessing an outdated value. Mostly, but not always.

If the one and only is the label and headline on this particular tab, the reason might be local in dewiki or by generating the system message at translatewiki.

In T299951#10554828, @Ladsgroup wrote:

That is the code and that will stay. Production data is different. And production data and schema is not considered stable interface explicitly: https://www.mediawiki.org/wiki/Stable_interface_policy

There are some guidelines somewhere how long a breaking change should leave for migration of affected software inside and outside WMF.

• At least the full durance of one major version is requested.
• In this migration period both approaches need to work, with all API queries and data etc.

In T299951#10528855, @doctaxon wrote:

Do you announce before the old tables or columns don't work as usual any more?

In T384926#10501229, @Sophivorus wrote:

unnecessary categories that pollute the categorylinks table

One category per gadget family – how many gadgets do you expect? Do you have any idea how many categories are just now “polluting” English Wikipedia? I never noticed any complaint nor server crash.

This issue is actually solved already by the categories feature.

Thank you for tagging this task with good first task for Wikimedia newcomers!

Recently German Wikipedia introduced a static TOC as temporary solution:

• MediaWiki:pageinfo-header (works in any language if requested by system message)
• Existing page.
• Missing page.

THX & HNY! Recollecting open issues now, found this and I am happy.

I am mourning about the lack of an overall strategy and comprehensive survey about all GUI variants and major elements.

In T381977#10397385, @Ammarpad wrote:

For the input {{#interwikilink:rfc|1{{Zeichen*|#}}appendix-I|1}}. The template actually outputs something like this

{{#interwikilink:rfc|1
    1. appendix-I|1}}

There's a new line at the beginning of the template output because the first character is #, and subsequently that starts a list item. The combination makes an invalid title, although it shouldn't crash this way.

Arrrgh, yeah, sorry, that is the bloody *#;: behaviour of template transclusion.

For smaller of almost 1000 WMF wikis it is hard enough to migrate current pages towards {{#isbn:}} in all pages. While larger wikis do have bots, many small projects have just three or four regular article authors. A global support by bots in foreign wikis will be needed.

• When migrating, all 1000 wikis would need to maintain a template implementation of {{ISBN}} which might collide with existing implementations.
• A {{#isbn:}} is not local, but maintained globally and present everywhere.

Funny. I entirely forgot that I had the same idea four years ago.

I see. Digits before and after, UBA is confused. Perhaps improved one day; an entire block of three groups only (digits letters digits) must not adjust order. There are older and newer versions of UBA, and they might depend on browsers.

If the entire content of a table cell is that parser function, the UBA does not influence anything.

• dir or <bdi> is important if a text fragment is embedded within inline fluent text in other directionality, especially if symbols or digits are direct neighbours of the insertion.
• In this case the symbols might be thrown to the wrong side, since they do not bear any directionality (letters do have a knowledge of themselves whether they are LTR or RTL). UBA might think that they should precede since they are following RTL.
• If the column width is greater than the parser function result, you might want to start an RTL date at the right cell border within a LTR page. However, such style="text-align:right" is not a property of the date, but needs to be applied to the entire table cell as block element.
• If inside the cell the parser function result is a mixture of letters with directionality and things with no directionality, UBA is made to arrange that in the appropriate order (as is).

In T223772#10226924, @IKhitron wrote:

And what about the directionality?

I’d assume most of the time this parser function will be used in contexts that have the given language already set (a table that has table-level lang and dir attributes, running text in that language etc.), so the extra markup would just clutter the HTML code without any benefit. Where do you expect to use a free-standing date, without, for example, a label that tells what on that date happens?

I see. For example, if this date is everything that exists in some table cell.

Please see my conversation above at Sep 10 2024, 03:46.

In T358497#10224220, @Tacsipacsi wrote:

BTW, if there is a transclusion {{ttt|thing|<div class="foo">Content</div>|another|named=value}} this is supposed to be resolved as:

• {{{1}}} → thing
• {{{2}}} → another

However, that was expected as:

• {{{1}}} → thing
• {{{2}}} → <div class="foo">Content</div>
• {{{3}}} → another

The assignment of the third parameter fails.

The Lua table is an object, not a sequence table.

I don’t think so. The very first words of the feature summary are The addition of – that is, it asks for something to be added, not something existing to be changed.

As soon as anything is implemented as proposed, the parameter mapping of all templates and/or modules would change. There is no distinction between those transclusions which shall be evaluated by new syntax and classic syntax.

Exactly. If a Scribunto-powered template makes use of this new feature, it should clearly mention that in the documentation. Processing such – from the parser’s POV broken – parameters should always remain a feature templates can opt into, never the default.

At least this will be an individual solution within one individual template somewhere.

• This task is about a global change of parameter handling by MediaWiki, and the approach is not suitable for all templates in all wikis.
• All assignments of named parameters are treated as if the parameter name and = are part of the value.
• The task description is supposing that all templates in all wikis have only unnamed parameters. This is obviously far from reality.
• The other way around works fine: Avoid unnamed parameters, migrate to named parameters and all = syntax issues are solved (trimming as well). German Wikipedia is migrating since the 2010’s and good new templates won’t introduce them.
• Frequently used templates in German Wikipedia do know which named and unnamed parameters are valid, and an assignment for a 1 by <span style="color:blue">blue</span> would create an unknown parameter name <span style and this will trigger error handling procedures.

The task is not only affecting Lua, but would need to be handled synchronuosly in template programming as well.

• Otherwise there would happen a different behaviour when changing the programming from plain template to Lua and back.
• Authors would need to know whether an implementation is using Lua processing or not, to provide the correct syntax.
• The implementation behind a template is a secret. That means: It is documented how to use a template, and a contract is made which result is expected. Within this contract it is open how to implement this, and the promised target might be reached by changing the programming at any time.

The detection of some = which should be taken as part of parameter value and some which should split parameter name and parameter value is not universal and impossible in general.

• HTML elements (or tags, in this case) are not replaced by the parser before evaluating the parameter value. This differs from MediaWiki tag extensions, where the entire content is hidden and replaced by a placeholder.
• There are too many cases where things like The <span style="color:blue">blue</span> flowers or Einstein’s formula E=mc² will contain = as text.
• Or perhaps the later one E=mc² could mean a parameter name E and a parameter value mc².

The issue is two decades old, and there are two common solutions:

1. Do not use unnamed parameters. If some can be omitted, it becomes cruel to assign the correct values in the right position. Named parameters are self-explaining and avoid misunderstanding the effect of the third assignment.
2. If unnamed parameters, then use 2= if a = might occur within values.

The workaround mentioned in introduction fails as soon a template is really expecting named parameters. It works if and only if all parameters are supposed to be unnamed.

• Typically, you have a few unnamed parameters, if any, for one or two mandatory parameters, followed by many options where the current ones are identified by name.

German Wikipedia is offering all configured minority languages in Central Europe including neighbour countries with German speakers, and migrated population to countries with German language, and further languages in the world with many million speakers.

There is a solution: T359582 (Define alt=- as intended presentational image).

@Ebrahim: FYI

Detected now: rMWc0af446dd0d9caf29cc75dd24ada21a0d742be7f

The major issue on this kind of magic is that they are a nightmare on parsing.

• And hard to understand and teach and describe to authors as well.
• It is blowing up syntax description and make things even more complicated.

@Legoktm: German Wikipedia discontinued to use RFC magic in article space for almost a year now.

In T151682#8967297, @matmarex wrote:

What would this message be used for?

In T355159#10065700, @Bugreporter wrote:

This can be resolved by T328254: Parser function for content model {{#contentmodel:}} plus T151682: Add a new MediaWiki system message as a content header inside #mw-content-text, but this requires an extension (PageNotice).

No idea what will happen finally, but if I am reading only a temporary name might be put into cookie immediately.

I do not think that any Wiki server could solve the problem, at least no trivial patch is meaningful.

I think this suggestion is already in some ticket. Just reminding here.

There came another accessibility issue from users:

• Some have difficulties with distinguishing blue and black.
• Some are not aware that it has an important effect when something in the toolbar is changing from black to blue. They do not know that they triggered unintentionally this mode, and they come to village pump crying that they cannot work any more.

The activated effect should be more obvious than just changing text colour.

• It should be inverted, whether icon only or both icon and text.
• It should be (dark) blue background for the entire field, and white icon and text if active.
• We do a similar thing with ticbox. They are a white square with black or blue borders if not active, and a blue square with white ticmark when activated.
• This change of background colour is very obvious, even if you are less aware or not equipped with best eyes.

An explicit text is better explaining than text markers which have cultural limitations to know such tool in real life nor connecting such unknown device with syntax analysis presentation.

The user magic might be just taken as a reminder.

I learnt that the update is productive now, but user language did not work on BETA ever.

General advice: Append a _ when page name is terminated by . or ) or similar.

• Then, after _, add a space or terminate.
• When the system (many are recognizing and automatically linking URL) is identifying start of URL at http: and termination, they interprete . or ) and more as surrounding punctuation, not part of URL, not included in target.
• If our URL is terminated by _ that one is taken as last character and part of generated link, if a space is following and will break URL identification.
• If any wiki server is receiving _ that is taken as space, and will be stripped since there are no spaces at the end of page names etc.

In T364685#9952638, @Jack_who_built_the_house wrote:

border: 1px solid var( --border-color-base, #a2a9b1 ); also works as advised in T368637#9942128.

I happened to dig out an &exactmatch= meanwhile.

In T368415#9928036, @DLynch wrote:

...as-written, isn't going to change anything in the output for galleries because File:Red eyed tree frog edit2.jpg|A caption and File:Red eyed tree frog edit2.jpg|A caption|alt=A caption produce the same output. If we actually want to suppress the doubling, we currently have to output an empty alt into the gallery definition.

In T368415#9926815, @DLynch wrote:

To summarize: current behavior for the gallery image dialog is that when you add a new image to a gallery we check the "use caption as alternative text" box by default. PerfektesChaos would like that box to not be checked by default.

To clarify: I do not want that the ticbox is not checked by default – no copy of the legend shall be established ever as “starting point” for |alt=, neither by default nor on request.

Yes, the ticbox creating a duplicate of the legend is entirely pointless.

• The legend is already told by screenreader.
• A duplicate of this text, telling the same story a second time, is annoying.
• German Wikipedia is going to run a bot for removing all short |alt= from file transclusion and gallery which are a copy of the legend or media descriptor.

Arrrgh. The language de-AT de-CH de-formal is also involved.

• However, in July 2023 it has been stated that the system message in native project language shall act as fallback if not defined for subtag.
• Therefore de-at de-ch de-formal were deleted in August 2023.

The behaviour according to T229992 or the famous language fallback chain does not work here.

• What is the exact algorithm for fallbacks? Which definition at which level will take precedence and will be defaulted to what when? The manual is not precise enough.
• We did remove many explicit fallbacks de-at de-ch de-formal which worked, but some did not. Why?

In T204201#9915821, @Od1n wrote:

Would it be difficult to bring compatibility with AJAX previews… if ever it's feasible?

It is common practice to use $.extend() for merging defaults and options in a cascading style.

• Code will provide defaults, subsequently combined with site → user → page modification.
• And yes, it is common practice to ignore undefined components since they are – deliberately undefined for this stage!
• Whether this is stated explicitly in any documentation or not, it is common understanding for decades. Undefined components are regarded as not provided. No difference was made ever between undefined or not occurring components; both have the same meaning. Even false may be regarded as refused assignment in certain cases.

The documentation bug on dewiki was just misspelling of the key, but the functionality is known to other people even those who never read such fine manuals.

The error occurred first immediately after distribution, but the code is of 2010.

• Here is the executed code unchanged since 2020 in this particular usage.
• Used more than thousand times every day for every source editing on dewiki.
• You took me already hours to track until this point, time I do not have and resources missing in other issues.

T368102 is the same story, and I guess there are many many more. Enjoy.

While this might be solved technically, the entire task is not a good idea for two reasons:

1. An issue cannot be solved within a few seconds like other LINT “errors”, adding a missing ' – it is actually not an error.
   1. It will need several minutes and requires creative writing and deeper understanding of the context of the image.
   2. There is no helpful guidance in most wikis, partial in enWP.
   3. The target is to write a text which is “illustrative” – if you close your eyes the image shall appear in your mind before you would have seen it the first time.
   4. If I am encountering an alt= I delete them in most cases. They do not describe, they are confusing, 50% are just repeating the legend which will be told twice to the blind.
2. AI (artificial intelligence) is currently conquering automatic image description for blind people, integrated in screenreader.
   1. They get a button “Tell me” for each image, and a few seconds later the speaker starts describing the image; much better than most wiki authors do.
   2. There are apps for mobile phones in daily usage now. Blind people hold the camera in the direction incognita, and after some seconds the phone tells about houses, streets, inscriptions of shops, plate with the street name or reading the plate of a monument. They are heading for a dialog, “Which shops are there?”, and the phone will answer “barber shop, grocery, tailor”.
   3. Within some years I guess alt= is history and a Nice-to-have rather than pushing people to equip web pages.

From my understanding the role= is applied to the wrapping element, and only this one is mentioned and linked when generating a TOC from all role=navigation or role=region elements (in addition to <h2> etc.). Same goes for each single role=alert which may consist of several content elements.

In T204201#9877960, @Od1n wrote:

Another issue: I have a case with a gadget ("Diaporama" here) that is defined with a "categories" condition, but this gadget may also be loaded using mw.loader.load()/ mw.loader.using() (by this script), on a page that does not have the category.

In T366314#9876423, @Jack_who_built_the_house wrote:

so it can be removed with no effect.

HTML 4.0 – While clear= has been adopted, float= was implmented in all major browsers. Since it worked, it was used. Apparently still today. I am living in the wwwworld since 1995. Nevertheless, all these HTML attributes were deprecated in 1998 in favour of CSS. Wikis were founded in 2001, none might have occurred ever in any Wiki, but you may scan English Wikipedia for quite common usage of align=.

Please note that there are other means in addition to <gallery> and File: transclusion.

In T366314#9873117, @hgzh wrote:

The italics rule is not present anymore in the current stylesheet.

The reason why float-(left|right) are preferred in German Wikipedia is that they provide a small margin-top. Therefore they can be stacked.

We are going to adopt templates to follow WMF properties for inverting dark mode, and we follow the WMF definitions and try to inherit some of those.

I just happened to run into this border-color mantrap.