I see ... almost 40'000 accounts got banned ... but as WMF admits, essentially no damage had occurred except the discovery the the mass ban tool did not work: T389728: Locking hundreds of accounts with Special:MultiLock results in 0 locks

We have documented https://www.mediawiki.org/wiki/Help:CirrusSearch#Regular_expression_searches that
this form of query is expected to time out, particularly on wikis of decent size like dewiki. The
suggested variation insource:/Dremel/ insource:dremel returns results in < 1s and should be equivalent

Reportedly LUA can use 50 MiO RAM, quite generous. But if 7'000 pages hog 50 MiO, then every single page consumes ca 7 KiO. Does it really need so much? I could try to call "mw.title.newBatch(...)" in batches of 25 pages, and copy the relevant info from bloated title objects into a LUA table of booleans.

Related tasks:

• T410513: Parsoid behaves strangely on pages violating the Expensive Budget "expensive-parserfunction-category" BUG discovered the same day
• T376564: Scribunto should provide a bulk ifexists check resolved

Drop this {{ }} syntax altogether for cats and files. There are better methods to show the content of a cat, and better methods to transclude ie show a file.

I disagree with lowering the priority, and I disagree with move to "non-blockers" given that this is a blocker. Please move into Blockers (any wiki) given that this bug indeed does break a module https://www.wikidata.org/wiki/Q120442526.

It could be of course limited to plain text, ie accept things like

Thank you for that answer. Now I start understanding how this ie activation of "Extension:EmailAuth" could happen. Still, there are several false assumptions:

elaborate on the security risks associated with enabling 2FA?

Indeed I have exactly this problem:

Thanks ... but I can't see a method to disable this behaviour. I do not want to enable 2FA (a huge security risk), and of course I do clear the history whenever I am done online. Also I access my account from several places and several devices, making the suggestion "preserve the cookie" inapplicable. Generally, I do not want let any third party collect my personal data when I use wikis. Is the only way to fix this removing my email address, or would that result in immediate loss of my account?

I think the next obvious question is can we
make mw.title.new("Media:foo.svg"):getContent() return the text of the svg if the
file is below a certain size.

I support preserving the traditional rasterization of SVG:s into PNG. See also T396307: Add the missing link from LUA interpreter to SVG rasterizer. Outcome when viewing wiki pages should be predictable and same in all browsers to the utmost possible extent. So when viewing an Indonesian lemma in Esperanto wiktionary having a SVG with lang=id I want to see the image in Indonesian, even if the browser, the ISP or IP address, or the OS are in German or whatever.

I don't understand why T405861 (Lua implementation) was merged and not this task. The effects for readers are
the same, but T405861 only works in Lua (so less use cases for creators). I don't understand this decision.

This should de global: T396307: Add the missing link from LUA interpreter to SVG rasterizer.

The bug is still present at commons: https://commons.wikimedia.org/wiki/Category:Blue_ISO_639_icons_with_double_parentheses now 2025-09-20.

Support \r, \n, \t, and \uNNNN in insource and intitle queries
Open, Needs Triage

Done! Fixed.

I also greatly prefer T122934 (or something similar) to this hacky workaround.

I principally highly support this. It should be possible to brew SVG:s by LUA modules. Either let the browser rend the SVG, or add the "missing link" from existing LUA interpreter to existing SVG rasterizer. The challenge is to design this in a decent way maximizing usefulness and minimizing maintainance nigtmare, abuse and nonsense, as well as and risk of sudden killing (see T334940). Also this should be limited to "commons" to prevent that a gazillion-SVG-mess located at commons only is repaced by a gazillion-templates-mess spread over hundreds of wikis (see T121470). While a solution to T121470 possibly is not expected soon, the "templatized SVG idea" ultimately must not become a part of that problem making it even harder to solve.

Sorry but I have to reopen this one. The fix is partial only. It indeed fixes the original problem

Possibly related: T389623: Parsoid fails to parse [[{}]] single curly brackets inside double rectangular brackets

Still suggesting " Automatically create populated babel categories as needed by a dedicated bot account. " as otherwise it is very unclear when they are created and how.

I can see that both contain translatable text. But maybe both contain translatable defaults too? The "interface messages" ultimately do. But what about the LocalSettings configuration variables "BabelCategoryNames" and "BabelMainCategory"? On eowiktionary they contain the translated word "Vikivortaristo".

It is less clear when try are created. This is ultimately a minor problem.

2. Well, support for " Automatically create populated babel categories as needed by a dedicated bot account. " then.

1. Sysops are expected to be inherently careful when editing protected pages. Weak support for a shorter warning like " beware of consequences for existing categories " .

Traditionally those messages contained translatable text (poorly translated for some smaller languages ...), but they can also contain trivial fixed text: https://eo.wiktionary.org/wiki/MediaWiki:Babel-autocreate-text-levels (the underlying module must detect ns 8 in order to make the {{kat}} show as it does). Here https://eo.wiktionary.org/w/index.php?title=MediaWiki:Babel-autocreate-text-levels&action=info&uselang=en we can ee that the module is trancsluded in the ns 8 message page, but it shouldn't be.

Seems to be already fixed.

It brews for example "Категория:Ru-2" instead of "Категория:User ru-2"

Very good thing. IMHO the blocks against the bot should be globally removed in favor of setting the new setting "no autocreation" on affected wikis.

The task was created AFTER the begin of the timeframe if it was 2025-01-20. If no answer comes within 24 hours then this probably can be closed as obsolete and not done.

Any progress, given that a patch emerged over 3 months ago?

https://commons.wikimedia.org/wiki/File:Bugged_SVG_ISO_639_on_commons_2024.png
https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Bugged_SVG
https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Issues_with_E-road_shields_(Tabliczka_set)

I highly support this proposal. It essentially solves T278629. Many wikis do suffer from the current limit of 500. The number of pages needing over 500 IFEXIST:s is low, but they exist and are important. Example: https://sv.wiktionary.org/wiki/Wiktionary:Balans_efter_spr%C3%A5k_och_ordklass

function should return an array of mw.title objects, so we can preload the other fields

None of the provided or linked images exposes the alleged bug. So it's probably fixed by stealth. :-D

current behaviour is crap

Just stick to good old ASCII quotation marks.

The logo is active now. Please revert 2024-07-13.

Working link: https://www.mediawiki.org/w/index.php?title=Extension:Scribunto/Lua_reference_manual&diff=prev&oldid=6470970

Shot: https://commons.wikimedia.org/w/index.php?title=File:Bug-in-subheadings-ASCII-62.png
Link: https://eo.wikipedia.org/w/index.php?title=Vikipedio:Alinomendaj_artikoloj&oldid=8650474#Adolf_Hitler_%E2%86%92_Adolfo_Hitlero_kaj_Vladimir_Putin_%E2%86%92_Vladimiro_Putino

The fault is in the proprietary "Ios" and the proprietary "InternerExplorer". I am aware that some of the patents on MP3 expired, still converting Vorbis to (inferior) MP3 is anything else than a gain. As long as users of proprietary stuff are the most privileged group having everything working smoothly and "natively", whereas users of free software and free file formats have trouble, the power of the proprietary companies will not shrink. PNG as a temporary solution until the patent on LZW84 expires, Vorbis as a temporary solution until the patents on MP3 expire, Theora as a temporary solution until the patents on old MPEG expire ... who would want to ever design a free file format under such provisions?

It should not try to convert a free audio file format into an unfree one: T346508.

Agree and strong support. Changing the submicroscopic "i" to "ⓘ" is an improvement. But please add an attribute allowing to override this new "(i)", allowing for empty string to suppress it (so that separate wikitext can be used in order to link directly to Commons).

• The fact that the namespace 4 has different names on different project types of same language makes sharing templates more difficult.
• The fact that the namespace 4 has same name as the site causes confusion. People are trying to create articles in the ns 4 assuming that ns "Wikipedia" is the obvious choice for wikipedia articles. People don't understand it's purpose. This is happening on essentially all wikis, last but not least on Indonesian wikipedia. Are other namespaces such as "Template:" NOT part of Wikipedia too?
• The namespace 4 has most aliases and causes most trouble and confusion. On many wikis we have page titles like Wiktionary/Wiktionary/Wiktionary/Project/Project.
• On wikidata it is difficult to name an item linked to pages in ns 4 because it has many names even in one language. Using the generic "Project:" is possible but it will NOT show like that on any wiki.

The former "Sitetitle" contains "{{SITENAME}}".

The name of ns 5 is currently " Pembicaraan Wiktionary: ".

YES please do decommission "Windows-1252" (and "Windows 11") ASAP.

OK ... T184749 ... does svwikt still contain non-ASCII-and-non-UTF8 text?

This one still fails: https://sv.wiktionary.org/w/index.php?title=MediaWiki%3AHistorywarning&diff=14484&oldid=8261

Logs are broken too: https://sv.wiktionary.org/wiki/Special:Logg/Taylor_49

Swedish wiktionary is still broken. I can't delete pages anymore. Plus some other cosmetical errors. But I still can undelete and protect.

T331906: Add Lua function to read out previous section heading suggests another, possibly cleaner and simpler solution to the same problem.

Indeed T122934 adresses same problem, but this one offers a simpler and cleaner solution avoiding the need for extra code like {{#sectionproperty: declare | lang=en}}.

The translation between language code and language name (discussed at meta page linked above) is already available elsewhere on every decent wiktionary. This is about reading out the RAW heading and nothing else.

Do you believe that if someone opens a Wikidata item with 100
sitelinks, Wikidata should query all 100 Wikipedia projects every time?

Can this maybe get closed now? There are plenty of non-urgent bug-items about the same thing, and one more is still open:

Adding Wikidata badges in Wikidata via a bot needs one bot approval within Wikidata
Adding a magic word to existing redirects would require a bot request on every Wikimedia project

T299823: Regularly run recountCategories.php on Wikimedia wikis via systemd timer

SUPPORT, all wikis, once per month.

If it is valid then it is a dupe of T85696: Allow action=purge to recalculate the number of pages/subcats/files in a category.

The script was run again on all public WMF wikis due to T299244: Deleted pages are not being removed from links tables, which also messes up category counts.

Right ... quit ping-spamming, and make sure to give a support vote after 2022-01-28: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Wikidata/Do_not_follow_sitelink_redirects_when_redirect_badge_is_used#VALIDREDIRECT

don't need arbitrary padding

T2986: [tables] Please implement COL, COLGROUP unresolved since year 2004