I did mention it several times now, but I feel urged to repeat: The “reauthentication” is entirely pointless and does not improve against attacks and worm proliferation.

• I can wait and sleep, as long as no “reauthentication” did happen, and no critical resource edit has been seen.
• As soon a vulnerable page is on editing, I set a cookie with a timestamp.
• When that page has been saved, my cookie tells me that I have 14 or 59 minutes to do whatever I want, since the “reauthentication” gave unlimited green light. Go for it.

There are three actions that really help:

1. Whenever a resource page is edited, safemode is to block any JavaScript.
2. Launching an interactive edit via index.php does need some hidden random code field not available for page retrieval to avoid faked interaction, or similar methods.
3. As soon as api.php is used, which might modify easily 50 pages per wiki, an individual access code for this run has to be provided, or block api.php entirely.

Yes, it is.

In T197137#11775914, @PerfektesChaos wrote:

I do not understand how and why a repeated login should be a remedy against automatic malicious operations?

I can listen to the [publish] button when NAMESPACENUMBER is 8 and CONTENTMODEL is css or javascript.

• If the button is pressed, I set a cookie yippie with current timestamp. Perhaps waiting for some approval etc., or check success of publishing when this page is rebuilt and got a new revision number.
• On every visited page from now, if yippie is on time I can run a script with everything I want. I am a confirmed account less than a quarter old. I do not leave traces when bounced back, watched by some smart monitoring.
• I have interface rights, otherwise I would not get a [publish] button in MediaWiki namespace for CSS or JavaScript.

In T197137#11834632, @Nux wrote:

I think I haven't mentioned this, but you would not be able to POST to it from another page. You would not have a token. CSRF tokens are specifically designed to block forged requests. The important part here is that the token must be specific to that page and obviously(?) specific to a single user and obviously(?) just available on that special page.

I would retrieve that special page via $.ajax() and can read a CSRF token in the header via XMLHttpRequest. Then modifying the JS payload code and sending back the form.

In T197137#11833818, @EMill-WMF wrote:

CSP is an entirely pointless approach, and wasting staff resources.

There are three ways to modify a .js page under advanced restrictions:

1. Interactively by some Special:SecureEdit or Special:EditResource etc. which is in safemode.
2. HTTP POST to index.php a form with all field values from Special:SecureEdit including hidden special safety keys built in when this page is retrieved from wiki server.
3. Change a set of pages via api.php and provide a special security code for one run only, for this account only, within some days.

In T197137#11822948, @Od1n wrote:

I still prefer the "disable execution of JS from wiki pages" approach (though would it be sufficient?), but if "re-auth" is kept, we could reduce its friction:

In T197137#11822294, @Nux wrote:

Or you can just click a button "yes I want to edit sitewide JS" on Special:QuickAuth. This adds a cookie token for an hour and you check that cookie upon editing of Mediawiki:*.js and redirect and done. Probably a one day of work, a bit more for translations.

So who would approve the sitewide adjustments if they are already done by interface moderators, who are qualified to do so. Do we expect communities to have technical people higher up in the hierarchy?

I do not understand how and why a repeated login should be a remedy against automatic malicious operations?

My ISP are using frequently changing dynamic ranges. I do not have one particular IP range I could ask to be unblocked for an entire week.

In T421654#11762462, @Krinkle wrote:

The canonical address used by Beta Cluster is beta.wmcloud.org since last year (T289318).

Sorry, but I have no access to BETA since March 2025. My regular environment is connected via a general ISP with >10 M customers in Europe, frequently changing dynamic IP ranges, all blocked.

• Several weeks ago I succeeded to connect my desktop environment via smartphone and slow Bluetooth, but after one week my mobile provider has been blocked as well.
• I gave up.
• I discontinued both software testing and also development one year ago.

I do hate IP blocking. It is an approach of last century. In 1999 you knew that you are blocking a particular department of a certain university. Nowadays all mobiles and most desktop sites are using universal providers, including privacy protecting VPN offered by browsers and security tools and the ISP. It became pointless to identify a bad guy via one constant IP address.

If you are cleaning your wiki and visit all pages with a lint problem, on editing all “important” lint categories need to be highlighted (there are a few lint categories which should be ignored since they do not reflect real errors).

In T419196#11680202, @Pppery wrote:

A malicious script can submit changes like this by screenscraping the web UI with only slightly more effort.

@cscott Yeah, fine, thank you.

Actually, I would be more happy to stop autopromotion for accounts in a certain category (per wiki, configured via system message) since that needs no maintenance efforts.

BTW, there is already code in current MW which can be shared:

• Magic parser does perform correct rendered hyphenation, but is expecting hyphens or no separator.
• Booksources special page already does a validity check.

In T413375#11517219, @cscott wrote:

to put in a Scribunto module

That would be required to be distributed to >1000 wikis. And maintained everywhere forever.

I do expect that an {{#isbn:}} transcluded in wikitext will check validity of mandatory first parameter.

• If optional second parameter is not 1 and the value is invalid, I want a maintenance category thrown and a small hint visible following every complaint:

On invalid ISBN:

• The problem is in the era of manually computed checksum from 1970 until 2006 with ISBN-10.
• They tried to calculate the checksum, based on publisher ID and internal serial number, but failed to catch the correct figure. Even electronic calculators were rare.
• The bad ID was printed into the book.
• The (national) libraries registered the data, typing a paper card and copied the bad number.
• In library catalogs, you could find the book by bad ISBN, but with no entry for a “corrected” ISBN. Even worse, nobody but the publisher knows which one is the bad digit, usually miscomputed checksum, but the printer might have shifted the digit sequence.
• Therefore it is necessary to arrive at Special:Booksources with a formally invalid ISBN, but not issuing an error message when transcluding {{#isbn}} in wikitext.
• If there is no suppress error message in parser function, a message and tracking category shall be issued.
• By ISBN-13 since 2007 and electronic accounting systems almost no errors are known.

Only background: is dangerous since it might bear an image URL to malicous.

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.

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.