It's definitely an improvement. I'll take it, if that's what we've got. Looping over all the blocks would also be satisfactory. Or, just remove the "There are multiple blocks against your account and/or IP address" part — that's already implied because we're calling blockedtext-composite, not blockedtext. If you remove the "There are multiple blocks against your account and/or IP address" from the block reason, that allows local customization for how to inform the user that there are multiple blocks.

Hello everyone. I write to emphasize this is a highly urgent issue and needs prioritization. This issue affects everyone who is using a VPN and editing the English Wikipedia -- including many who may not even know that they are using a VPN (see, e.g., iCloud Private Relay). I am guessing this is at least 10% of the non-established editors who attempt to edit, though I don't have a real basis for this. As I'm sure y'all can empathize with, receiving this message must be infuriating and entirely inconsistent with the Foundation's prioritization of Growth in its planning.

In T314672#8147378, @Tgr wrote:

@L235 is there any other place where you would expect better documentation?

Maybe "log", then? The schema is less well-defined there, and it's used by other services (such as the abuse filter log) that don't create entries on Special:Log.

We run into the 5000 entry limit *all the time* and having a way to navigate those results would make us much more effective as a team. This would be a good task to prioritize if there is capacity for that.

This seems like a relatively easier task that would help immensely, given the ubiquity of script usage when using CU.

This would be quite helpful.

This is already possible and being done on enwiki by testing the $7 parameter for whether it's an IP address. See https://en.wikipedia.org/wiki/MediaWiki:Blockedtext.

I would support this request; as an enwiki CU who has used this tool informally by emailing Ladsgroup, I can attest that this tool would be wonderfully helpful.

@Tgr that would be an insufficient response. It may be stating the obvious to you, but to the *many* editors who have come to functionaries in very tough situations (harassment or even legal trouble) after using a publicly identifiable username who registered prior to this message, it certainly was not. This was what prompted us to post this message in the first place.

I'm going to make this a security-protected issue for now for the reasons given in T265845#7309052 as a precaution. If this was the wrong call please feel free to reverse, but I'd rather be safe than sorry.

This would be useful on the English Wikipeida.

While interim stopgap measures (e.g. Znuny) should be implemented, this is a good opportunity to revisit the software we're using for email response purposes. OTRS is notoriously difficult to use: for example, I have heard from many English Wikipedia CheckUsers who refuse to use OTRS due to the difficult interface. Previously, the chief advantage of OTRS was its open-source ethos; unfortunately, that seems to no longer be a benefit. We should seriously consider using vaguely modern and well-designed CRM software, and switch away from OTRS and its descendant projects as soon as technically and logistically reasonable.

This is a big issue and I hope that it receives priority for fixing.

See also the recent discussion on enwiki which prompted this, and a user script that mitigates this issue: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=953329946#Fun_admin_script.

Done per IRC request.

Yes. Per this document, expected and normal behavior in the past is that redirects converted to articles show in the queue. Also see this discussion for more local info. Thanks!

This is an urgent issue for the enwiki community. This allows users to easily circumvent the new page patrol process, on pages that have usually been unwatched but are precisely the ones that are not notable enough for articles (that's why they're redirects in the first place). I hope that we'll see a fix for this as soon as possible. Thanks!

@Dzahn, I was intending to make Board business (voting and reports and such) easier replacing our current patchwork system, so I think a second list would be needed, but to avoid the confusion, perhaps "wikimedia-us-ia-board" would be better?

Thanks @Dzahn! Per the description, could you create wikimedia-us-ia-internal@lists.wikimedia.org as well?

@RobH, thanks! Yeah, please remove me from the moderator list as well. Cheers!

Chmarkine, there's always StartCom/StartSSL which has free certs, and they're already trusted by default in all major browsers.

Thanks Dzahn, appreciate it.

Also reproduced in Firefox Developer Edition and Firefox Nightly (on the same machine):

I can reproduce this at https://sv.wikipedia.org/wiki/Pwdes?veaction=edit. Screenshot attached.

Thanks. I suspected that was the issue but wasn't sure.

it's not working (if you try to search "wm2016:" on any wiki) nor is it showing up in Special:Interwiki

This needs to be added to the interwiki table as "wm2016", keeping in line with the previous Wikimania wikis.

Can confirm that I'm also getting this on several pages on en.wp. It's intermittent and happens in about one in two requests.