In T419143#11678431, @MBH wrote:

Some investigation was made in Russian Wikipedia discord chat, maybe it will be useful.

1. In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. Here https://wikireality.ru/wiki/РАОрг is an article about organisators of these attacks.
2. In 2024, ruwiki user Ololoshka562 created a page https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js containing script used in these attacks. It was inactive next 1.5 years.
3. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: https://meta.wikimedia.org/wiki/Special:Contributions/SBassett_(WMF) . In one edit, he loaded Ololoshka's script: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=30167202 and run it.

This would still be awesome.

Is it possible to do something about log entries for this user? For example, https://en.wikipedia.org/wiki/Special:Log/AccountVanishRequests is readily accessible and gives a comprehensive list of every user who's been vanished for privacy reasons, alongside their reason for doing so, all in one central and easily-indexed location. This would seem like, perhaps, the least private thing possible.

Bumping this to agree with all the stuff Izno said (although I take no position on the obscure parliamentary issues of which tasks should be under which bugs), and add the stuff I said at T31118; I think <details> and <summary> tags are a good example of a simple, low-overhead fix to what's currently a big obtuse workaround requiring clientside JavaScript. mw-collapsible is not only kludge that makes MediaWiki code incompatible with other stuff, it's also inaccessible in a lot of cases:. it only works for people who are capable of downloading and executing javascript -- many people have it disabled, and on en.wp for example my computer often doesn't load javascript and then just gives up altogether (making all mw-collapsible content impossible to view). It's hard to see how maintaining scripts/etc for mw-collapsible is easier than just permitting summary/details tags and leaving implementation to browsers.

May be worth noting that, per https://en.wikipedia.org/wiki/Wikipedia:List_of_Wikipedians_by_number_of_edits -- only 872 of us have made more than a hundy thou, and only 14 have broken a million (ofc this excludes bots). However, as it were, those 872 and/or 14 are probably the most likely to be using Xtools -- this seems to me, at least, to suggest that caching them might be really easy.

For what it's worth, I do a lot of work with templates and userscripts, and the lack of <details> is woeful.

Just to confirm my understanding of the situation: graphs are still broken after a whole year, with no replacement whatsoever, and no plan for implementing one?

Can local interface admins edit gadget pages now, or is this still a pending item?

This has been happening to me on the English Wikipedia. I use Firefox on Android. This started happening a few days ago. I will post here what I posted on the Village Pump.

Completely talking out of my whatever here, so tell me if this is stupid (it probably is) but is there a way to detect if page titles render with a pixel width of zero? Or, possibly, to iterate over all Unicode points, see which are rendered with a pixel width of zero in [whatever environment], and specify to render those as a period or a tofu box or something (or add them to the default title blacklist)?

It should be noted that this is one of the two deprecated characters in https://en.wikipedia.org/wiki/Khmer_(Unicode_block) (U+17B4 and U+17B5), which on that article renders as tofu, but I guess the characters themselves render as nothing.

Is this still a problem?

Going to post about this here since, although I solved the problem myself, this was what came up when I searched for it, so maybe other people will be here scratching their heads:

This would seem to, in general, militate against the wisdom of implementing a spam URL blacklist as a magical totem that prevents *anybody* (including EC, including TE, including sysops) from editing the page.

This happened with the Signpost today (details here). It seems that a good number of people were given double issues from the global MassMessage list on Meta. This is not user error, as the message was only requested once. For example, two successive edits to the same user talk page both cite the exact same revid (https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Signpost&oldid=24726786). I have repaired the duplicates via manual reverts, of which there were approximately 250. Most of these were from the local distribution list, but about a dozen were from the global distribution list; curiously, the doubled messages seem to be a couple hours apart.

I have spelunked through the Signpost omni-index (which I also set up, at https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Omni-index ) and cleared out (almost) all the bullshit. By my count, there were nearly a thousand pages, ranging from obsolete never-used redirects, to pagemove detritus from publishing errors, to templates that were created and never actually written, to deprecated templates with literally a single transclusion. They are all gone now: I am in the process of documenting what's going on at https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/Technical

This is now possible: WegweiserBot (running https://github.com/jp-x-g/wegweiser ) has refactored all of the old modules to include author information, and me and Mr. Stradivarius have updated the module to allow for sorting by author. This means that it is now possible to generate byline pages for individual authors: