In T340275#9143053, @Niharika wrote:

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow blocking of global accounts should be fixed instead.

Quick update - we are discussing this actively and there is a good chance we will end up working on T17294: Allow blocking of global accounts instead of this task. I will have another update within a couple of weeks. Thanks all for the helpful comments.

In T340275#9129585, @Sj wrote:

I would certainly be able to work with a semi-soft block. As it's possible to assign confirmed flags to new accounts, a variation could also allow running editing workshops through such blocked ranges. [schools often being subject to such blocks]

In T341414#9119218, @Ciell wrote:

Step 1-7 is needed to navigate to the translations starting from the Admin panel, I think to remember this specific section of the interface is visible for all, just not every user has access to change anything (read-only, as to say). Vermont is referring to step 8 in the process in their comment.

Yes, but you don't need to do all 7 steps every time you want to check on a banner you're supporting. When you setup a message group, you'll have a link to translate the message group, often to be included in the banner. From that link, click message group statistics, change which boxes are checked, and then there's the list of translations which you can then review and approve. Yes it's technically 8 steps in from just the search bar, but I'm not sure if there's any better way to navigate to message group stats for a specific message group besides through that chain of related pages. I'm certainly interested to know if there are thoughts on a better layout for these pages, though. My opposition to changing this is largely because, if we do get any development time (volunteer or staff) put towards this problem, there are more pressing things to work on. It's not great, but it's usable.

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners

I'm a bit confused here; I don't think I've seen anyone including html markup in a banner translation unit. Generally, if there's a line of text, we'll just put a localizable message there, and then add the translations through the Translate extension. Because there's rarely differing formatting within a line, it's just one plain text line inside a <p> tag. Additionally, CN banners are not parsed as wikitext, it's just HTML.

• Make the interface for approving banner translations simpler and more intuitive

I'm also confused on this point. Approving translations are as simple as opening the drop-down (on the review page) and then clicking "publish" for each translation.

• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

These two should be relatively easy to implement, depending on how the CN and Translate extensions bundle actions into their relevant userrights. Once the former is done, the latter is just a matter of a Meta-Wiki RfC, if we think that's even necessary.

The idea of allowing any two users to approve translations for CN banners is not a workable idea. This would make global CN banners incredibly susceptible to vandalism on a global scale, and far less protected than any random translatable page.

To maintain current capabilities, we would need to be able to set global blocks that only apply to temporary accounts (curently soft blocks), and global blocks which also apply to logged-in users (hard blocks).

I gave this ticket a more thorough read, and there are some points I would like to clarify.

In T309328#9058626, @valerio.bozzolan wrote:

Premising that, as far as I understand, the community of CheckUsers very much like the current "bug" that "blocks everyone in the damn planet including registered users, including autopatrolleds, including ...". So, while the situation could be improved (that is not acceptable honestly to me as-is) as compromise we should think about how to still give to our dear CheckUsers the ability to monitor the situation of registered users (so, CU should be able to "spy" whatever sysop that is exiting from non-predictive Internet nodes like "open proxies", for whatever is their weird legitimate investigative reason to explain such invasive eye on trusted "coworkers"...)

In T313446#8094343, @RoySmith wrote:

Perhaps that could be formalized, with a little help from the software. Imagine a work flow like this:

It appears that the many users affected by T-Mobile range blocks, which of course will (for the most part) only affect mobile devices, are not able to see any of the helpful templates intended to be viewed in the block notice on mobile, because of this issue.

It hasn't worked for the Spanish Wikipedia's CopyPatrol since the 4th of January, it seems. Same with the French version.

Another complaint about this account at https://meta.wikimedia.org/wiki/Talk:Steward_requests/Permissions#Strange_administrator_wikiquote:de:user:Missbrauchsfilter

In T150826#4778796, @Bawolff wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

I believe this should be handled by a meta RfC rather than discussion at the enwiki Village Pump and a Phab ticket. (Unless, of course, the WMF wants to act on it immediately as a security issue)

In T181848#3910896, @awight wrote:

In T181848#3852728, @Halfak wrote:

Oh this is done. It has been reviewed by @Adotchar

@Halfak @Adotchar can either of you confirm that this task can be closed? I remember some confusion on IRC when Aaron's comment went through. I would assume that experimentation would have to be done on the beta cluster, which doesn't have the models enabled yet, so unsure how this task would be completed. I'll update the task description per my understanding, please edit if I'm off-base.

In T181848#3805841, @Halfak wrote:

OK so here's what I suggest you do.

1. Disable the new recent changes filters in your preferences.
2. Edit your "/common.js" to look like mine: https://simple.wikipedia.org/wiki/User:EpochFail/common.js
3. Go back to Special:RecentChanges and wait a little bit. ORES should highlight changes that are likely to be damaging.
4. Tell us how it goes!

I did a little bit of testing and I was able to catch some damaging edits :)