The one major thing that have led to the accident was that one should NEVER, EVER run random scripts (in batches of hundreds of them in alphabetic order) from an interface-admin account.

1. Not really, I think. Incubator namespace hosts only short-lived page drafts, so there shouldn't be any concerns. User namespace can include different things apart from page drafts, but this is the same on all wikis.

I am an active member of Russian Wikipedia (and so is the ticket's author). I can tell you that even English words as accounts names would be much, much more readable than random strings of numbers that no person could remember or compare between users.

I'm pretty sure the global community, same as me and the ticket's author, finds words naming much easier to keep in mind then the numbers one. I don't see why there would be a need in "two name formats" that need to be supported.

A name consisting of few generated words would be much much more readable than a random string of numbers.

Oh, ok, thank you! So is this a bug in file descriptions on Commons? (Well, for another image, 480px produces an actual 480px image -- so what is the bug in that case?)

Is there some ETA on whether thumbnail cache cleanup will happen on Commons? User @Medvednikita has reported that this image offers in its description thumbnails of sizes 240, 480, 600, 768, but the real sizes are 250, 500, 900, 900. My understanding is that this is related to this task and T360589 (something along of the lines "thumbnails of these 250-500px sizes exist in cache cos they weren't cleaned up, MediaWiki now offers the closest size instead of always the requested one, and for some reason generation of 240-480px didn't happen"). (Probably until all the cache is cleaned we should make file description pages always show the real sizes -- but probably this needs a new task.)

That's strange. When I bought my YubiKey a year ago from Amazon it costed like $100.

I didn't know there was a community wish on this theme. Can you send it?

An option could be to not filter out missing data, but explicitly pass in all null rows as well, so that they have the same indices. That seems to work; see example here.

This sounds like a good idea.

@Jdlrobson-WMF user @Bezik on Russian Wikipedia has reported that this is actually a breaking change.
In any theme (MinervaNeue, Timeless, Vector-2022), any browser (Firefox, Vivaldi), without user CSS, when increasing browser scale/decreasing window width any punctuation marks after formulas go on the next line. Example on this page:

These are different things. You are talking about the situation when admin block a user and blocks also their IPs. This ticket is about the situation when a global admin or local admin blocks an entire IP range.

That issue is T411319. "then gaps in the data should be handled" is not true, they are not.

I see even two feature requests here -- 1) adding support in Extension:Chart for null or NaN values -- making continuous lines by ignoring them, 2) adding support in Extension:JsonConfig for producing null values from Lua (and obviously 3) patching Module:Graph:Chart in the required way).

It's not a bug in Charts extension, it's a bug in the Graphs module on Commons. I've reported it about a month ago.

Yeah, currently I introduced with some hacks only the size parameter. Some more info here: https://phabricator.wikimedia.org/T376845#11417667

There already is one. You can take the code from here: {{WikidataChart|P1082|pageIds={{{from|}}}|chart=Wikidata population (with dynamic data)}

There are two required parameters, a chart and Wikidata property to display on Y axis. Have you tried the examples slightly below?

See Module:Graph:Chart and Template:WikidataChart -- effectively, we now have graphs with dynamic data (e.g. from Wikidata) working again.

This is pretty much the biggest issue for charts in Russian Wikipedia.

The current workaround is to just remove the points outside the intervals, but this still doesn't allow 100% the same intervals as the page author intended.

No, you can't. This is exactly the "multiply the data values by -1" thing, and with it the users will see the negative values.

@Johannnes89 100% related, but I don't see in that task any mentions that originally graphs also look very small, not only blurred. Also probably the 2017 editor's is another bug.

Workarounds:
With some CSS hacks, here's what I was able to achieve on Russian Wikipedia: Template:WikidataChart (Lua, CSS). I managed to limit charts width (which otherwise stretch to infinity, producing ugly white space), but it's impossible to do that after some minimal amount about 700-800 px (depends on something?). Currently there's a hack utilizing transform: scale() to scale the graphs (as CSS zoom property messes up mouse events), but this doesn't allow arbitrary sizes (for example, you can't change aspect ratio without getting completely broken labels).

So does this mean somebody can now port Vega library to Lua (at least some very small subset of it) and we'll finally get working graphs from dynamic data (non-interactive, but still)?

Workaround:
Instead of this code (working for Wikidata):

item.editEntity(summary='my edit')

Use this (works for Commons):

data = item.toJSON(diffto=getattr(item, '_content', None))
data['claims'] = data['statements']
del data['statements']
commons.editEntity(item, data, summary='my edit')

I'm absolutely sure both of these properties should be implemented to display a button in the warning suggesting the user to autoreplace the incorrect value with the new one. There's just no sense in these properties without such a thing, and it seems like a trivial thing to implement.

Still an issue for my bot for some random Wikinews projects:

pywikibot.exceptions.OtherPageSaveError: Edit to page [[wikidata:Q8823]] failed:
Failed OAuth authentication for wikinews:de: The authorization headers in your request are for a user that does not exist here
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[wikidata:Q8823]] failed:
Failed OAuth authentication for wikinews:de: The authorization headers in your request are for a user that does not exist here

Why not just allow only listing all of the pages from a category (+ subcategories)? This shouldn't be really resource intensive (I think?), and cover like 90% of use cases, no? If an intersection is required, just a new subcategory ould be created, same as is constantly done now.

Why wasn't this task pushed forward?

On what exactly is this task stalled? AFAICS it was planned to be done in early 2020?

Another example of outdent creating a mess:

*** A
{{outdent}}
* B, reply to A
** C, reply to B
*** D, reply to C
**** E, reply to... D or A?

Seems it became better.

Currently they either do not open at all (as described above), or open very slowly.

This happens on any page on any wiki trying to open it while logged-in.