<s>I guess the order of filter updating and tag updating could be reversed to avoid race conditions. But this is me nitpicking perhaps without understanding what actually happens.</s> Now I see it's a transaction.

As formal "awareness" is tracked by this filter, being able to filter a user's talk history for one single relevant tag is beneficial. Splitting the history into two tags would break this functionality. The tag filtering interface requires the actual tag name, not the label, although labels can be chosen from a list.

Clicking the link with Firefox just leads me to a normal "There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page." (HTTP 404)

An anon-only email block on an IP address is unlikely to have any meaning other than the here-desired one, as Special:EmailUser is not available to logged-out users by default and in probably almost all MediaWiki configurations.

With "block sending e-mails" existing for exactly this purpose, there is no need to reinvent the wheel, no need to add a new option to the blocking menu, no lack of a tool to selectively prevent password resets for abusive ranges. All that's needed is a bugfix: Without "block sending e-mails", don't block sending e-mails.

In T109909#7769254, @Oshwah wrote:

In T109909#7705708, @ToBeFree wrote:

Isn't this what the "block sending e-mails" option is for?

Since this option can only be applied to an account being blocked

Removing {{Auflagen-Diagramm|Zeitungen|1090|Verk|5000000}} solved the problem. https://de.wikipedia.org/w/index.php?title=Bild_(Zeitung)&oldid=221538811 contains the still-broken revision.

(by the way, message names with words separated by hyphens and spaces at the same time look strange. "Nstab-project_talk" looks like an accident, at least due to its inconsistency with "Nstab-talk".)

I'm currently attempting to build an infobox using the following syntax:

Isn't this what the "block sending e-mails" option is for?

I was unsure whether to share the specific account name, as it has been redacted. I can simply link to a diff, though.

In T298655#7599988, @Majavah wrote:

On the other hand, User:2A01:4C8:1488:8B62:0:0:0:0/64 and User:2A01:4C8:1488:8B62:F997:1338:1555:BB9F/64 are both valid separate page titles in the User: namespace.

Reproduced and explained:

Oh, T270798 even has a patch for review. That was Sep 4 2021, though. :/

• Similar to: T188690, T139656
• Duplicate of: T270798
• Could be superseded by: T146628

Ah well, that explains the issue. I incorrectly assumed that the video converter (AV1 -> VPx) was running on the same host (or at least on the same software) as the thumbnailer. The old VP9 file has been restored for now. Thanks!

Can someone from SRE confirm that the bug exists and is currently reproducible? Is there a kind of desired "maximum response time" from sysadmins in response to persistent 100% HTTP "client" errors caused by a server-side issue for files embedded on 86 pages including https://commons.wikimedia.org/wiki/Commons:Media_of_the_day ?

I'll probably revert the file to the previous revision sometime in the next week, as the filesize is a bit excessive and the codec currently lacks hardware decoding support on client devices. The second link in the bug report then probably needs to be updated (/thumb/archive/... instead of /thumb/...). At the moment, I'm not doing this as I fear it may break the current perfect reproducibility of the bug.

"Other users" :)

(I do acknowledge that even without access to [[Special:Unblock]], it would currently be possible to unblock a user by re-blocking them for 0 seconds. However, for user group assignment, we do have a technical separation of "remove or shorten" vs. "add or prolong" access. It's not as obvious as it may seem to be.)

Caught with --qd querydump.dat -vvv. Again, no querydump file was created anywhere.

Caught on exit with --qd -vvv

Heisenbug. Happened twice in a row, but disappeared when using --qd -vvv.

@Aklapper , @Ladsgroup , has this been fixed on enwiki? I can't see it anymore when going through the diffs at https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox/T279276&action=history

Ah, sorry. Thanks!

Incomplete fix: With the default system message gone, the revisions marked as "quality" during the regression are now displayed as follows:

Counter-argument: Everyone will get used to "Reply" over time, and standardization isn't a bad thing.

https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox/T279276&action=history

This would be solved by T235873.

Here you are:

In T239277#6441351, @Wugapodes wrote:

We should consider granting to autoconfirmed by default, though I'm not sure it's the right course.

(Per T263943#6775076, I guess this specific task can be closed then, but something needs to be done about that iOS bug affecting multiple enwiki users)

@Dbrant, the problem does not affect my own (non-iOS) devices and I couldn't provide a detailed bug report nor any reproduction steps even if I wanted to. I was hoping for the responsible team to have a look at this unbureaucratically. If it helps the team to file a task, please do so.

This is a serious issue still remaining in place. I searched for a template error first, then noticed that this is a MediaWiki regression. It causes problems at enwiki's vandalism report page, where bots like DatBot automatically create urgent reports with lowercase IPv6 addresses that are incorrectly interpreted as non-actionable.

@Dbrant, would you mind having a look at this again? Perhaps this is a combination of two issues in one task; perhaps it's the same underlying problem. There is something that needs to be fixed because it causes disruption in the community.

Alternative solution: Convert to a page-creation block as in [[T199918]] (thanks @Xaosflux )

Sorry, I'm afraid the "enwiki user" was me; when the "clear watchlist" button on my oversized watchlist had no visible effect, I ended up doing a "raw watchlist" edit, cleared the field, saved the page and repeated a few times. That actually emptied the watchlist over time; I could see the number of pages decreasing quickly after this.

oh, that's a funny coincidence; I didn't see T270737. I disagree about it being a duplicate of T146628, though. It's not a duplicate, it's an interim solution before proper range search support is added.