Wikipedia:Edit filter/Requested

Requested edit filters

This page can be used to request edit filters, or changes to existing filters. Edit filters are primarily used to address common patterns of harmful editing.

Private filters should not be discussed in detail. If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details to wikipedia-en-editfilterslists.wikimedia.org.

Otherwise, please add a new section at the bottom using the following format:

== Brief description of filter ==
*'''Task''': What is the filter supposed to do? To what pages and editors does it apply?
*'''Reason''': Why is the filter needed?
*'''Diffs''': Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.
~~~~

Please note the following:

• Edit filters are used primarily to prevent abuse. Contributors are not expected to have read all 200+ policies, guidelines and style pages before editing. Trivial formatting mistakes and edits that at first glance look fine but go against some obscure style guideline or arbitration ruling are not suitable candidates for an edit filter.
• Filters are applied to all edits. Problematic changes that apply to a single page are likely not suitable for an edit filter. Page protection may be more appropriate in such cases.
• Non-essential tasks or those that require access to complex criteria, especially information that the filter does not have access to, may be more appropriate for a bot task or external software.
• To prevent the creation of pages with certain names, the title blacklist is usually a better way to handle the problem - see MediaWiki talk:Titleblacklist for details.
• To prevent the addition of problematic external links, please make your request at the spam blacklist.
• To prevent the registration of accounts with certain names, please make your request at the global title blacklist.
• To prevent the registration of accounts with certain email addresses, please make your request at the email blacklist.

Click here to create a new request

Brainrot account creation

I've seen a lot of accounts like this one that use brainrot terms and usually are bad faith accounts that just vandalize wikipedia. As a result, I think we should create a filter similar to 54 (hist · log) with the regex of 614 (hist · log). It should look something like this:

action contains "createaccount" &
!contains_any(user_rights, "override-antispoof", "tboverride", "tboverride-account") &
(
abuseStr := "f\s*r\s*e\s*e\s*d\s*i\s*d\s*d\s*y|y\s*o\s*[lo\s]+s\s*w\s*[4ae]+\s*g+ // etc, the rest of the 614 regex;
(accountname irlike abuseStr)
)

– PharyngealImplosive7 (talk) 17:14, 14 December 2024 (UTC)

If this request is implemented, it should also exclude users with tboveride and tboverride-account, as this is essentially equivalent to an addition to the title blacklist. JJP_Master (she/they) 03:43, 15 December 2024 (UTC)

Added your suggestion to the proposed code. – PharyngealImplosive7 (talk) 21:55, 15 December 2024 (UTC)

Sorry, I missed an "r" in tboverride, so could you add that? JJP_Master (she/they) 22:03, 15 December 2024 (UTC)

PharyngealImplosive7, ccnorm(accountname) rlike abuseStr will not work for this lowercased regex, so use accountname irlike abuseStr instead if we plan to implement this new filter. But for now, I'm not seeing that many vandalism-only accounts with brainrot usernames on the recent changes list. Codename Noreste 🤔 Talk 03:34, 16 December 2024 (UTC)

I see them all the time. Not sure there's much point, though, because people can just choose a different username. It won't actually prevent any vandalism. If anything, usernames like this make it very easy to spot vandalism-only accounts. C F A 05:17, 25 December 2024 (UTC)

I mean I would intend this filter to be log-only like filter 54, so it's an easy way to see these accounts and block them quickly, not a disallow filter. – PharyngealImplosive7 (talk) 23:55, 25 December 2024 (UTC)

I don't see a problem with that. C F A 00:38, 26 December 2024 (UTC)

Alternatively, there's User:AmandaNP/UAA/Blacklist in which someone can place a request to add some brainrot regex to that blacklist (usernames like these will eventually be reported to UAA). Codename Noreste (talk) 03:13, 10 January 2025 (UTC)

I have two issues here. The first is, is an edit filter the right path for implementation here, or would the title blacklist be more appropriate? The second is, if implemented through an edit filter, I would almost certainly only exclude override-antispoof, keeping with what was used for 54 (hist · log). This is given that tboverride is a far wider amount of people than would generally be creating accounts with unusual patterns. Unusual and otherwise generally disruptive username patterns are generally held for those with the account creator flag, which are those identified to the Foundation and working with account creation requests, as well as administrators. I'm not sure it's the best idea to toss in every page mover and template editor, given there would be a near-zero chance of them actually tripping this at all (not all PMR/TPE are account-creation savvy, either, such as a current TPE who isn't even extended confirmed...). EggRoll97 ^(talk) 02:46, 28 December 2024 (UTC)

New user possibly adding Copyright violation or unreliable source

• Task: Highlighting edits by new users that add urls to wikis, that aren't licensed with a compatible license.
• Reason: Those edits are likely either a copyright violation or an use of a self-published source. This filter would partly be an extension of filter 894 (hist · log) (Self-Published Sources).
• Diffs: I've seen this a few times over at CopyPatrol, those diffs were all revdelled as RD1.

Nobody (talk) 12:47, 16 December 2024 (UTC)

What are the urls of these incompatible wikis? – 2804:F1...69:1A4C (::/32) (talk) 15:09, 16 December 2024 (UTC)

Mirrors and forks lists some of them, I don't think its even possible to make a complete list. There's also Fandom, which has both, compatible and non-compatible licenses for their wikis.[1] Nobody (talk) 15:36, 16 December 2024 (UTC)

Here's the basic code for it. (With a few example urls of mirrors that aren't compatible.)

Code
equals_to_any(page_namespace, 0, 2, 118) & !contains_any(user_groups, "extendedconfirmed", "sysop", "bot") & ( url := "\d{5}\.us|99colors\.net|alchetron\.com|celebsagewiki\.com|en-us\.nina\.az|knowpia\.com|profilpelajar\.com|wikizero\.org"; added_lines irlike url & !(removed_lines irlike url) & !(summary irlike "^(?:revert|rv|undid)") )

Nobody (talk) 17:44, 16 December 2024 (UTC)

1AmNobody24, I've modified the code to also exclude removed_lines. Without it, the user would get flagged regardless if they edit a part of a section containing the website or not. Codename Noreste 🤔 Talk 23:17, 16 December 2024 (UTC)

Filter for drive-by, unconstructive talk page junk related to student assignments

• Task: This is related to the persistent issue with talk page junk, some of which is addressed by Special:AbuseFilter/1245. I am proposing a filter to catch a further subset of them, most likely generated by students, that follow a specific but extremely common pattern:

• The page is not a user talk page, a sandbox page, or any subpage of Wikipedia:Reference desk
• The editor is an IP
• The subject line should be a school subject from a predetermined list. Some subjects that are common here: "English", "Math", "Mathematics", "Maths", "Geography", "History", "Social studies", "Chemistry", "Civics", "Physics", "Biology", "Life science", "Earth science".
• One or more of the following should apply to the comment body:

• Comment filter 1: Edits that are really short (fewer than 5 words or thereabouts)
• Comment filter 2: Edits that start with certain phrases: "Definition of", "Write", "Information about", etc.
• Comment filter 3: Edits that start with the phrases "what is" or "what are" (possibly others) and are somewhat short (fewer than 10-20 words? idk)

• Reason: This is a very common pattern of the talk page junk that has ratcheted up since 2021. See this village pump entry and this requested edit filter discussion for past discussions on the topic.

This specific subset is clearly related to student assignments -- WikiEd doesn't think it's related to their assignments specifically -- there is a correlation but it's probably just school, in general. For instance this diff seems to be associated with this assignment or a very similar one.

I suspect some of these are produced by LLMs, text-to-speech, search integrations, or other automated tools because of the time frame (the date they really started pouring in lines up almost exactly with the date GPT-3, ChatGPT, etc. came out); because of the formulaic predictability of the pattern; and because of certain tells in some of these suggesting they're overheard conversations, ChatGPT prompts, etc. (Here is a smoking gun for this.) These edits have almost no utility and usually go unanswered; if they are answered, it's usually to scold the user, who almost never responds.

There are literally thousands of these, cleaning them up is a huge task, and that task also has a deadline. If nobody cleans them up before the page is archived (which is likely to happen because school-curriculum talk pages are often long, and because archiving is often done by bots who don't check what they're doing) then they will be stuck there forever. (I cannot emphasize enough how arbitrary and asinine that is, but whatever.). While I'm willing to clean up as much of the existing stuff as I catch in time, it would be nice to stop the floods.

I'm happy to add to or refine this filter to reduce false positives and catch more false negatives, this is off the top of my head. The real solution is to either find a technological or UI-design cause, but this subset of edits is just so predictable that a filter might make sense.

• Diffs: 1094685874 (comment filter 1), 1183615020 (comment filter 1), 1085568369 (comment filter 2), 1108078327 (comment filter 2), 1064959579 (comment filter 2), 1185080593 (comment filter 3), 1110355731 (comment filter 3). Again there are thousands more examples, these are the ones I happen to have convenient.

If you want to find more -- or to help clean them up -- the relevant search pattern is insource:"UTC [subject]". A search pattern more prone to false positives is insource:"[subject or common one-word edit] Special".

Gnomingstuff (talk) 19:04, 19 December 2024 (UTC)

Bumping this. I can provide more acronyms that are even less likely to be false positives. Gnomingstuff (talk) 20:25, 5 January 2025 (UTC)

Here is some regex I've made quickly so it might not be accurate completely:

!("confirmed" in user_groups) &
!( (page_namespace == 3) || (page_namespace == 4 & contains_any(page_title, "sandbox", "reference desk")) ) & 
( 
    junkStr := "={1,6}\s*(?:(?:math(?:ematics)?)|(?:english))\s*={1,6}"; /* add other subjects */
    added_lines irlike junkStr &
    !(removed_lines irlike junkStr)
) &
(edit_delta < 50 || added_lines irlike "(?:(?:definition\s*of) || (?:write) || (?:info(?:rmation)?\s*about)) || (?:what\s*(?:(?:is)) )

This is fairly rudimentary and probably has a few errors but I hope it helps in creating a sketch of what the filter could look like. Thanks, – PharyngealImplosive7 (talk) 14:48, 6 January 2025 (UTC).

PharyngealImplosive7, your suggestion unfortunately does not work because the regex did not match some edits from those diffs, and because of the regex in the last line which was broken. Gnomingstuff, are there recent cases of these specific talk page junk edits? These diffs that you have provided are from 2022 and 2023, and because of that I believe that it's not worth creating a new filter just to check for these edits. Codename Noreste (talk) 03:10, 10 January 2025 (UTC)

Yeah the edit filter is not going to catch anywhere near 100% of this -- I'm mostly hoping to hit the major categories while avoiding false positives as much as possible.

That said, this is absolutely still ongoing. The list of diffs I linked is heavily skewed toward 2022/2023 because it only includes talk pages that have been archived. If the talk page wasn't archived, then I just reverted the edit and it isn't on that list.

I can put together a list of December 2024/January 2025 diffs but it'll take a while. Gnomingstuff (talk) 04:27, 10 January 2025 (UTC)

@Codename Noreste OK, timeboxed to about ~1 hour or so of searching, here are some edits from the past 30 days that fall into this category. This is not a complete list -- a lot of what was out there has been reverted/caught, which is why the list is skewed toward the past few days -- nor a full list of subjects, nor representative of how much each subject gets relative to the others. It's just what I found in an hour.

Sample drive-by edits, 9 December 2024 - 10 January 2025

diff, 9 December 2024 (political science) diff, 9 December 2024 (social studies, more elaborate subject line) diff, 19 December 2024 (history) diff, 20 December 2024 (social studies) diff, 22 December 2024 (biology; a little over the wordcount) diff, 23 December 2024 (English; subject line is longer and misspelled so outside current filter, but demonstrates the nature of these edits) diff, 24 December 2024 (history; see above note) diff, 26 December 2024 (English) diff, 26 December 2024 (science) diff, 26 December 2024 (physics) diff, 30 December 2024 (social/social studies; a common pattern is for the body text to be the title of the article but not sure you can do that with regex except maybe with some capture group) diff, 30 December 2024 (English) diff, 2 January 2025 (math) diff, 4 January 2025 (English) diff, 6 January 2025 (biology) diff, 6 January 2025 (maths) diff, 6 January 2025 (mathematics) diff, 7 January 2025 ("economic" - economics) diff, 7 January 2025 (physics) diff, 7 January 2025 (SST - social studies) diff, 7 January 2025 (geography; has tells of text-to-speech query) diff, 8 January 2025 (biology) diff, 8 January 2025 (biology) diff, 8 January 2025 (social studies) diff, 8 January 2025 (science) diff 1, diff 2, diff 3, 8 January 2025 (history; as above the subject line is too long for the proposed filter but it demonstrates the fact that this is drive-by homework queries) diff, 8 January 2025 (chemistry and English; two subjects in one) diff, 8 January 2025 (SST - social studies) diff, 9 January 2025 (science) diff, 9 January 2025 (history) diff, 9 January 2025 (economics) diff 1, diff 2, 9 January 2024 (social studies; has text-to-speech tell) diff, 9 January 2025 (history) diff, 10 January 2025 (history; ending in just "ok" is another common pattern, also this edit was from, like, right now)

Let me know if you have any other questions. Gnomingstuff (talk) 05:49, 10 January 2025 (UTC)

Some more recent edits, this time with some of the more common abbreviations:

Sample drive-by edits, 11 December 2024 - 14 January 2025

diff, 11 December 2024 (algebra) diff, 14 December 2024 (economics) diff, 29 December 2024 (English; longer subject) diff, 5 January 2025 ("Pak studies" - maybe "studies" in the end of headeris a potential fiter?) diff, 7 January 2052 (GK - general knowledge) diff, 9 January 2025 (social - social studies) diff, 9 January 2025 (social - social studies) diff, 9 January 2025 (biology) diff, 10 January 2025 (science) diff, 10 January 2025 (sociology) diff, 11 January 2025 (SST => social studies) diff, 11 January 2025 (history) diff, 11 January 2025 (SST => social studies) diff, 12 January 2025 (chemistry) diff, 12 January 2025 (English) diff, 12 January 2025 (geography) diff, 12 January 2025 (SST => social studies) diff, 12 January 2025 (MAPEH: some health related subject) diff, 13 January 2025 (English) diff, 13 January 2025 (English; amid other homework driveby edits) diff, 13 January 2025 (math) diff, 13 January 2025 (science) diff, 14 January 2025 (science) diff, 14 January 2025 (maths)

I think this should demonstrate how ongoing an issue this is. Gnomingstuff (talk) 12:23, 14 January 2025 (UTC)

Adition to filter 707

Given that the average report has a edit size between 600 and 1100, I think that edits by non-confirmed users that have an edit delta much bigger than that (2500 or 5000?) be disallowed, since they're likely non-constructive edits. Nobody (talk) 15:07, 13 January 2025 (UTC)

Do you have any diffs related to this? I can modify the old and new size OR the edit delta conditions together, perhaps. Codename Noreste (talk) 03:00, 14 January 2025 (UTC)

Diff 1 (+14,121), Diff 2 (+2,981), Diff 3 (+402,411), Diff 4 (+19,845), all in the last two weeks. Edit: Another one (17,279) Nobody (talk) 06:08, 14 January 2025 (UTC)

See Special:Diff/1269760874 (2,433 bytes added) in which an anonymous user added an article lead of a district in Thailand (probably disruptive), so I think we can lower the edit_delta limit to more than 1800 bytes. Codename Noreste (talk) 08:20, 16 January 2025 (UTC)

The biggest constructive edits I've seen this year by new or unregistered users were between +2,000 and +2,100 bytes, so I wouldn't lower it below that. Nobody (talk) 08:25, 16 January 2025 (UTC)

Never mind. Codename Noreste (talk) 08:35, 16 January 2025 (UTC)

I believe my suggested change to filter 707 below could work, along with your suggestion about blocking reports with more than 2500 bytes. Note that I removed the old and new_size condition logic because only the edit_delta works for some reason.

page_id == 26204397 & /* False positives reports page */
!("confirmed" in user_groups) &
(
    (
        /* Removal or modification of the page's headers */
        contains_any(
            removed_lines,
            "__NONEWSECTIONLINK__",
            "__NOINDEX__",
            "<noinclude>",
            "{{Wikipedia:Edit filter/False positives/Header}}",
            "{{shortcut|WP:EF/FP/R|WP:EFFPR}}",
            "</noinclude>"
        )
    ) | (
        /* New or anonymous users blanking or modifying reports */
        edit_delta <= -250 |
        /* False positive reports containing more than 2500 bytes */
        edit_delta >= 2500
    )
)

Codename Noreste (talk) 15:06, 16 January 2025 (UTC)

Surely this will also disallow good faith edits where the person pasted their edit into the description? – 2804:F1...70:9D36 (::/32) (talk) 15:46, 16 January 2025 (UTC)

I probably assume that you meant when people remove duplicate reports, or withdraw their own reports? On the other hand, see here. Codename Noreste (talk) 15:48, 16 January 2025 (UTC)

No, I mean the thing the page notice warns users against doing but people do anyways:

Please also note that there is no reason for you to paste the content of your edit here. The edit you tried to do is visible to others, and sometimes the same filter which stopped you earlier may stop you again. This is especially the case when including external links.

If this filter will also disallow that, as those cases are usually large edits, and there's consensus to do so, a different disallow message than the current MediaWiki:Abusefilter-disallowed-EFFPR might be more appropriate. – 2804:F1...70:9D36 (::/32) (talk) 15:53, 16 January 2025 (UTC)

All users (and those who can see private filter log entries) can see the attempted edit, so I'm not sure about the case regarding on disallowing good edits to EFFPR. I haven't seen any recent good edits to that page that have more than 2500 bytes, yet. Codename Noreste (talk) 16:02, 16 January 2025 (UTC)

and also, it seems that some people are removing or disrupting headers from edit filter related pages (not just EFFPR), see Special:Diff/1270484744 and Special:Diff/1270358969 (both EFN), and Special:Diff/1270356788 (EFR). For these three, I believe we can create a new filter by sending a request to the mailing list, or somewhere?

Cc to 1AmNobody24 who started the thread. Codename Noreste (talk) 12:58, 20 January 2025 (UTC)

That gets picked up by filter 1151 sometimes, but it could be added to 707. Though I wonder if filter 809 (private) isn't the better place for it. Nobody (talk) 13:32, 20 January 2025 (UTC)

I'm not sure of adding to 809 without commenting on other specifics, but perhaps a new filter could do because 707 uses a custom message, while for the new filter, we could use the default disallow message. Codename Noreste (talk) 13:59, 20 January 2025 (UTC)

Honestly, @Codename Noreste: I'm not sure why any filter preventing the disruption of edit filter-related page headings would need to be private (707 after all is public) since this is just regular vandalism. So I think a request to EFR or EFN would be fine. – PharyngealImplosive7 (talk) 20:47, 20 January 2025 (UTC)

This and this are also examples of edits that are clearly not constructive and should be stopped. Nobody (talk) 10:49, 24 January 2025 (UTC)

Keyboard mashing filter?

• Task: What is the filter supposed to do? To what pages and editors does it apply?

The filter is intended to catch "keyboard spam" edits (things along the line of "ajksljhgfhlasjaewzxcvo"). The way I believe this could be implemented is with a filter that catches strings of length 5 that contain only lowercase consonants (y is a vowel in this case). For example, in the example given above, the substring "jklsj" would be caught and flagged. Should only apply for main space edits and only for IPs to avoid usernames triggering the filter. Exception needed for links. I don't know what regex has in its capabilities so I don't know if this is possible. I'm worried about edits on other language scripts messing it up.

• Reason: Why is the filter needed?

This is a relatively common pattern of vandalism; the diffs below were collected over a span of a single, non cherry-picked hour.

• Diffs: Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list

[2][3][4]

Wildfireupdateman :) (talk) 17:50, 13 January 2025 (UTC)

• If this is done, I would suggest a longer string length than 5. For example, place names in Wales where "w" is effectively a vowel, such as Cwmbran, Amlwch or Pwllheli, may regularly have five consonants in a row. Not to mention occasional normal English plurals such as "strengths". Black Kite (talk) 08:49, 14 January 2025 (UTC)

Have you given some thought to compounds such as Knightsbridge and Catchphrase, names like Goldschmidt and Norbert Pfretzschner, technical articles like HTML color names (white is #FFFFFF; see also hex for color names Blanched almond, Gainsboro, Lemon chiffon, Navajo white, Pale turquoise, and Snow); the parenthetical phrase in the first line of The Adventures of Mr. Nicholas Wisdom, and non-English content (notably German compounds) such as Handschriftencensus (6), Selbstschutz (7), and Rechtschreibreform (7). But I believe these examples are rare, and that there are no 8-letter examples, so you can probably whitelist all of these. There might be a portion of an article that covers keyboard spam with examples, and you might have to whitelist that, too. Mathglot (talk) 10:31, 14 January 2025 (UTC)

I didn't think of those. It appears that in addition to the filter below, there are way too many exceptions to work properly. I'm going to retract this request but I don't know how; can someone help out? Wildfireupdateman :) (talk) 20:16, 14 January 2025 (UTC)

There IS a filter for this:

• 135 (hist · log) ("Repeating characters")

It works almost exactly as suggested as well, even the exception for links, with the difference being it looks for 9 characters, not 5.

At any rate, perhaps the filter could be improved - for example, it didn't catch the second example because the edit edited a line starting with a pipe (|), why do we exclude edits that do that?

That change was done here in 2012, which changed it from excluding edits that left a line like |- or |. in the article to ones that edit any line starting with a pipe or an exclamation mark.

The filter did not catch examples 1 and 3 because of the aforementioned vowels before it reached 9 'repeating' characters. – 2804:F1...87:8192 (::/32) (talk) 15:32, 14 January 2025 (UTC)

Alternate idea: since keyboard spam usually stays on the same keyboard row, could a filter that checks for repeated characters in the same row (usually the home row) be a thing? Chaotic Enby (talk · contribs) 17:50, 27 January 2025 (UTC)

If that is the case, the length trigger would probably be ~7-8 or so, as there are sufficiently few words(typewriter, rupturewort) that would need to be implemented as exceptions. Wildfireupdateman :) (talk) 17:54, 27 January 2025 (UTC)

Yep, that would be a more reasonable length trigger – 5 is too short, but 8 would likely still match most keymashes. Chaotic Enby (talk · contribs) 17:55, 27 January 2025 (UTC)

possibly misleading newcomer task

• Task: Tag possibly misleading newcomer tasks with "possibly misleading newcomer task".
• Reason: Most of the newcomer task edits I have saw are straight up vandalism.
• Diffs: Special:Diff/1265081093

M.C. (talk) 08:41, 21 January 2025 (UTC)

You can already filter for edits tagged with newcomer task at RecentChanges, I don't see how we could improve on that with an edit filter. Nobody (talk) 08:56, 21 January 2025 (UTC)

I agree, it's very hard to make a filter for these edits. Codename Noreste (talk) 11:00, 21 January 2025 (UTC)

Implementing the balanced editing restriction

WP:ARBPIA5 has been closed, and one of the successful remedies was to authorize the imposition of the "balanced editing restriction" on an editor if it is found that it would be a net positive for the project were the user to lower their activity in the topic area, particularly where an editor has repeatedly engaged in conflict but is not being intentionally or egregiously disruptive. Doing so would require an edit filter that would ensure that [i]n a given 30-day period, a user under this restriction is limited to making no more than one-third of their edits in the Article, Talk, Draft, and Draft talk namespaces to pages that are subject to the extended-confirmed restriction under Arab–Israeli conflict contentious topic procedures. See also: Wikipedia:Arbitration/Requests/Case/Palestine-Israel articles 5 § Balanced editing restriction. JJP_Master (she/they) 00:11, 24 January 2025 (UTC)

It seem 1339 has already been written by SilverLocust. It looks about right to me, at least as a starting point. I can only see this as a log that interested editors are going to have to go through, rather than a filter which actually limit edits through the filter. -- zzuuzz ^(talk) 00:20, 24 January 2025 (UTC)

Later today I'm expecting to edit the filter a bit. SilverLocust 💬 00:23, 24 January 2025 (UTC)

I have edited it to exclude bots, non-extended-confirmed users, and namespaces other than Article, Talk, Draft, and Draft talk. I'd welcome suggestions for improving it, preferably at the arbitration clerks' noticeboard. SilverLocust 💬 05:07, 24 January 2025 (UTC)

Extended-confirmed talk page filter

• Task: Prevent edits to article talk pages where the article is subject to the extended-confirmed restriction, the user is not extended confirmed, and the talk page edit is not tagged as an edit request
• Reason: The current system we seem to have consists of ECPing articles and not ECPing talk pages, expecting new users to know the difference, and blocking them when they don't get the message. Not only is this a much more heavy-handed system than it needs to be, enforcement of talk-page ECR is still patchy and inconsistent. An edit filter that simply prevents non-EC editors from inserting any edit that's not marked with an edit request template (and we should probably filter out edits that do have the edit but aren't new sections) would be much more robust.
• Diffs: I mean, I can put some together if you want, but ECR violations are kinda everywhere in ARBPIA.

theleekycauldron (talk • she/her) 17:37, 27 January 2025 (UTC)

While the idea is definitely good, I figure it might need some fine-tuning as some users might not always clearly mark their edit requests as such, even if they are an edit request "in spirit". However, if your proposal clearly instructs them to add the template if needed, it could definitely work.

Also, is it okay for users to reply in edit request sections they themselves created, or adjust their edit requests? Chaotic Enby (talk · contribs) 17:44, 27 January 2025 (UTC)

I would say yes to instructing them on how to make an edit request, no on replying to edit requests, yes to editing their original request if that's technically feasible to implement but I'm also okay with them just having to submit a new one. theleekycauldron (talk • she/her) 17:48, 27 January 2025 (UTC)

Actually, let me take a whack at drafting this – no way I'd self-grant EFM, but this would be an interesting opportunity to teach this to myself :) theleekycauldron (talk • she/her) 17:53, 27 January 2025 (UTC)

Thanks! That definitely seems like a good filter, and disallowing with a custom message could work out. I was also thinking of trying to write it out, but we can both do it and compare our versions! Chaotic Enby (talk · contribs) 17:54, 27 January 2025 (UTC)

Incredible! Here's a first draft that I'm sure is riddled with bugs :) I cribbed everything that works from filter 1339 by SilverLocust. theleekycauldron (talk • she/her) 18:11, 27 January 2025 (UTC)

!contains_any(user_groups, "extendedconfirmed", "sysop") &
equals_to_any(page_namespace,1,119) &
"This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." in new_html &
!(added_lines irlike "{{(E(C|P)ER|Edit(|-)Extended(|-)Protected)" &
added_lines irlike "^==[^=]")

Close to what I was having!

! contains_any(user_groups, "extendedconfirmed", "sysop") &
equals_to_any(page_namespace,1,119) &
"You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text &
! added_lines irlike "Edit *request(ed)?|Edit[ -](extended[ -])?protected|E(P|C)ER"

I used the generic message on talk pages so that it also targeted other topics under EC restrictions, and there's sooo many redirects for {{Edit protected}} to go through. Also I opted to not add the {{ since there was also the possibility of having whitespace or something between it, but I forgot about the header part, good catch! Chaotic Enby (talk · contribs) 18:14, 27 January 2025 (UTC)

Ah yeah, that seems better! Slapping one on the other, we've got:

! contains_any(user_groups, "extendedconfirmed", "sysop") &
equals_to_any(page_namespace,1,119) &
"You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text &
! (added_lines irlike "Edit *request(ed)?|Edit[ -](extended[ -])?protected|E[CP]ER" &
added_lines irlike "^==[^=]")

I have no idea what the process looks from here – does it get tested somewhere, do we need more input? theleekycauldron (talk • she/her) 18:17, 27 January 2025 (UTC)

! contains_any(user_groups, "extendedconfirmed", "sysop") &
equals_to_any(page_namespace,1,119) &
"You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text &
! (added_lines irlike "{{ *Edit ?request(ed)?|Edit[ -](extended[ -])?protected|E(P|C)ER|Req ?(uest(ed)?)?edit|Edit ?protect(ed)?|Protected edit|Edit locked|Changerequest" &
added_lines irlike "^==[^=]")

I think this should take care of every single {{Edit protected}} redirect there is. Also curious about the process now! Chaotic Enby (talk · contribs) 18:19, 27 January 2025 (UTC)

[Watching with interest] I'll throw it into a filter when you've finished edit-conflicting me :) Guessing: 1341. -- zzuuzz ^(talk) 18:23, 27 January 2025 (UTC)

@zzuuzz: edit-conflicting has concluded! theleekycauldron (talk • she/her) 18:35, 27 January 2025 (UTC)

I've put the filter. Someone please suggest a better title for it. I haven't done any testing of past edits, which I normally would have. A few diffs would help.. -- zzuuzz ^(talk) 18:38, 27 January 2025 (UTC)

Looking at Talk:Palestine (region), Special:Diff/1269265277 could be a good check for a non-EC edit without an edit request, and Special:Diff/1251785711 for a non-EC edit with an edit request. Chaotic Enby (talk · contribs) 18:42, 27 January 2025 (UTC)

1269265277 is a miss so far. Is it possibly because the link over "extended-confirmed" in "You must be logged-in and extended-confirmed" appears as html markup in new_html? theleekycauldron (talk • she/her) 18:56, 27 January 2025 (UTC)

Yes, I was about to note that. Also, there are two slightly different versions of the PIA talk notice: {{ArbCom Arab-Israeli enforcement}} (the older version) and {{Contentious topics/Arab-Israeli talk notice}}. I would go back to the earlier suggestion of using "This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." in new_html so that this is limited to talk pages of ECP'd primary article rather than any talk page with a PIA notice (including unprotected related topic articles). SilverLocust 💬 19:04, 27 January 2025 (UTC)

I'm curious, our last proposed version did have new_text and not new_html, @Zzuuzz was there a reason for why you changed it to new_html? Chaotic Enby (talk · contribs) 19:50, 27 January 2025 (UTC)

Sortof, starting from a precautionary approach based on what SilverLocust said immediately above. There are at least 2 versions for new_text: "You must be logged-in to an extended confirmed account (...", and "You must be logged-in and extended-confirmed to edit ". I'm wondering if simply "You must be logged-in" would perform this function. -- zzuuzz ^(talk) 20:55, 27 January 2025 (UTC)

Yep, but neither gets caught with new_html, which adds hard-to-parse HTML code to the content of new_text, so I'm not sure why it would be preferable. Just "You must be logged-in" could work, although there's still the issue that any editor could add it to prevent others from editing the page. Chaotic Enby (talk · contribs) 21:04, 27 January 2025 (UTC)

I'll just clarify this explicitly: new_html checks whether the article is protected. new_text checks whether there's a talk page notification irrespective of protection. I went with the former while cooking dinner. -- zzuuzz ^(talk) 21:08, 27 January 2025 (UTC)

Yes, it does make more sense to use "This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." in new_html for the hidden flag.

My question was about why you used "You must be logged-in and extended-confirmed to edit or discuss this topic" in new_html at first (rather than "You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text like in the submitted version), which still checks for a talk page notification but parses the HTML code instead. That still didn't check whether the article was protected, but didn't check for the text's wording itself, which is what I found confusing. Chaotic Enby (talk · contribs) 21:14, 27 January 2025 (UTC)

That seems to have been corrected? There's a few reasons I might not copy a proposal verbatim, or make a temporary mistake. -- zzuuzz ^(talk) 21:19, 27 January 2025 (UTC)

No problem, sorry then! Chaotic Enby (talk · contribs) 21:21, 27 January 2025 (UTC)

Thanks for adding it! Small (and not very critical) detail I'm just realizing right now, I think there should be parentheses like "{{ *(Edit ?request(ed)?|Edit[ -](extended[ -])?protected|E(P|C)ER|Req ?(uest(ed)?)?edit|Edit ?protect(ed)?|Protected edit|Edit locked|Changerequest)", otherwise it only checks {{ for the first one. Leeky's original draft had them but I forgot to add them back! Chaotic Enby (talk · contribs) 18:38, 27 January 2025 (UTC)

Done. Here's one example of a new section without an explicit edit request: Special:Diff/1271256707. -- zzuuzz ^(talk) 19:08, 27 January 2025 (UTC)

I have a new suggestion for filter 1341:

equals_to_any(page_namespace, 1, 119) &
!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
"You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text &
!(added_lines irlike "^==[^=]\n{{\s*(?:Edit ?request(?:ed)?|Edit[ -](?:extended[ -])?protected|E[CP]ER|Req ?(?:uest(?:ed)?)?edit|Edit ?protect(?:ed)?|Protected edit|Edit locked|Changerequest)")

Note that because of new_html, during testing, none of the edits have matched. Also, instead of checking twice for added_lines, I added a \n when I merged the regex together into one check (for a new line of blank space). Codename Noreste (talk) 19:10, 27 January 2025 (UTC)

new_text is a good fix, but the new added_lines regex doesn't catch "header (blankline) template", which is fairly common, so that should probably be adjusted? I think having them as two separate checks is more bulletproof. theleekycauldron (talk • she/her) 19:19, 27 January 2025 (UTC)

I can change it back to those two checks if you wish, thank you. Codename Noreste (talk) 19:25, 27 January 2025 (UTC)

I've made a number of minor changes and implemented some suggestions from above. I'm off to cook some dinner, so I'll pass this along. -- zzuuzz ^(talk) 19:27, 27 January 2025 (UTC)

Enjoy dinner! A couple of things for whomever wants to tweak this further:

1. "This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." doesn't seem to appear in pages like Talk:Gaza war. Maybe check for membership in Category:Wikipedia pages subject to the extended confirmed restriction related to the Arab-Israeli conflict, or that string?
2. Our first filter hit is from a bot that seems to manually not have ECP, so we should probably add the bot flag to the list of exempt usergroups.

theleekycauldron (talk • she/her) 19:33, 27 January 2025 (UTC)

Bots have been added. We also need to consider people editing their own requests! -- zzuuzz ^(talk) 19:34, 27 January 2025 (UTC)

I have a solution to fully exclude users who are editing their own requests:

equals_to_any(page_namespace, 1, 119) &
!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
"This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict." in new_text &
!(
    added_lines rlike "^==[^=]+==" &
    added_lines rlike "{{\s*(?i:Edit ?request|Edit[ -](?:extended[ -])?protected|E[CP]ER|Req ?(?:uest(?:ed)?)?edit|Edit ?protect|Protected edit|Edit locked|Changerequest)"
) &
!(user_name in (old_wikitext + page_recent_contributors)) /* Exclude users who are editing their own requests */

Note that using irlike in line 5 in its current version does not make sense, so I changed it to rlike, and I did the same for line 6, but for the non-capturing group, I used (?i:, which should make the text case-insensitive while using rlike. Thoughts or suggestions? Codename Noreste (talk) 19:47, 27 January 2025 (UTC)

Looks good, although the original proposal of "You must be logged-in and extended-confirmed to edit or discuss this topic" in new_text might still be better as it includes other CTOPs under similar restrictions? Chaotic Enby (talk · contribs) 19:53, 27 January 2025 (UTC)

Just realizing that there are two wordings for it, so your earlier proposal might be better, my bad. Chaotic Enby (talk · contribs) 19:56, 27 January 2025 (UTC)

I have recently changed it back to new_text. Codename Noreste (talk) 19:58, 27 January 2025 (UTC)

As far as I can tell, the "This page is subject to the extended.." text doesn't appear within new_text, since it's a hidden element.. I might be wrong; it's not super easy to test. -- zzuuzz ^(talk) 22:06, 27 January 2025 (UTC)

Evidently new_html and new_text both work, per your example below (Special:AbuseFilter/examine/1869020215). But the latter is smaller – about half the size in that example. SilverLocust 💬 04:42, 28 January 2025 (UTC)

Well spotted. -- zzuuzz ^(talk) 06:10, 28 January 2025 (UTC)

For that, we might need to hear what leeky thinks about the suggestion you said above. Codename Noreste (talk) 19:59, 27 January 2025 (UTC)

I don't know whether it should be just PIA or broader, I'm mostly focused on PIA. I'm also not sure whether it makes a difference for it to be new_text or new_html, because the filter is currently at new_html and is catching edits. As for the suggested edit-own-request, doesn't that basically give any user a free pass around this filter if their name is on the page somewhere else? theleekycauldron (talk • she/her) 20:44, 27 January 2025 (UTC)

The edit-own-request thing should already be taken care of without that line, as an edited request would show up in the "+" side of the diff and thus be present in added_lines. Chaotic Enby (talk · contribs) 20:48, 27 January 2025 (UTC)

Even if the ER template is on its own line? theleekycauldron (talk • she/her) 21:02, 27 January 2025 (UTC)

In that case no, you're right. I forgot they were on different lines! Would there be a way to check the lines immediately above to check for the template, until reaching either a header or something that can be parsed as a signature? Chaotic Enby (talk · contribs) 21:06, 27 January 2025 (UTC)

Here's a relevant example: Special:Diff/1271850666 (Special:AbuseFilter/examine/1869020215). It doesn't answer all the questions here, but a check of the edit summary may provide one route forward.-- zzuuzz ^(talk) 22:11, 27 January 2025 (UTC)

Thanks a lot! I'm guessing we could check if Extended-confirmed-protected edit request is in the edit summary but Reply isn't? While that is easy to game, non-ECP users usually do not know about the specifics of edit filters. Chaotic Enby (talk · contribs) 23:04, 27 January 2025 (UTC)

Maybe we should just not filter out replies in edit-request sections? or is that too big a false negative... we do seem to be okay with people responding to concerns about their own edit requests. theleekycauldron (talk • she/her) 04:11, 28 January 2025 (UTC)

There's a few recent FPs in the logs, due to how line breaks are used in added_lines, which I've now fixed. So having reviewed a few hits, I'm thinking we should be checking for a) any addition of an edit-request template, or b) any edit summary containing 'edit request' (loosely speaking), and then c) anything which could be reasonably construed to be an edit request (example (details)). -- zzuuzz ^(talk) 06:10, 28 January 2025 (UTC)

Agree with the first two cases. For the third, it might be hard to filter something that presumably needs human understanding and can't rely on specific keywords, but words like proposed text, proposed change or change .* to .* could be good hints. Chaotic Enby (talk · contribs) 22:02, 28 January 2025 (UTC)