I just noticed (and either overlooked before, or it really appeared in the list with its original timestamp after minutes) that one of my edits was indeed saved. https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_intervention_against_vandalism/TB2&diff=prev&oldid=1314610333

Such a page-specific issue sounds like an AbuseFilter-related issue to me, but I can't find anything at https://en.wikipedia.org/wiki/Special:AbuseFilter/history that would explain it.

https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AHuggle%2FFeedback&oldid=1313119292#c-ToBeFree-20250924112700-Novem_Linguae-20250924032600

I'd even say we should have a two-dimensional setting: Bot difficulty from 0 to 100, human work from 0 to 100. Displaying a maths question in plain text would be 0:10, displaying ten of them would be 0:100. Using images instead of text would increase the left number instead.

Increasing a CAPTCHA's difficulty is probably normally done to stop bots which manage to solve easier CAPTCHAs. When Cloudflare or Google display their most annoying CAPTCHAs, they probably do so in response to bot traffic: Once someone has proven their humanity (and perhaps some CPU work), they're allowlisted with a cookie.

In T251910#6501971, @Ammarpad wrote:

Note that this is not an error per se. If you don't select any revision that does not make sense and so you'll be redirected to an error page, the "return to mainpage" is meant to guide you and everything back to normalcy. There are many pages (that are not normal to come by) that have that generic return message also.

Ah no, they need to contact ca@. Okay.

I just confirmed this on enwiki in case it needed confirmation. @Randomdude121 had asked about it and I'm pretty sure my rollbacks were counted in the years before. Past rollbacks are still part of my edit count, new ones are not counted.

Oh my, I see it now. I came here from the "Rangeblock Calculator" AN discussion linked as "1" above and thought "we already have a solution for that". But one of the main points of the task is to prevent the automatic deletion after 40 days from happening, and probably to re-enable the scripts in their original form. Okay, okay.

This seems to be mostly or purely about the rangeblock calculator, which is (hopefully) going to become a special page available to all users. It already exists for checkusers.

It's still happening, as pointed out by @Mathglot:

I mean, the filter hits are now probably gone due to the renaming, which appears to break these logs for both the source and the target username, which is probably a separate bug we hopefully also already have an issue for.

@Amdrel, @Seddon: Does "no activity" and "[no] public logs" intentionally include users with "Disallow" edit filter hits that led to a warning on the user's talk page, such as https://en.wikipedia.org/wiki/User_talk:Vanished_user_16d7650337e0e95cfe1b82503d0a1d4f ?

😊 As a late reply to @Ladsgroup, I just noticed the "addedBy" column and am happy – of course I don't mind. Thank you!

https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=88.230.103.208 keeps getting multiple entries per edit (2023-10-05T14:55:08), this time through https://en.wikipedia.org/wiki/Special:AbuseFilter/1199 alone.

<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.