Workaround: https://www.wikidata.org/w/index.php?title=MediaWiki:Deletereason-dropdown&diff=2241374887.

User can put "und" in their babel: https://www.wikidata.org/wiki/Category:User_und.

They are always categorizable programmatically. The respective content handler just needs to provide a "side channel" for categorization. This could be for example a reserved JSON key or even a new MCR slot.

Somewhat similar problem as T62160: Edits by Babel AutoCreate tagged as mobile edit or T228959: Abusefilter's block with a "Mobile edit" tag.

See also T175562: Check “conflicts with” and “item requires claim” constraints on qualifiers and references?.

I think this can be closed in favor of T312097: [EPIC] MUL - Default values for labels and aliases .

https://www.wikidata.org/w/index.php?diff=2111464738&oldid=1893689482

https://www.wikidata.org/w/index.php?diff=2338975707

This has been the most detailed proposal so far:

In my opinion, "unlikely to be reverted" is unlikely to be of any use for patrollers (it's harmless, though). In fact, patrollers would (besides the "very likely to be reverted") benefit most from a filter that excludes edits below a threshold instead (i.e., edits unlikely to be reverted). Such a filter would increase the efficiency of patrolling as it would prevent recent changes from presenting edits that patrollers (probably) don't have to deal with while keeping a reasonable recall (85-95%).

In T386978#10573119, @Epidosis wrote:

By the way, restoring the right for Wikidata administrators to block batches in QuickStatements would mitigate the issue; this function ceased to work many years ago.

My humble patrolRevisions.js script provides this button.

In T386978#10573119, @Epidosis wrote:

By the way, restoring the right for Wikidata administrators to block batches in QuickStatements would mitigate the issue; this function ceased to work many years ago.

Some ideas that I believe are still worth looking into before going too drastic:

In my opinion, opt. 2 is the most easeful. The labeling narrows to simple yes/no, and it also contains the diff information (which the check will also use). But we won't get the "dictionary" (If yes, what words or phrases should be detected?).

In T390873#10709896, @Dreamy_Jazz wrote:

In T390873#10709849, @Ladsgroup wrote:

I'm reviewing the schema of abuse filter and I have several notes:

• A lot of work in this regard is not done yet. I'm still seeing afl_user_text and afl_user, can we finish these migrations please?

Hmm. I see that T188180 was recently resolved by @matej_suchanek. Any thoughts on this?

In T390528#10706524, @MusikAnimal wrote:

This is definitely a race condition. I had a brief look at core's BlockUser, and there doesn't seem to be any protection (mutex, lock) against it when placing a block.

I think that sort of thing is done in the storage layer, i.e. DatabaseBlockStore. But either way, the fact that multiblocks was utilized when the feature flag was not enabled is indicative that there is a problem.

This is definitely a race condition. I had a brief look at core's BlockUser, and there doesn't seem to be any protection (mutex, lock) against it when placing a block.

Like this:

The title is a bit misleading as "Confusing experience" is definitely not what this feature request asks for.