Wikipedia:Edit filter/Requested/Archive 21

Add links
From Wikipedia, the free encyclopedia

Furry convention page vandalism

  • Task: This filter would filter out attacks on pages related to furry conventions. A good start would be to add it to members of Category:Furry conventions. Specifically the string "furries are queers" or variations of it would be what is filtered out.
  • Reason: There have been several attacks on pages in this category in recent days. I noticed it today and instead of protecting these pages, a filter would make it so valid edits from users without extended confirmed protection could edit the page. Of course the filter may need to be a little more robust than just this string. Looking at the history of some these pages, this seems to have been going on for quite some time.
  • Diffs: [1] [2] [3]

Philipnelson99 (talk) 21:05, 8 March 2023 (UTC)

Support with the option to expand the filter as new phrases are discovered. Furry hate is not new to this encyclopedia, and more phrases may be discovered over time. Jalen Folf (talk) 21:32, 8 March 2023 (UTC)
Speaking of, new phrases used: "They're weird and creepy" and "I dont like these people", as of the latest edits on affected pages. Examples: [4] [5] [6] [7] [8] Jalen Folf (talk) 22:18, 8 March 2023 (UTC)
This is an LTA that has demonstrated some degree of dexterity in evading filters. I'm not saying it isn't worth trying out a new filter or modifying an existing one as it may temporarily slow them down and may keep their preferred abuse from going live, but our primary tool is likely to remain ECP. 74.73.224.126 (talk) 14:07, 9 March 2023 (UTC)
I oppose the creation of the filter. I don’t see any reason why we can’t just extended-confirm protect the page. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:56, 26 March 2023 (UTC)
The box at the top of the page says:
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. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:58, 26 March 2023 (UTC)
This should probably be a LTA filter. I disagree with Illusion Flame since this applies to a set of articles. 0xDeadbeef→∞ (talk to me) 03:08, 27 March 2023 (UTC)
The filter would only apply to about 7 pages. I truly don’t see why we just can’t protect them.
However, you guys are also more experienced around here.
If we are going to make an LTA filter, I recommend discussion occurs over email per:
If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details to wikipedia-en-editfilterslists.wikimedia.org - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:30, 27 March 2023 (UTC)
Hmm if there are only about 7 pages then I think regular admin actions should be sufficient. I didn't see the actual number of pages listed at that category and I assumed there would be more articles that the current actual count, Smiley Sorry! 0xDeadbeef→∞ (talk to me) 09:41, 28 March 2023 (UTC)

Transclusions of articles in templates

 Courtesy link: Wikipedia:Administrators' noticeboard/Incidents § Vandalized Preview Pop Ups for American cuisine and a Large Number of Related_Articles

There's been a spate of vandalism where editors have been transcluding articles on unpleasant subjects into templates, see 86.180.182.153 (talk · contribs · 86.180.182.153 WHOIS) or Rustyrivet (talk · contribs). Would it be sensible to disallow transclusions of articles in templates for new editors? There seem to be very few legitimate uses of this feature [9]. 192.76.8.84 (talk) 18:51, 31 March 2023 (UTC)

Testing. Galobtter (pingó mió) 21:43, 31 March 2023 (UTC)
 Done Galobtter (pingó mió) 23:03, 31 March 2023 (UTC)

Removal of fringe-theory keywords

–LaundryPizza03 (dc̄) 19:51, 25 March 2023 (UTC)

I think this edit filter request is good and can be approved.
@LaundryPizza03: Would you want this filter to tag the edit or warn and tag the edit? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:41, 30 March 2023 (UTC)
Definitely tag the edits to allow the FTN editors to track them more closely. I will need to ask about warning users, however. –LaundryPizza03 (dc̄) 01:48, 31 March 2023 (UTC)
They are not opposed to issuing a warning to editors who trigger the filter. –LaundryPizza03 (dc̄) 09:17, 31 March 2023 (UTC)
Okay! Only edit filter managers are allowed to create edit filters, so I will ping some active ones to this discussion. @Galobtter: @Suffusion of Yellow: @TheresNoTime: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:52, 31 March 2023 (UTC)
This should be tag only as, whilst I think the filter is a good idea, you are going to get an absolute s**tload of false positives. Black Kite (talk) 11:13, 31 March 2023 (UTC)
Warning users for their edits doesn’t disallow them. It merely warns them and asks if they want to continue with their edit. If they press publish changes, it will go through. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:09, 31 March 2023 (UTC)
We'll have to see how well the filter actually works, if it's possible to build a decent one; but for possibly good-faith edits, I'd like to see a proper consensus for warning, even if it allows edits to go through. Galobtter (pingó mió) 21:47, 31 March 2023 (UTC)
In theory, this means that if for example a vandal adds to Barack Obama the text "Obama is a pseudoarchaeologist", then the editor who goes to remove that will see a warning, but I suppose that sort of thing is an unlikely scenario. BD2412 T 22:19, 31 March 2023 (UTC)
We could only have it apply the warning to new or unregistered users. That might help fix the problem. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:17, 1 April 2023 (UTC)

Telephone numbers added to articles

  • Task: To prevent the addition of personal telephone numbers (either of the editor adding them, or of their friends/enemies) to articles
  • Reason: I've been going through all our Telephone numbers in [Countryname] articles and related subjects per this AN discussion, finding telephone numbers that have been added in the past 50 edits in the last 2 years and having them Oversighted. This is now more or less done, but as I've been removing them I've been watchlisting the articles and am therefore seeing new ones being added live. HJ Mitchell suggested an edit filter might work to block these in the first place, saving Oversighters a lot of work.
I've not worked with regex for some years, so I'm very rusty. The filter would be something like:
^[\+]?[(]?[0-9]{2,4}[)?[-\s\.]?[0-9]{3,4}[-\s\.]?[0-9]{4,6}$
but not where the digits are consecutive (123456789, 2345678, 0123456 etc) and not when the digits are repeating 5 or more times (0800 1111111, 1-333-333-3333 etc) as these are both valid "example of number formatting" edits. That's where I get stuck!
  • Diffs: Recent diffs in question have been revdelled, but older ones include [10] [11] [12] and this edit summary — Trey Maturin™ 17:53, 18 December 2022 (UTC)
    I regularly undo the addition of strings which are probably phone numbers in some country or other, and also see them in edit summaries where they're harder to remove. Some are obviously commercial (contact 012345789 to order), others more cryptic (probably the author's own number). Blocking this for everyone would produce lots of false positives, but it might be reasonable to stop IPs from adding (\d[- \d]{7,12}\d), where the capture contains either 5+ consecutive digits or 9+ total digits. That would allow ISO dates (2022-12-18) and year ranges (1998 - 2001) even if poorly punctuated. Multi-digit amounts, such as large sums of money, generally contain comma or dot. Certes (talk) 21:20, 18 December 2022 (UTC)
Bumping thread for 14 days. 137a (talk) 13:12, 9 January 2023 (UTC) 137a (talk) 13:12, 9 January 2023 (UTC)
A minor issue would be that the filter log entries would still need to be oversighted anyway, which would then push the task of finding and reporting such log entires solely onto EFHs, EFMs and sysops. Unless just keeping the filter private would be enough? Mako001 (C)  (T)  🇺🇦 04:40, 8 February 2023 (UTC)
I’d see the filter as preventing the edit happening at all (once the testing and refinement period is over). I’m not sure what kind of information the system logs: if it logs the text of the edit, then yes, the log would need to be trusted-users only (sysops as a minimum, oversighters-only as an ideal). This may need discussion with (or by) those very trusted users — that’s above my pay grade! — Trey Maturin™ 09:26, 8 February 2023 (UTC)
Filters log basically anything you can see from a diff, even when set to disallow. If made private, they still show it to several thousand more users besides oversighters (namely, EFHs, EFMs, sysops). So, yes, the logs would contain oversightable material, and it would still (at least technically) need oversight requested anyway. Mako001 (C)  (T)  🇺🇦 13:43, 8 February 2023 (UTC)
It would be up to oversighters to say if this was more or less convenient than having me emailing them manually for the 250 most-telephone-number-attracting articles on my watchlist, but it doesn't sound like it, does it? Bum. — Trey Maturin™ 13:47, 8 February 2023 (UTC)
Well, in one rather extreme case of something later oversighted which was known to a lot of users, User:CheeseDreams password was avaliable on User talk:Rienzo up until March last year. OK, someone had logged in and changed it since, but... it had been up there for over eighteen years after they posted it there.
Regarding your question, probably not, since someone would still have to request oversight, but unless you become an EFH, you wouldn't be able to. So, it would still be just as much work, only it would fall on editors who may be more busy with other stuff, like keeping edit filters running smoothly, and general admin stuff. Setting it to warn would probably be a problem too, since the effect would be much the same, with "successful" warnings (where they didn't make the edit) still leaving a oversightable log entry behind (as much as disallow), and "unsuccessful" warnings (where they did make the edit) leaving two log entries and an edit to be oversighted. Mako001 (C)  (T)  🇺🇦 13:58, 8 February 2023 (UTC)
It might be feasible to make a bot that oversights everything the filter catches automatically (or, when I think about it, skip the middleman and just use a bot). Snowmanonahoe (talk) 12:59, 7 March 2023 (UTC)
We've had Special:AbuseFilter/247 which blocks addition of emails for quite a while. Surprised the equivalent for phone numbers doesn't already exist. I think having a private filter would reduce visibility quite a lot in practice by not allowing phone numbers into articles, since no one really looks at log entries and they are functionally automatically revdelled (EFHs and non-admin EFMs are trusted and they are the only non-admins who can see). So I think I'll see if I can test something decent. Also per Special:PermaLink/1093966130#EF_247 having a filter to stop oversightable stuff does seem to help oversighters. Galobtter (pingó mió) 03:43, 25 March 2023 (UTC)
If this filter is created it needs to apply to Talk pages. I've seen far more personal phone numbers added to them than to articles. - X201 (talk) 10:44, 27 March 2023 (UTC)
It would be extremely useful for dealing with the Nigerian phone scam, although that has not been active recently, and the Kenyan phone scam although that produced several ways to get round the filter. - Arjayay (talk) 10:59, 27 March 2023 (UTC)
Testing what Certes suggested basically at Special:AbuseFilter/1244. I think references will often cause false positives so we'll have to see what can be done about that. Galobtter (pingó mió) 09:09, 31 March 2023 (UTC)
Ah yes, you might have to allow some 10- and 13-digit numbers, perhaps only with a certain check digit or when accompanied by a certain keyword. Certes (talk) 09:26, 31 March 2023 (UTC)
I filtered down to small edits that don't add urls. Hopefully that works well - based on the diffs given, the phone number additions are generally pretty small edits. Galobtter (pingó mió) 09:29, 31 March 2023 (UTC)
I started a discussion at Wikipedia_talk:Oversight#Edit_filter_to_block_additions_of_phone_numbers about the filter. Galobtter (pingó mió) 21:04, 5 April 2023 (UTC)

Talk page junk

Is there anything we can or should do to deter brief talk page additions such as this? They're quite frequent and, whilst rarely a serious problem, clog up the page and waste editors' time finding and reverting them. Many consist (in heading or content or both) of a phone number, e-mail, social media account or similar spam, which are addressed elsewhere, but there's still plenty of plain nonsense. Such contributions may or may not be signed. Certes (talk) 12:35, 30 March 2023 (UTC)

I feel that the scope of this proposed filter is quite unclear. The diff you linked is just a 1 character test addition to a user talk page, but in your request you want a filter for emails, phone numbers, etc. We currently have a filter to detect emails, and we are working on one for phone numbers. (See above) If you would like a filter, I suggest you be much more specific on what strings you want to prevent and the actions you want the filter to take. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:38, 30 March 2023 (UTC)
Yes, it's an idea rather than a specification at this stage. If there's a more appropriate forum for that, or it's simply unwelcome, that's fine. Certes (talk) 21:37, 30 March 2023 (UTC)
You want WP:VPIL, most likely. –LaundryPizza03 (dc̄) 09:38, 31 March 2023 (UTC)
I think it's fine to make general suggestions here for discussion but it's not really possible to make a useful filter without a specific pattern of edits to be blocked and multiple diffs showing how to design a filter to block those specific diffs. Galobtter (pingó mió) 11:54, 31 March 2023 (UTC)
Something like the following may be possible:
!("confirmed" in user_groups)
& (page_namespace == 1 | page_namespace == 3)
& added_lines rlike "^\s*=+\s*\S{0,2}\s*=+\s*\S{0,2}\s*(?:\[.*\(UTC\))?\s*$"
& length(removed_lines) == 0
0xDeadbeef→∞ (talk to me) 07:02, 2 April 2023 (UTC)
Thank you; that looks like a good pattern to at least try. I'd raise the maximum word length from 2, but I'm not sure how far it can go without false positives. Beware of catching something like ==XY== A link near the start of a useful comment. [signature], which I think matches the expression above. Certes (talk) 11:16, 2 April 2023 (UTC)
@0xDeadbeef Now running something similar at Special:AbuseFilter/1245. Seems to be pretty good at catching junk as per testing vs Special:AbuseFilter/1014 helpfully being run by Suffusion of Yellow :) Galobtter (pingó mió) 04:38, 4 April 2023 (UTC)
Judging by edits like [13], I don't think the word count can be expanded any further beyond 2. Galobtter (pingó mió) 04:40, 4 April 2023 (UTC)
Nice! Thanks for revising and creating the test filter. 0xDeadbeef→∞ (talk to me) 05:02, 4 April 2023 (UTC)
Thank you! That seems to be catching one every few minutes, ranging from content-free to generic insult to slightly disturbing with no obvious false positives. Certes (talk) 13:06, 4 April 2023 (UTC)
See Wikipedia:Edit filter noticeboard#Setting 1245 to disallow?. Galobtter (pingó mió) 19:47, 5 April 2023 (UTC)
 Done the filter has been set to disallow. Galobtter (pingó mió) 04:19, 6 April 2023 (UTC)

Interstate 20 spam link

  • Task: Prevent insertion of i20accidents.com/i20-accidents into the Interstate 20 article
  • Reason: Several IPs from the same general range of addresses in Bangladesh keep adding a link to a website ostensibly run by a law firm seeking clients related to vehicle accidents on I-20. Once the link was added to the external links section, but typically it is inserted as a reference even though it is clearly not an RS nor does it reference the content of the article.
  • Diffs:

Imzadi 1979 → 19:08, 5 March 2023 (UTC)

@Imzadi1979: Is the spam blacklist talk not a superior venue for this report? – dudhhr talk contribs (he/they) 16:11, 9 March 2023 (UTC)
Request moved there, thanks! Imzadi 1979 → 19:54, 9 March 2023 (UTC)

Prevent removal of talk page headers

  • Task: Identify when an editor removes all items in a talk page header or removes a portion in a way that breaks a template
  • Reason: It's not uncommon for inexperienced editors to remove a talk header while trying to use a talk page. Many of these edits go undetected for a long time.
  • Diffs: Special:Diff/1105054073, Special:Diff/1136030142, Special:Diff/1084946475

Thebiguglyalien (talk) 00:34, 23 February 2023 (UTC)

Monitoring removal of all WikiProject banners at Special:AbuseFilter/953; let's see what's going on and what can be done. There might be some potential for a filter similar to Special:Abusefilter/957. I think really this is a mobile UX bug, where it is really easy to edit the first section of a page by hitting the edit button at the top. Galobtter (pingó mió) 03:24, 25 March 2023 (UTC)
Seems to catch a decent bit, so now testing at Special:AbuseFilter/1243. Galobtter (pingó mió) 08:16, 31 March 2023 (UTC)
 Done. Set to disallow per Wikipedia:Edit_filter_noticeboard#Set_1243_to_disallow?. Galobtter (talk) 05:23, 13 April 2023 (UTC)

Bad words to possibly add

"trann(y|ie)", "libtard": rarely seen in legitimate edits from new users. Requested previously but got no response. 137a (talk • edits) 18:00, 12 April 2023 (UTC)

Also, is this still an issue?137a (talk • edits) 18:02, 12 April 2023 (UTC)

do you have diffs of those being used? Galobtter (talk) 22:32, 12 April 2023 (UTC)
"Libtard" seems to have dimished quite a lot recently. I suspect the hard of thinking have just moved on to calling everything they don't like "woke", a bit like 10-year-old kids in the early 2000s calling everything "gay". Black Kite (talk) 07:16, 13 April 2023 (UTC)
I am struggling to find edits where these words are used, can you link some diffs @137a? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:49, 15 April 2023 (UTC)
Idea is not well explained No reply. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:17, 8 May 2023 (UTC)

Reverting administrator filter

  • Task: This filter would apply to all pages in all namespaces. It would be a tag only filter for non-confirmed users undoing edits by an administrator.
  • Reason: This would help users who use edit filters to identify vandalism to find users reverting administrators edits. This will allow them to review the edit as it is probably problematic.
  • Diffs: I couldn’t find any specific diffs, but this is a clear and obvious vandalism tag-only filter.

- 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:42, 8 May 2023 (UTC)

I don't like this. Non-confirmed users can still get in perfectly reasonable disputes with administrators. Admins are trusted to perform administrative actions, but it's impossible to be perfect with editing content, even if someone is an administrator. 0xDeadbeef→∞ (talk to me) 00:02, 9 May 2023 (UTC)
I agree with all the concerns you have raised, especially the part that administrators are fallible. In 95% of cases, you shouldn’t revert an administrators edits if you are not confirmed, and if you do this filter will only tag, so I don’t see a problem. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:13, 9 May 2023 (UTC)
It goes well beyond just content issues, +sysop does not immunize you from fat-fingered mistakes, I've reverted a number of sysops over the years and some even thanked me for it. If your looking for a reason though, tag filters have a cost in editor time and unless they are catching something that is otherwise slipping through, that editor time is going to be more efficiently used monitoring other things, or if they aren't monitored just push us closer to the condition limit for no reason.
I would need to see some clear examples of edits that this filter would catch but are not already being caught by other means before I'd consider supporting this. 74.73.224.126 (talk) 03:21, 9 May 2023 (UTC)
As others have pointed out, this is problematic in general. One specific case is where an administrator adds a message to a new user or IP's talk page, then the recipient notes and deletes it quite properly. Certes (talk) 14:22, 9 May 2023 (UTC)
I tend to agree with those above, but mainly I wish to raise the meta point that the edit filter can't determine much about who is being reverted, except sometimes their username, and having a filter containing all 861 admin usernames is not reasonable. Technically, it's a non-starter. -- zzuuzz (talk) 14:36, 9 May 2023 (UTC)
And this sort of thing already exists (or should exist) for anti-vandal scripts and tools. Having used Huggle when reviewing an edit the history does give different icon color to different user groups so that should be fine. I think we should also look at how ORES looks at those edits and maybe ORES will generally rate them as more problematic than others. 0xDeadbeef→∞ (talk to me) 14:41, 9 May 2023 (UTC)
 Request withdrawn per the concerns above. Great points everyone! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:19, 9 May 2023 (UTC)

Flag of Indian Kashmir

Please review your content that is totally incorrect. 49.36.184.190 (talk) 12:17, 12 May 2023 (UTC)

You tried to add a nonexistent file, which triggered an edit filter set to warn. – dudhhr talk contribs (he/they) 18:30, 12 May 2023 (UTC)

Edit summary indicates possible use of ChatGPT or a similar large language model

  • Task: Eventually, tag edits by IP editors and non-(auto)confirmed editors with an edit summary that suggests use of a large language model, e.g. by including text like "ChatGPT", "human-like AI", "GPT-4" or "Large Language Model" in the edit summary with something like "Possible use of Large Language Model". Probably should start out as logging to see how widespread it even is vs. the number of false positives (like edits to subject-relevant articles & reverts of AI-edits)
  • Reason: Most ChatGPT/LLM/AI-written edits (especially those by editors unfamiliar with the standards of Wikipedia) need reverting, and the rest of them still needs a thorough check due to the potential pitfalls of AI-generated content. While nowhere near all of them indicate the use of a LLM in the edit summary, being able to easily find at least a portion of them is still an improvement.
  • Diffs: Due to the inability to search for edit summaries, I only have a single sort-of example at hands, which shows the type of edit summary I mean, even if the actual edit was a different kind of problematic edit: GPT-spam. AddWittyNameHere 03:06, 16 May 2023 (UTC)
    Could probably do something like:
    !("confirmed" in user_groups) &
    (
    bad_word := "GPT”
    match := get_matches(bad_word, summary);
    match[0] & !(match[0] in old_wikitext)
    )
    Make changes as nessesary. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:18, 18 May 2023 (UTC)
    From what I understand of it (writing edit filters isn't something I've got any experience in), seems to do about what I'm looking for, yeah (other than the GBT part which I assume is a typo for GPT) AddWittyNameHere 10:22, 18 May 2023 (UTC)
    trout Self-trout because I can’t spell GPT. We may want to add something like: page_name ! contain “GPT” to avoid false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:34, 18 May 2023 (UTC)
    Maybe exclude anything in Category:Large language models too, to cut down on false positives? Even on those not actually named GPT-something, there'd be plenty of situations in which GPT in the edit summary would be perfectly relevant, I guess. (If that's possible—I'd assume so—and not too expensive compared to its benefits—no clue, I'll leave that to y'all edit filter experts) AddWittyNameHere 11:06, 18 May 2023 (UTC)
    edit filters have no knowledge about categories. 0xDeadbeef→∞ (talk to me) 12:23, 18 May 2023 (UTC)
    Oops, it can still check for a category link (in the wikitext) but not for categories added by templates and etc. 0xDeadbeef→∞ (talk to me) 12:23, 18 May 2023 (UTC)
    Can you create the filter @0xDeadbeef? I have supplied some basic REGEX code to start and @AddWittyNameHere has made some suggestions. Whenever you get a chance, please go ahead and create it because I have also seen the editing AWNH speaks of. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:13, 19 May 2023 (UTC)
    I personally agree with Suffusion of Yellow's sentiment below and I think this should be created if there is a consensus to do so. 0xDeadbeef→∞ (talk to me) 18:30, 20 May 2023 (UTC)
    Let's ask the obvious question: Do we want to tag these edits? Seems kind of like detecting paid editing by looking for "paid editing" in the edit summary. Only the "honest" people are going to do that. And if you start tagging their edits, they might become less honest. AFAIK, the only way to reliably detect AI-written content is another AI. This seems almost like a desperation measure. See also evil bit. Suffusion of Yellow (talk) 00:23, 19 May 2023 (UTC)
    @Suffusion of Yellow Yes, this won't catch deliberately-deceptive, or maliciously-LLM-using (e.g. deliberate hoaxing) people, barring the occasional exceptionally sloppy case of it. But catching those was also not really my aim in proposing this filter.
    I think, for the type of edit(or)s I'm hoping to catch with this filter, a better comparison than paid editing is the history of issues we had on en.wiki with the content translation tool before it was disabled for non-EC editors: people using a tool with the best of intentions, but without the necessary knowledge to understand its limitations, pitfalls, or what additional measures and considerations need to be taken into account when using it. Ignorance, rather than deception or malice.
    Plenty of those folks will, once told that the way they're using the tool is not compatible with the rules of this place, happily stop doing so, because they were trying to improve the encyclopedia even if in effect they made it worse; and some might actually become productive editors. But that does mean someone needs to actually tell them, and for that someone needs to notice them first. Sure, an edit filter like this will only catch a portion even of the well-meaning editors. But correcting a portion of them early on can still mean a fair bit of effort saved down the line.
    Or at least, that's my view and intention in proposing the filter.AddWittyNameHere 05:45, 19 May 2023 (UTC)
    @AddWittyNameHere How does the inclusion of phrases like "ChatGPT" in the edit summary show that the edit was produced by ChatGPT? The two things seem almost unrelated to me. LLM output does not include those phrases by default, so I don't know why it would be a good idea to look for them - they probably won't exist. I imagine the false positive ratio would be astronomical, you're far more likely to see an edit summary like "removing ChatGPT generated rubbish" than "This edit was written by ChatGPT".
    This seems a bit like trying to populate an "edit made from a windows PC" tag by looking for edit summaries that contain the words "Microsoft" or "Internet explorer".
    I do agree that we're going to have a big problem with LLM generated content in the future, I've seen the problems with the output it generates and I've noticed sockpuppets using it to avoid detection, but I think this is the wrong approach. I think a much better approach would be either updating mw:ORES to look for AI generated content or creating a standalone tool to look for AI generated edits, in the style of WP:CopyPatrol. There are bits of software that claim to be able to detect AI generated text, though it's not clear what the false positive ratio would be. 192.76.8.64 (talk) 00:11, 21 May 2023 (UTC)
    If you are concerned about false positives, this would be a tag only filter, probably, and we could make it only apply to non-autoconfirmed users. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:14, 21 May 2023 (UTC)
    @Illusion Flame I don't see how restricting this to autoconfirmed editors fixes the fundamental problem - the edit filter is looking for something that probably won't exist in the edits it is supposed to be tagging.
    If you ask ChatGPT to write an article on something then copy and paste its output into Wikipedia the edit will not include any of phrases mentioned in the op, nor will it contain any other kind of specific content we could look for. As I said, this is like trying to figure out which editors are using Microsoft Windows by looking for people using the words "Internet Explorer"
    The tag this would produce would be pointless, because the thing the filter is looking for is essentially unrelated to the condition in the filter. You would end up incorrectly tagging massive amounts of edits from people editing about/discussing LLM's while missing a load of AI generated articles.
    Integrating something like GPTZero into the recent changes feed via ORES or building a tool around it allowing people to review suspicious edits seem like much better options to me. 192.76.8.64 (talk) 00:28, 21 May 2023 (UTC)
    Think about this scenario: A users asks ChatGPT to write an article about cats. They then paste it onto the page about Cats. They use the edit summary “chatgpt wrote this”. This is what the filter is hoping to track. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:33, 21 May 2023 (UTC)
    Yes, I understand that. Have you read what I've been saying - I mention this in my first comment here.
    The point is that a massive proportion of people using AI models will not use edit summaries like this, and these kind of phrases do not appear in the LLM output - this makes this an extremely poor detection method. I've seen quite a few cases of editors using LLMs to edit ending up at noticeboards now and I can't recall a single one of them admitting what they were doing in the edit summary. There will, however, be a massive number of people using edit summaries like "removing ChatGPT generated content", "adding a section on using ChatGPT" or "Tagging article for deletion as an AI generated hoax" - you are going to end up with a tag that is almost entirely false positives. 192.76.8.64 (talk) 00:43, 21 May 2023 (UTC)
    N Denied per 192.76.8.64 above. Most users won’t have it in their edit summary, lots of false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:47, 21 May 2023 (UTC)
    Yeah, guess you're right. Pretty sure I've seen a few cases that would've been caught by a filter like this (but pretty much impossible to find those back because of the lack of ability to search on edit summaries alone), but I guess 192.76.8.64 certainly does have a fair point about false positives. AddWittyNameHere 02:09, 21 May 2023 (UTC)
    I have also seen a few cases, but not as many to justify creating a filter to tag them. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:10, 21 May 2023 (UTC)

"Za" vandalism

  • Task: This filter is supposed to prevent the addition of, or replacement of words or phrases in an article with "Za".
  • Reason: Recently, numerous IPs (likely same editor using multiple IPs) have begun adding and replacing parts of an article with "Za" in the Article and WP: namespaces. Such edits are disruptive and should be prevented.
  • Diffs: The first diff I came across with this vandalism. Initially mistook it for a test edit, until it continued. Later, the vandalism became more widespread, beginning to break templates, and extending into the WP: namespace.

ChrisWx (talk - contribs) 00:58, 22 May 2023 (UTC)

Did you see any instances of that vandalism outside of this this range? If not, a rangeblock should suffice. OhNoitsJamie Talk 01:07, 22 May 2023 (UTC)
I haven't, and you're right, a rangeblock would likely be best for this situation. ChrisWx (talk - contribs) 01:11, 22 May 2023 (UTC)
If vandalism does continue outside of this range, this filter will be requested again, but for the time being,  Request withdrawn per Jamie's rangeblock. ChrisWx (talk - contribs) 01:12, 22 May 2023 (UTC)

Adding broken harvnb-sfn cites

Now, there probably isn't a way to do this that doesn't involve creating false positives. However, I do think this is worth discussing and maybe testing out.

Basically, I want to combat against good faith edits like this which add material from another article but which introduce harv errors. It's pretty time-consuming to fix these because only the author really knows what source they were trying to cite. However, if they could be warned before they publish their edit that the footnote's link is broken, they could be prodded into fixing it themselves. Otherwise, folks like me have to fix it by going through the entire edit history to try and (hopefully) see where the citation was copied from to finally be able to put the source into the article properly.

An editor filter which theoretically checked new text to see it includes a harv/sfn template and then checks to see if it matches an expected ref on the page, would greatly aid bringing down Category:Harv and Sfn no-target errors for the future. –MJL ‐Talk‐☖ 21:19, 26 May 2023 (UTC)

@MJL: This might be possible. I'm gathering some data at 1014 (hist · log), which I'll use to test some ideas once there are enough hits. Some quesitons:
  • Are "multiple target" errors really common enough to worry about? There are only 10 page in Category:Harv and Sfn multiple-target errors right now. "No target" errors seem easier to check for.
  • What's more common? People adding a {{sfn}} template, with no associated {{cite}}? Or people removing a {{cite}}, not realizing that there's still a {{sfn}} pointing to it? Suffusion of Yellow (talk) 18:47, 27 May 2023 (UTC)
@MJL: Now a more refined filter at 1254 (hist · log). Both no-target and multiple-target errors are detected. But the filter has a few limitations: If there's already a broken {{sfn}} on the page, it will only detect a new one being added if it's before the old one. And it doesn't detect problems caused by removing or altering the {{cite}}. Incidentally, I highly recommend User:Nardog/CatChangesViewer. Suffusion of Yellow (talk) 18:51, 28 May 2023 (UTC)
@Suffusion of Yellow: Awesome! Thank you for both the script recommendation and the filter!
To answer you question, multiple-target errors certainly occur but are very infrequent as you might have guessed.
I would say people adding {{sfn}} templates with no associated {{cite}} templates are much more common than people removing {{cite}} templates with still existing {{sfn}} templates. The latter generally only occurs when the reference the {{sfn}} is pointing to is also a footnote in another section of the article (which gets removed at some point). That's very much not as common as just placing the {{cite}} template at the bottom of the page.
Your work is very much appreciated! –MJL ‐Talk‐☖ 19:24, 28 May 2023 (UTC)
I'll be watching/monitoring the filter, and if I notice anything that could be improved in a few months, I'll post to WP:EF/N with recommendations. Cheers, –MJL ‐Talk‐☖ 19:26, 28 May 2023 (UTC)

Filmcompanion

Trivial construct (maybe, add a case to an existing filter?):

  • Disallow addition of any links from the domain filmcompanion.in by non-confirmed users.

See consensus at at this thread. Thanks, TrangaBellam (talk) 16:10, 20 May 2023 (UTC)

I've created Special:AbuseFilter/1252, but have not enabled it since an admin should be responsible for assessing the consensus over there, and also a custom disallow message should be created (or used from somewhere else that I can't find where). 0xDeadbeef→∞ (talk to me) 18:42, 20 May 2023 (UTC)
@0xDeadbeef: Thanks. There should be no harm in leaving that enabled, in log-only mode. I generally don't worry about consensus for log-only filters (just BRD like anything else); for disallowing filters leaving a message at WP:EFN for a week or so should be sufficient. Suffusion of Yellow (talk) 19:42, 20 May 2023 (UTC)
The link in question is blacklisted as of now; this EF is a compromise to allow established editors add links from the site but prevent link spamming. So, we can probably waive off the usual one-week-requirement for disallowing filters. TrangaBellam (talk) 10:07, 21 May 2023 (UTC)

Any updates? TrangaBellam (talk) 11:02, 29 May 2023 (UTC)

The filter is supposed to be working correctly. But since the link is still in the spam blacklist, it's not going to catch any edit (I think? or does spam blacklist run after filters). 0xDeadbeef→∞ (talk to me) 11:39, 29 May 2023 (UTC)
Huh. A few years ago, at least, adding a blacklisted link and tripping a filter would create an entry at both the filter log and spam blacklist log. But not any more, it would seem. There's no filter hit corresponding to [14]. I don't know whether to call that a bug or a feature. And yes, people are trying to add the link; just CTRL-F at [15]. Suffusion of Yellow (talk) 20:43, 29 May 2023 (UTC)
@Black Kite: The filter is all set. So, please proceed with the removal of the domain from Blacklist? TrangaBellam (talk) 18:54, 31 May 2023 (UTC)
@TrangaBellam and 0xDeadbeef: Someone still needs to post at WP:EFN with the proposed "disallowed" message, unless you don't mind letting all editors add these links while the filter is under discussion. Examples at Special:Prefixindex/MediaWiki:Abusefilter-disallowed and Special:Prefixindex/MediaWiki:Abusefilter-warning. Suffusion of Yellow (talk) 01:15, 1 June 2023 (UTC)

Slavic profanity

Have seen a bit of this sort of thing around lately. The particular term here is "ХУЙ" (KHUY), which is Russian for "FUCK". Mako001 (C)  (T)  🇺🇦 00:07, 14 May 2023 (UTC)

Instead of creating a filter for this purpose, why don’t we add “ХУЙ” as a hit for a current profanity filter. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:47, 14 May 2023 (UTC)
@Illusion Flame: Perhaps I should have said so, but that was the intention. No need to push us even closer to the condition limit for something that an existing filter can handle. Mako001 (C)  (T)  🇺🇦 04:37, 5 June 2023 (UTC)
Thanks for suggesting a change, but this page is for filter creation requests only. Please make a request on the Edit filter noticeboard suggesting an addition to the profanity filter. Thanks! - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:21, 5 June 2023 (UTC)

Prevent or warn on Use of nowiki tags around URLs in refs

  • Task: The filter would warn or disallow activate on the use of nowiki tags around URLs in references. It would apply to all users.
  • Reason: Whilst such edits are not themselves harmful (although they do make it harder to access the URL), this is used to bypass other filters that look at the "links-added" parameter, including the "RS linked through proxy" filter, the spam blacklist, and the "unreliable/predatory source" filter.
I cannot think of any legitimate need to use this sort of formatting in the ref, if you need to use such sites in the references, then that is what the whitelists are for. Some editors seem to frequently use this sort of formatting for all refs, and this is obviously an issue, as when they add a blacklisted link or add a proxy URL, they are completely oblivious. However, in some cases below, the users spam blacklist logs, as well as other evidence, suggests that they are aware that a filter or blacklist would prevent the addition of the link, but intentionally bypass it anyway. Most of these edits were tagged as "nowiki added", but finding these problematic additions amongst the noise of other nowikis being added isn't really an option. I have also seen URLs within citation templates nowiki-ed, so a filter would need to take that into account as well.
At best, putting a ref URL in nowiki tags makes the url difficult to navigate to and impedes accessibility. At worst, it slips blacklisted and proxy URLs into the article almost unnoticed, impacting verifiability and leaving content sourced to garbage sources, or making it inaccessible to almost all readers.

Mako001 (C)  (T)  🇺🇦 06:36, 5 June 2023 (UTC)

I am neutral about the filter creation itself, but I don’t think the filter should disallow/warn users. There could be good faith newer editors incorrectly trying to add references that become discouraged upon having their edit disallowed. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:19, 5 June 2023 (UTC)
It could be set to tag-only, but it is a pain if it is used to bypass blacklisting and add proxy URLs, especially since those who do so often hit another filter first, then put the URL in nowiki tags to avoid it. Any sort of potential warning would be a very softly-worded one. That said, tag or log-only would be far better than nothing at all, so I've amended the request accordingly. Mako001 (C)  (T)  🇺🇦 00:10, 11 June 2023 (UTC)
Okay. I’ll ping some Edit filter managers to help get this expedited: @Suffusion of Yellow: and @0xDeadbeef: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:07, 11 June 2023 (UTC)

pen1s vandalism filter

Task: Block edits by non-confirmed users or IPs which contain the word "pen1s"
Reason: The word "pen1s" has been used by multiple IPs to vandalize seemingly random articles. May want to put this in a related filter (e.g. one relating to genitalia)
Diffs: On USS Newport News, On Phobia (Breaking Benjamin album)
Capsulecap (talk • contribs) 20:01, 16 June 2023 (UTC)

Looks good to me. I’ll ping @0xDeadbeef and @Suffusion of Yellow for comments and addition. This will probably just be added to an existing filter, if that’s alright. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:15, 18 June 2023 (UTC)
I've already added this to the misc LTAs filter. — Ingenuity (talk • contribs) 00:19, 18 June 2023 (UTC)
Okay, although this would probably be a better fit for the bad word or other vandalism filter. It isn’t really an LTA issue, I don’t think @Ingenuity. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:30, 18 June 2023 (UTC)
Eh, doesn't really matter. If someone wants to move it that's fine with me. — Ingenuity (talk • contribs) 00:41, 18 June 2023 (UTC)
I guess you’re right, it doesn’t matter that much. I just like to be very organized :) - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:43, 18 June 2023 (UTC)

Modification to '#WPWP (throttle)' filter

  • Task: Filter: 1158
  • Reason: I'd like to request for modification to this filter on behalf of the #WPWP contest organizers.
Based on evaluation of previous campaigns and issues raised on this wiki, we have made new changes to the campaign rules this year and one of the changes is specifically regarding participation on English Wikipedia. Eligibility rules now require a user to be extended-confirmed (WP:XC) before participating on this wiki. So Instead of uniform throttling edits for all users, we'd like it to request for help in enforcing this new eligibilty rule by disallowing edits from users who are not extended-confirmed and raising the daily limit to 100 edits (from current 25).
I'd like to note that when this filter was introduced in 2021 the campaign allowed brand-new editors to participate which led to most of the issues due to lack of experience. This is no longer the case. We have already changed that since last year (see my comment here [16]) to require having account for at least a year to allow participants gain real editing experience prior to the campaign proper and assimilate community values. With the last years' changes we have seen improvements and significant decrease in abuse and competency-related issues. This year we would like to further make this change to allow experienced users participate more freely while preserving the intent of the filter for the inexperienced users.
  • Diffs:

– Ammarpad (talk) 17:04, 14 June 2023 (UTC)

This page is for requesting new filters only. Please request filter changes on the WP:Edit filter noticeboard. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 18:30, 14 June 2023 (UTC)
Regardless, if an EF manager is passing by, can you edit 1158 for extended-confirmed only? That would sort the main problem straight away. Black Kite (talk) 19:02, 14 June 2023 (UTC)
@Illusion Flame, sorry, I misread this. It looked like it says If you wish to request an edit to filter, please post at Wikipedia:Edit filter/Requested. I should have read better. I'll leave it here now per Black Kite.– Ammarpad (talk) 21:10, 14 June 2023 (UTC)
That’s fine! Just so you know for the future. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 21:15, 14 June 2023 (UTC)
Pinging recent editors of the filter: @ProcrastinatingReader and Firefly: . – Ammarpad (talk) 08:00, 19 June 2023 (UTC)
@Black Kite and others - have implemented the extended-confirmed restriction in Special:AbuseFilter/1258 so as not to overwrite 1158 if it turns out we still need it. I have not yet enabled 1158 (the throttle filter). Will flag all this at AN as 1158 was created to implement a community decision. firefly ( t · c ) 09:40, 2 July 2023 (UTC)
Flagged at AN firefly ( t · c ) 10:09, 2 July 2023 (UTC)

Prevent non-AfC reviewer from declining or accepting AfC submission

Criteria:

AfC reviewers must have:

  • a Wikipedia account at least 90 days old.
  • a minimum of 500 undeleted edits to articles (this is not the same as total number of edits).
  • thoroughly read and understood the reviewing instructions.
  • a demonstrated understanding of the policies and guidelines mentioned in the reviewing instructions, including the various notability guidelines.
  • reasonable evidence of understanding the deletion policy (experience in areas such as CSD/AfD/PROD or page curation, while not mandatory, are beneficial).
  • a willingness and ability to respond in a timely manner to questions about their reviews.
— Notice to prospective Articles for Creation reviewers, Wikipedia:WikiProject Articles for creation/Participants

Vitaium (talk) 14:54, 19 June 2023 (UTC)

Needs wider discussion Currently AFC only strongly discourages non-afc reviewers from reviewing drafts. It doesn’t completely disallow it. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:10, 20 June 2023 (UTC)
Vitaium proposes that only non-EC users should be disallowed by the filter. Extended-confirmed non-AFC reviewer users would be unaffected (and, on the technical side of things, AFC review is checked through a Wikipedia page rather than a user-right, which I believe is harder to implement into a filter's conditions). – dudhhr talk contribs (he/they) 03:00, 20 June 2023 (UTC)
I know, but I still think wider discussion is needed to make the change. And you’re right, I hadn’t even considered that it will be very difficult to create the filter because there isn’t a user right that comes with AFC reviewing. I don’t now how this would work myself, so this would be Impossible unless someone else has another idea. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:54, 20 June 2023 (UTC)
Yeah, agreed, the lack of an official MediaWiki permission for AFC reviewers probably means a filter can't be created for this. –Novem Linguae (talk) 09:09, 29 June 2023 (UTC)
Consensus on whether or not this ought be mandatory aside, I don't think a filter to help with this is impossible per se.
  1. One could exempt admins and NPRs from the filter and then simply hardcode a list of non-admin, non-NPR reviewers into it. If one then checks the user_name variable against that hardcoded list, it could technically be possible. My concerns with this approach are that it would require unusually active maintenance for an edit filter and would drive up the condition count as a result of the long, hard-coded list (there's about 150 users with access to the AfC script that have neither NPR nor admin).
  2. An alternative could be to write a filter that disallows users who are not extended-confirmed the ability to do this sort of thing. Since AFC reviewers are 90+ day-old accounts with >500 undeleted edits, all of them have to be extended-confirmed at minimum. The downside of this approach is that it would allow through edits from ECP'd accounts w/o permission to use the AfC script.
Neither of these are perfect, but these sorts of approaches could be a way forward if the community wants something like this. — Red-tailed hawk (nest) 00:35, 1 July 2023 (UTC)
If this is done, I’m leaning towards opinion 2 that @Red-tailed hawk provided. I still think that wider discussion is needed before either filter is created. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:13, 1 July 2023 (UTC)
I also would lean that way. Might be worth creating a tracking filter along the lines of #2, to better understand the frequency of this sort of thing, before opening a discussion on whether or not to disallow/warn users for doing this. If we're dealing with something that happens once per fortnight, the extent of damage may be so low as to not even warrant an active tracking filter. If this is happening all the time, and only with particularly spammy drafts, then having that data might also better inform future discussions. — Red-tailed hawk (nest) 04:52, 3 July 2023 (UTC)
Anecdotally speaking, we're pretty good about nipping this in the bud, and while I don't have any numbers to support the idea that this isn't an issue, I would be surprised if it requires an edit filter to stop folks from doing it. Primefac (talk) 14:18, 3 July 2023 (UTC)
#1 wouldn't be a good maintenance to value ratio. The list of AFC reviewers that aren't NPPs or admins is updated frequently. –Novem Linguae (talk) 05:47, 3 July 2023 (UTC)
@Novem Linguae: Would the following work?
/** user is not EC or admin **/
!contains_any(user_groups, "extendedconfirmed", "sysop") &
/** namespace is User or Draft **/
equals_to_any(page_namespace, 2, 118) &
/** syntax added when a draft is reviewed **/
contains_any(lcase(added_lines), "{{afc submission|d|", "{{afc submission/declined", "{{afc submission|reject", "{{afc submission/rejected", "{{afc submission/created")

– dudhhr talk contribs (he/they) 06:43, 3 July 2023 (UTC)

I'm not sure Template:AfC submission/created is needed. I also think we should pause and get consensus from WT:AFC before proceeding further. Seems odd to make an edit filter affecting AFC without asking them. I'll drop a note. Note that I am neutral on this so far and was just providing some technical advice. Note that WP:AFCP states Editors whose usernames are not on the list are strongly cautioned not to review AfC submissions which is not an absolute prohibition on non-AFCers reviewing drafts, although I wouldn't mind tightening that. In the event that there is not consensus to block these edits, having a tag and a log could be useful. –Novem Linguae (talk) 07:37, 3 July 2023 (UTC)
Thanks for notifying AFC. I agree that we should consult them first. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:28, 3 July 2023 (UTC)
dudhhr, your example is problematic; if for example a new user blanks their (declined) draft, and then decides to restore it, they would be prohibited from doing so, because they would be "adding a decline notice". Primefac (talk) 14:21, 3 July 2023 (UTC) With apologies to bradv who pointed this out to me... I replied before he could... soz...
@Primefac: Thanks. All of the draft declines that I looked at in my afc log change the page size by <400. Maybe add an edit_delta < 400 condition to prevent unblanking from triggering the filter? – dudhhr talk contribs (he/they) 15:42, 3 July 2023 (UTC)
Then the filter could be easily circumvented simply by adding a comment. I'm struggling to see the benefit of this filter – unless someone can demonstrate that unauthorized declines is a significant problem, the downside risk of usability errors introduced by the filter is likely too high. – bradv 15:54, 3 July 2023 (UTC)
I too struggle to see the benefit. If a decline by a non-reviewer is bad, it can just be reverted by a recent changes patroller. – dudhhr talk contribs (he/they) 16:45, 3 July 2023 (UTC)

Warn on talk page creations for AfD entries

  • Task: When a new user attempts to create a talk page under an AfD entry, give them a notice stating that any discussion should take place on the main AfD entry.
  • Reason: To hopefully push people in the right direction when it comes to AfD contributions.
  • Diffs: Only one, which is here. There might be more cases that I'm not aware of.

Deauthorized. (talk) 18:32, 17 July 2023 (UTC)

Maybe this would be a better job for edit notices? I haven’t noticed this as a huge issue, so I’m not sure a filter would be necessary. Definitely would like to hear other’s opinions. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:40, 18 July 2023 (UTC)
@Illusion Flame: Apparently group notices are a feature, which extends edit notices to every sub-page within a page. Perhaps one for Wikipedia talk:Articles for deletion would work. Though I'm sure I'd have to propose it somewhere. Deauthorized. (talk) 06:13, 19 July 2023 (UTC)
Yes, I think this is probably better than an edit filter, which applies to all edits. Maybe start a discussion on WT:AFD. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 12:29, 19 July 2023 (UTC)

Nazi flag LTA

  • Task: Edit filter for image vandalism
  • Reason: Abuse of widely-used images that can't reasonably be blacklisted by LTA, via proxies. If there's a suitable existing EF that this can be added to, so much the better.
  • Diffs: [17], many nearly identical edits like this [18]

Acroterion (talk) 01:52, 2 August 2023 (UTC)

Enabled 684. -- Tamzin[cetacean needed] (she|they|xe) 03:33, 2 August 2023 (UTC)

Addition of external links by new users

This would make it easier to detect spam. As far as I can tell, no such filter currently exists. Partofthemachine (talk) 23:31, 28 June 2023 (UTC)

It would also make it harder to add citations. How do we tell the difference? If certain sites are a problem, we have a spam blacklist and a CAPTCHA system. Certes (talk) 08:29, 29 June 2023 (UTC)
I get the impression this would be a log-only filter, but maybe I am misreading. Partofthemachine, can you clarify? –Novem Linguae (talk) 09:06, 29 June 2023 (UTC)
Idea is not well explained. Please follow the format at the top of this page. Some diffs of the issue, along with specifics of what you mean by “new users” and what actions you believe the filter should take would be great. We currently have a filter for new users adding links containing their username, which helps stop a lot of spam. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:47, 29 June 2023 (UTC)
Yes, it would be log-only, and only apply to external links outside of a <ref> tag. Partofthemachine (talk) 19:50, 29 June 2023 (UTC)
Would you also want it to exclude external links in the external links section? only apply to external links outside of a <ref> tag. This might be too complicated for an edit filter. –Novem Linguae (talk) 21:20, 29 June 2023 (UTC)
Looks like this already exists; see Special:AbuseFilter/80, which adds the tag repeated addition of external links by non-autoconfirmed user. — Ingenuity (talk • contribs) 21:48, 29 June 2023 (UTC)
Okay so this is Redundant. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:09, 30 June 2023 (UTC)

A version of this I would find very useful would be "brand new editor adding an external link with their first edit" just as a log. At the moment I go through the User Creation Log twice a day and I reckon that 90% of new editors who actually edit add a clear spam link. They might be bots, but I get the impression that it's paid work on some Fivver-style site. Here are three from the last hour or so: cheap visas betting site blog.

A log (or an edit tag, I suppose) would help me (and others, obvs) find them quicker and save a fair bit of clicking around. — Trey Maturin™ 12:59, 5 August 2023 (UTC)

'Nothing to say about me really' spambot

  • Task: Preventing a spambot from adding links to their newly created user's user page.
  • Reason: Long-standing issue going back to at least 2013
  • Diffs: Example spam, Meta page on the spambot

It's not a huge problem, per se. I spot perhaps three of these a week and tag them for deletion. But the G5 template doesn't have an area to put see meta:NTSAMR in it (I put it in the edit summary instead), so other editors come along and change the tag to "something better" (a waste of everybody's time) or very busy admins, occasionally, turn down the speedy because I've not specified who the 'banned user' is (there isn't one: it's a downloadable bot).

Whilst it's a slow-burn thing, the time taken to find, tag, and delete the pages is a drain on resources when it could be Disallowed by a filter.

The Meta page has a list of filters for the spambot used on other projects, but they're all private. Perhaps there's someone here with EF viewing rights on Commons or Simple who can grab the code? — Trey Maturin™ 12:09, 5 August 2023 (UTC)

There's actually already a private filter for this (935). — Ingenuity (talk • contribs) 00:35, 7 August 2023 (UTC)
Okay. Presumably it just logs the spambot and admins periodically go through the list deleting the pages? Can it be set to Disallow instead? — Trey Maturin™ 08:59, 7 August 2023 (UTC)

Nowiki added (surrounding URLs)

Jonatan Svensson Glad (talk) 15:06, 8 August 2023 (UTC)

This looks like output from the Article wizard: does that need fixing? I've accidentally inserted nowiki tags occasionally when using well-meaning tools (I can't remember which). Certes (talk) 17:08, 8 August 2023 (UTC)

Infobox deletion filter

  • Task: Edit filter that will warn people that infoboxes shouldn't be deleted.
  • Reason: For some reason this doesn't exist. It shows up on Recent Changes very commonly. We have disallow filters for removal of article lead but not removal of infobox, this can probably be folded into that one.
  • Diffs: [19] stuff like this, often an IP will be like "wrong information" or "made it better" or no edit summary at all when doing this.

Gatemansgc (TɅ̊LK) 21:23, 2 August 2023 (UTC)

I’m thinking this is a good idea. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:18, 5 August 2023 (UTC)
The diff you give as an example looks like a completely legitimate removal of incorrect information. The information in the infobox is unsourced, contradicts the sourced information in the article and contains several blatantly incorrect statements, e.g. this person did not win the Nobel prize in economics and obviously did not invent something that is named after someone else. 192.76.8.66 (talk) 00:31, 7 August 2023 (UTC)
Switched to a better diff, also that's why it would be good to have it warn and not disallow cause then people could add BLP-violating fake infoboxes to articles and no anon would be able to remove the BLP violations. Meant to do this earlier but focus has been garbage... Gatemansgc (TɅ̊LK) 19:14, 9 August 2023 (UTC)

Filter against ethnicity removal

  • Task: Avoid removal of words "Aromanian" and "Aromanians" by new users.
  • Reason: Aromanians live in the Balkans, we all know the nationalist battlegrounds that Balkan topic areas are known to become, however the Aromanians are the only stateless and disorganized major ethnicity in the Balkans so common IP and newly registered vandalism often goes unnoticed as there's not an Aromanian base of editors in Wikipedia, or of users in the Internet really. I've went to ANI, the help desk and EFN over this.
  • Diffs: Example in Albanian biographies: [20] [21] [22] [23] [24] [25] [26] [27]. I don't think these were the same person. Examples in Greek biographies: [28] [29] [30], these are all the histories of three different articles, scroll down until you see the edit-warring, that was the abuse of a single guy with multiple accounts throughout several months, he definitively had no connection to the vandals in Albanian biographies. Super Dromaeosaurus (talk) 07:56, 12 August 2023 (UTC)

1940s nazi flag vandalism

This will not allow the nazi flag to be added to non related articles

i have seen it a lot and its just labeled vandalism

https://en.wikipedia.org/w/index.php?title=Hoshimachi_Suisei&oldid=1169503311~~~~

•Cyberwolf• 13:52, 9 August 2023 (UTC)

Probably related to a recent vandalism spree. Certes (talk) 22:39, 9 August 2023 (UTC)
Theoretically, the image could be added to the blacklist. However, it is used to produce a small flag representing Germany of that era in nearly 12,000 articles such as 1938 FIFA World Cup#List of qualified teams and can legitimately be added to others in similar contexts. Unfortunately, there are many alternative images for vandals to use if this one is prevented from appearing. Certes (talk) 22:44, 9 August 2023 (UTC)
Ugh. I regretfully agree - this is the legitimate symbol for representing Nazi Germany. Compare our article on a specific racial slur beginning with the letter N - you just have to use it in some articles.
There might be an appetite for a (private) filter that has specific exceptions (private so people don't know what they are). @Certes, what's your opinion on that? (I can think of some potential ideas for exemptions but I'm not commenting them for obvious reasons.) casualdejekyll 22:49, 9 August 2023 (UTC)
There's potential there for a private (or even public) filter. There are obvious differences between gratuitous use of the symbol to dominate an unrelated page and a historic flag within a column of national flags, even if we don't want to spell out the exact criteria for distinguishing mechanically. Certes (talk) 22:54, 9 August 2023 (UTC)
This is one of those cases where a filter will likely have the opposite of the intended effect; if you look closely at their contribs, you'll see that they're picking out filters from the list and defeating them as sort of a game. What they don't realize is that any 10-year-old could defeat most of our filters (even private ones, by trial-and-error) if they tried hard enough; filters aren't serious security measures and they prove nothing by revealing the "flaws".
Filters work great when you're dealing with 10000 people who all try the same stupid thing and then get bored; or a spammer trying to promote a specific entity. And some LTAs "try the same thing over and over and expect different results", so it's often worth a try. But if someone is just out to disrupt in any way at all, well, as they say over at WP:SPI,  The edit filter is not magic pixie dust. Just WP:RBI. Suffusion of Yellow (talk) 23:00, 9 August 2023 (UTC)
Could we black list it on user pages excluding draft •Cyberwolf• 14:38, 14 August 2023 (UTC)
Probably not. What's a draft? Use on pages like User:David Kernow/Template:World War II, User:Elmo12456/Sandbox page/Flags of the world list and User:Esdrasbarnevelt/Operation Bagration looks legitimate. Anyway, the unwanted images have appeared mainly in articles. IP edits to User: pages are rare, suspicious and reverted quickly if necessary. Or did I misunderstand "user pages"? We've dealt with the outbreaks effectively, so I have to agree that RBI seems the best way forward. Certes (talk) 19:24, 14 August 2023 (UTC)
I have seen and reverted it added to numerous talk pages •Cyberwolf• 19:26, 14 August 2023 (UTC)
I think you caught them all. The only inappropriate use I see is on the page of one user who made a handful of pro-Nazi edits in 2007 and hasn't edited since. Certes (talk) 20:39, 14 August 2023 (UTC)

Bountiful High School

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

Yeahthatguyy (talk) 15:27, 26 August 2023 (UTC) On the page for bountiful high school in bountiful utah, there are 2 players that have also gone pro for sports respectively. Zac Zeljass for Basketball who plays overseas and Parker DePasquale who plays independent minor league baseball. Both won state championships and hold records at bountiful high and they can both be found on google with information and stats to confirm their careers.

Not done – In general, "notable people" lists and similar are only meant for people who already have articles about them. If you think this person meets our notability guidelines, please see Help:Your first article. If you think an exception should be made here, please discuss the matter on the article's talk page. 0xDeadbeef→∞ (talk to me) 05:00, 27 August 2023 (UTC)

Emailed request

I have submitted a request via email. ~ Pbritti (talk) 19:51, 29 August 2023 (UTC)

Racist language

It would be nice if a filter could prevent this sort of thing. (Link contains unpleasant wording.) I expect tweaking an existing private filter would be more appropriate than adding a new one. Certes (talk) 16:51, 7 September 2023 (UTC)

Filter 861 modification / VisualEditor bug

This is a request to modify filter 861 which was approved at this RfC in 2019. The VisualEditor bug has been evolving into slightly different forms getting past the filter defenses. This search shows examples. In particular we want to stop instances like <sup>[1]</sup> which is the majority. There are some others like [[Golden Gate Park#cite note-15|<sup>[15]</sup>]]. There is an ongoing discussion at VP here. -- GreenC 15:42, 15 September 2023 (UTC)

Short descriptions on redirects

  • Task: Warn editors adding a short description to a redirect page that it will break the redirect.
  • Reason: There have recently been several cases of editors using the iOS app adding short descriptions and breaking redirects, as they do not realize that they are editing a redirect - alerting them that they will break the redirect would likely stop this from happening.
  • Diffs: [31] [32] [33]

Tollens (talk) 15:40, 30 August 2023 (UTC)

I believe the following filter would work (although I'm not well versed in the edit filter language):
user_mobile &
new_wikitext irlike "^{{short\sdescription\|.{0,100}?}}\s*\n+\s*#\s*redirect\s*\[\["
The filter should fire if a content page is replaced with a redirect and the short description remains as well as simply if a short description is added to a redirect, and also not fire if a redirect is replaced by a content page with a short description. I haven't filtered it against user groups as there have been editors of all permission levels making the same mistake, and haven't filtered it against namespaces as this mistake could happen on any page. If me drafting the filter here is inappropriate in some way, my apologies - just figured it would be interesting to write and debug it. Tollens (talk) 07:11, 8 September 2023 (UTC)
Testing at 1266 (hist · log) 0xDeadbeef→∞ (talk to me) 06:48, 17 September 2023 (UTC)
It's been a week, and there has been only one hit. The single hit was actually where someone tried to turn a redirect into an actual article. I don't think the iOS app has this issue anymore? 0xDeadbeef→∞ (talk to me) 02:09, 24 September 2023 (UTC)
Yeah, it certainly seems that way. I don't use the iOS app so I can't be certain but clearly something's changed. Tollens (talk) 02:17, 24 September 2023 (UTC)

Warning admins for deletions that don't appear to follow proper processes

An idea of using an edit filter to warn on certain deletions is currently being discussed over at Wikipedia talk:Criteria for speedy deletion#G2 in user namespace * Pppery * it has begun... 01:36, 19 September 2023 (UTC)

The following abuse filter code (lightly tested) should work for "wrong namespace": 
action = "delete" & (
    (summary rlike "WP:(CSD#)?A[0-9]+" & page_namespace != 0) | /* A* criteria only apply to mainspace */
    (summary rlike "WP:(CSD#)?F[0-9]+" & page_namespace != 6) | /* F* criteria only apply to files */
    (summary rlike "WP:(CSD#)?C[0-9]+" & page_namespace != 14) | /* C* criteria only apply to categories */
    (summary rlike "WP:(CSD#)?U[0-9]+" & !equals_to_any(page_namespace, 2, 3)) | /* U* criteria only apply to userpages/user talk pages */
    (summary rlike "G(1[^0123]|2)+" & page_namespace = 2) | /* G1 and G2 don't apply to user namspace */
    (summary contains "G13" & !equals_to_any(page_namespace, 2, 118)) | /* G13 only applies to draft and user namespace */
    (summary contains "R2" & page_namespace != 0) /* R2 only applies to mainspace*/
) & ! (summary contains "[[WP:CSD#G8|G8]]: Deleted together with the associated page with reason")
. * Pppery * it has begun... 03:37, 29 September 2023 (UTC)
Lots of false positives. A couple examples: F clause, U clause, G1/2 clause, G13 clause, R2 clause. —Cryptic 04:18, 29 September 2023 (UTC)
This should ideally be built into twinkle, or log-only because of false positives 0xDeadbeef→∞ (talk to me) 04:46, 29 September 2023 (UTC)
I think Twinkle already won't let you G1 and G2 in user namespace - see Wikipedia talk:Twinkle/Archive 40#Cheeky Twinkle! (although that's very old and things may have changed since). Also, this doesn't make sense as a log-only filter because the log already exists as a database report.
The idea (suggested by Extraordinary Writ and endorsed by Thryduulf in the linked discussion at the top of this thread) was to provide immediate feedback, not feedback potentially a long time later and only if one of the few people who care about this sort of thing chooses to raise a stink about it. Interesting to see it uncontested for 10 days over there but now attracting objections over here when I moved toward implementation. * Pppery * it has begun... 14:48, 29 September 2023 (UTC)
There's also slightly under two hundred pages in namespace 2 and Category:All disambiguation pages that could conceivably become G14 candidates, which the G1 clause will match. About half of the ones I've looked at are editing tests like L0cus.Antart1ca, about half are drafts and sandboxes like User:Star Garnet/Terrence Berg. —Cryptic 12:57, 29 September 2023 (UTC)
Valid points - I definitely should have included a \b there, and I have no idea how I missed G14 when composing the original database report (and then copied it here without further checking) - that was a clear error. * Pppery * it has begun... 14:48, 29 September 2023 (UTC)
Tightening the regexes should help: (entirely untested)
action = "delete" & (
    (summary rlike "WP:(CSD#)?A(1[01]?|[2379])\b" & page_namespace != 0) |        /* A* criteria only apply to mainspace */
    (summary rlike "WP:(CSD#)?F(11?|[2-9])\b" & page_namespace != 6) |            /* F* criteria only apply to files */
    (summary rlike "WP:(CSD#)?C[12]\b" & page_namespace != 14) |                  /* C* criteria only apply to categories */
    (summary rlike "WP:(CSD#)?U[125]\b" & !equals_to_any(page_namespace, 2, 3)) | /* U* criteria only apply to userpages/user talk pages */
    (summary rlike "WP:(CSD#)?G[12]\b" & page_namespace = 2) |                    /* G1 and G2 don't apply to user namespace */
    (summary rlike "WP:(CSD#)?G13\b" & !equals_to_any(page_namespace, 2, 118)) |  /* G13 only applies to draft and user namespace */
    (summary rlike "WP:(CSD#)?R2\b" & page_namespace != 0)                        /* R2 only applies to mainspace */
) & ! (summary contains "[[WP:CSD#G8|G8]]: Deleted together with the associated page with reason")
But I still think it would be much more effective to bring invalid speedies to DRV instead. DRV can handle the volume - it used to handle five or six complex afd appeals every day, and now often goes days between any listing at all - and it provides a paper trail for repeat offenders. This is a technological fix to a social problem, and by its nature - only admins can trigger it, and are bound by WP:ADMINACCT - people who'd trigger it should be receptive to persuasion.
We'd also want to make very sure that, if set to warn, it can be overridden, since this is very undertested compared to warning on action="edit". My own User:Cryptic/g2 subpage, for example, could've just as easily been titled User:Cryptic/WP:G2, which would still trigger a false positive if it was deleted at MFD. —Cryptic 13:59, 29 September 2023 (UTC)

Prevent curly apostrophes and quotes

The MOS says use straight apostrophes and quotes (MOS:', MOS:STRAIGHT). If someone uses them anyway, then someone else needs to fix it. Most likely, the person who used them will do so repeatedly, unless someone takes the time to ask them not to. This creates a lot of unnecessary work.

An edit filter that prevents the addition of curly punctuation would be of huge benefit. It would mean that as soon as someone uses the wrong style, they are made aware of it. Nobody would have to take the time to point out the guidelines to them; nobody would have to fix the (likely) repeated instances of incorrect style.

Obviously this may seem like a very trivial thing to have a filter for. But the curious thing is that whenever I fix incorrect punctuation style, I notice that text which includes curly quotes has a very high chance of being problematic in other respects. I really don't know why that should be, but many, many times I've found that curly quotes are contained in text which is biased, incorrect, pushing fringe POVs, promoting a person or organisation, or deliberately disruptive. So I think a filter preventing addition of curly quotes might have a much wider effect than you'd expect. 46.170.227.106 (talk) 06:04, 6 September 2023 (UTC)

A lot of file names have curly quotes. You'll need some kind of whitelist or rule exemption. - Sumanuil. (talk to me) 05:41, 9 September 2023 (UTC)
Also, mobile devices usually default to curly quotes (at least IOS does, not sure about android). Warning or disallowing edits which add curly quotes would drive away good-faith Mobile editors adding quoted text, and the curly quotes can be trivially fixed with awb. – dudhhr talkcontribssheher 05:59, 9 September 2023 (UTC)
I just tested it. Looks like Android does not. Good point about iOS though. –Novem Linguae (talk) 07:01, 9 September 2023 (UTC)
...would drive away good-faith Mobile editors... - how would it do that? I think that, if they are acting in good faith, someone who is warned that curly quotes should not be used will simply change them to straight quotes and be glad to know what the requirements are. Good faith editors want to contribute well, after all. On the other hand, someone knowingly adding biased, incorrect, promotional or disruptive text who is prevented from saving it by a simple edit filter might very well decide not to bother, and that would clearly a good thing. 51.52.241.154 (talk) 09:19, 21 September 2023 (UTC)
It would be nice if all good-faith editors persisted despite difficulties, and all vandals were easily deterred, but... Certes (talk) 12:01, 21 September 2023 (UTC)
What Wikipedia is best known for, IP editor, is its WP:SOFIXIT culture. I won't deny that MOS violations might loosely correlate with larger problems. But that correlation is never going be perfect. If an editor has something valuable to contribute, and it happens that the best they can do is write less-than-brilliant prose, we should welcome them, not demand that they fix every minor problem. A editor who likes copyediting makes a good team with an editor who struggles to write. If you find it a terrible burden fix other people's mistakes, consider changing your perspective. See the terrible writing as on opportunity to create something better. This is a big pot of stone soup which we don't pretend is finished. Suffusion of Yellow (talk) 23:01, 21 September 2023 (UTC)
Your comment seems to be greatly over-interpreting what has been proposed. Prose quality is not being discussed. And obviously there is not a perfect correlation between style errors and other problems - your straw man is not productive. The suggestion is simply that a filter to prevent curly punctuation being added would help everyone - the person adding them, the person who would otherwise have had to spend time removing them again, the reader who is delivered a more professional encyclopaedia. Good faith contributors want to contribute well. They don't want to cause unnecessary work. So if they try to make some trivial, easily-correctable mistake, why not simply automatically notify them of the mistake? Good faith contributors will be grateful. Bad faith contributors, who are disproportionately likely to make said mistake, might be discouraged to find a barrier between them and their harmful edit being saved. 51.52.241.154 (talk) 09:10, 28 September 2023 (UTC)
automatic notifications about small issues like these should absolutely be avoided if we're displaying a warning instead of saving it immediately. I don't see a problem with a log-only filter for people to watch and notify people if they repeatedly add such things, but anything above log-only I would oppose. 0xDeadbeef→∞ (talk to me) 10:19, 28 September 2023 (UTC)
"anything above log-only I would oppose" - why? 145.107.190.31 (talk) 11:45, 9 October 2023 (UTC)
Many otherwise good contributions are badly punctuated. The solution is to fix the punctuation, not discard the content wholesale. Certes (talk) 12:25, 9 October 2023 (UTC)
I think this discussion is best had elsewhere - ultimately community consensus is going to be required for any warn or disallow actions on a filter like this, so best to go and get that consensus and then come back here to request the actual filter. Sam Walton (talk) 22:04, 9 October 2023 (UTC)
"Many otherwise good contributions are badly punctuated. The solution is to fix the punctuation, not discard the content wholesale" - indeed, and that's exactly what an edit filter like this would achieve. 145.107.190.31 (talk) 07:14, 11 October 2023 (UTC)
The solution is WP:SOFIXIT, and not gate it behind some warning from an edit filter, which would discard the content, unless someone does the work to patrol it to ensure that none of the edits are lost. 0xDeadbeef→∞ (talk to me) 08:41, 11 October 2023 (UTC)
Instead of allowing an error to be made and then hoping that someone will fix it, not allowing the error to be made in the first place seems greatly preferable. How do you suppose it would involve discarding any content? I don't think anyone is proposing that. 145.107.190.31 (talk) 11:22, 11 October 2023 (UTC)
Uhh.. Because setting the filter to anything above log would display a message instead of saving a page immediately, which results in less edits going through? 0xDeadbeef→∞ (talk to me) 12:07, 11 October 2023 (UTC)
If people were prepared to discard their entire edit, rather than simply changing the curly quotes to straight ones, then it could result in fewer edits going through. Do you seriously imagine that would be a common response? 145.107.190.31 (talk) 12:58, 11 October 2023 (UTC)
The best understanding that reflects the human condition is that editing is hard, and we should try to make it as easy as possible. Countless edits in the abuse log with the level 'warn' never got through, just look for entries that don't have a "diff" link next to them. And to be honest, this isn't my imagination. Is Wikipedia really a place that should prevent people that have just enough willpower to make an edit but no more to change all curly quotes to straight ones? If you think these people don't exist, that's just your opinion man. It's unclear whether this is trolling or making an actual argument. In any case, I feel like continuing would be an inefficient use of time, so I will not engage further after this comment without another editor bringing up a good point to respond to. 0xDeadbeef→∞ (talk to me) 13:43, 11 October 2023 (UTC)

Editing is not hard at all. You can confirm that by looking at the number of edits made every minute of every day to the total of many millions of articles. Editing well is more difficult. You can see that by actually reading a typical article. Now imagine that you yourself had written some text which contained curly quotes. If you tried to save it and got a message saying "thanks for the edit but please change curly quotes to straight ones", would you seriously throw away your work entirely? 145.118.72.148 (talk) 11:43, 13 October 2023 (UTC)

sigh. 0xDeadbeef→∞ (talk to me) 12:41, 13 October 2023 (UTC)
I'd think "if this system is intelligent enough to detect curly quotes and to know what to replace them with, wouldn't running a simple s/“/"/g on my effort be easier than putting up a dialogue box?" Certes (talk) 12:42, 13 October 2023 (UTC)
I guess I should have bolded a few words in my first sentence of my reply. Sorry. This is WP:LTA/BKFIP, and I really should have just closed the discussion. There's no point in arguing further.
That said, this might not be a bad idea for mw:Edit Check if the final implementation is sufficiently unintrusive and configurable. Think of the jshint integration in the ACE editor; the little symbols in the left gutter are just irritating enough to make you want to fix the problem, but not so much that you're not going to save the page. Now the actual implementation (so far) of Edit Check could be best summarized as "WMF-controlled edit filters under a new name" but I'm still not sure if that's only a demo. In any case, keep an eye on that page. Suffusion of Yellow (talk) 22:36, 14 October 2023 (UTC)
  • {{EFR}} I am denying this request because it is not technically feasible without a large amount of false positives due to file names, and because a better solution would be to have a bot that auto-corrects this. It would've made mobile editing impossible for me until I discovered the rather obscure "smart punctuation" feature of iOS and turned it off, and doing so also has the disadvantage of not automatically changing -- to —. The requester is also likely a banned user (BKFIP).--Jasper Deng (talk) 21:32, 15 October 2023 (UTC)

New page creation by anonymous users

  • Task: this will prevent unregistered users from creating pages
  • Reason: Except Draft space
  • Diffs: Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.

92.251.26.251 (talk) 08:39, 30 September 2023 (UTC)

Unregistered users can't create pages. See WP:ACPERM. 0xDeadbeef→∞ (talk to me) 14:46, 30 September 2023 (UTC)
  • {{EFR}} as unneeded due to the existing restriction. In general, namespace-specific no-editing restrictions by user group should be done using MediaWiki configuration instead of the edit filter, because that effectively takes away from our condition limit.--Jasper Deng (talk) 22:00, 15 October 2023 (UTC)

Unblock requests with nowiki tags

Task: Identify when a user adds an unblock request template with nowiki tags to their own user talk page

Reason: When some users imperfectly copy the unblock template wikitext from the block notice and paste into the source editor, they're given a notice that what they're pasting contains rich formatting and are prompted to convert it to wikitext. If they do so, the editor adds code and nowiki tags around the block notice, preventing the template from transcluding and therefore preventing their talk page from being added to the unblock request category. If they paste using the visual editor, the code and nowiki tags are included with no prompt and are hidden unless the user changes to the source editor. Again, this prevents the template from transcluding.

Since new users may not understand what nowiki tags do or that they were included when pasting using the visual editor, their unblock requests will go unreviewed. This filter would allow experienced users to identify these cases and be able to go in and fix them so the unblock requests can be discoverable and reviewed by administrators.

Diffs:

  1. Special:Diff/1178427698
  2. Special:Diff/1146559717
  3. Special:Diff/1114599509

Something like this might work, though could probably be improved: 

page_namespace == 3 &
page_title == user_name &
added_lines contains "nowiki" &
added_lines contains "unblock"

Uhai (talk) 01:44, 4 October 2023 (UTC)

To reproduce the issue:
  1. Copy the unblock request wikitext from Template:Uw-blockindef, including some of the surrounding text. If you correctly copy only the text in the code tag in the template, the issue will not occur.
  2. Click "new section" on your own talk page and click "source"
  3. Paste and you should see the prompt to convert what you pasted to wikitext. If you do so, you will see the nowiki and code tags.
  4. Alternatively, clear the text box and change it from source to visual. If you paste, you will see the template wikitext pasted but will not see the code or nowiki tags, even though they are still there.
See User_talk:Uhai/test for an example. Uhai (talk) 02:04, 4 October 2023 (UTC)
Should we add a new tag for the suggested filter? Signed, 64andtim (any problems?) 16:44, 13 October 2023 (UTC)
Looks like Special:AbuseFilter/550 tags, so it may be beneficial to do so here as well. At the same time, though speculating without a trial of the filter to see the number of hits, I imagine this issue may be a rarer occurrence so it may not be necessary. I'm ambivalent. Uhai (talk) 13:14, 15 October 2023 (UTC)
This is not an appropriate use of the edit filter considering how hindering it can be to users getting unblocked. The ones who need to use it are often inexperienced and do not know what is going on when they encounter something like this.--Jasper Deng (talk) 21:09, 15 October 2023 (UTC)
? The whole point is that this issue does hinder users getting unblocked. The reason for the filter is to keep track of occurrences of this issue so myself and anyone else can go in and fix the broken unblock requests so they can get reviewed by admins. It's a perfectly appropriate use of the edit filter. I'm not advocating that the filter action be warn or disallow at all, it should be no action or maybe tag. Uhai (talk) 21:41, 15 October 2023 (UTC)
The reasoning for the filter in the original post was unclear so I added a sentence to hopefully elucidate what this is meant to accomplish. To reiterate: the filter should not impede anyone trying to add an unblock request with nowiki tags with a warning or a disallow, it should only keep track of this so someone can go in and fix the problem, as you can see that I've done in the three example diffs when you click "next edit". Uhai (talk) 22:16, 15 October 2023 (UTC)
As for the new suggested filter, it should be set to either log-only or tag, both without any action when trying to click the "publish changes" button. Signed, 64andtim (any problems?) 23:05, 15 October 2023 (UTC)
See filter 1271 (hist · log). There are many ways to break the template, so instead of looking for nowiki I'm looking for the absence of user-unblock-request in the html. I'm not totally opposed to a warning, if the alternative is the unblock request sitting unnoticed forever. If someone wants to actually monitor the log of this filter and fix the requests, a warning is not needed. Suffusion of Yellow (talk) 21:42, 26 October 2023 (UTC)
@Suffusion of Yellow: Thanks much. I was planning on actively monitoring the filter though I suppose I can't guarantee I'll be doing this consistently or indefinitely into the future.
Could you also add unblock-un as an OR with user-unblock-request to the filter? The unblock template for requesting a username change seems to use the former class in place of the latter. See https://en.wikipedia.org/w/index.php?title=User_talk:Polyvinylrecords&action=render. Uhai (talk) 22:45, 26 October 2023 (UTC)
Thanks for spotting that; now checking the HTML for class="[^"]*unblock. Suffusion of Yellow (talk) 23:43, 26 October 2023 (UTC)
{{resolved}} * Pppery * it has begun... 04:19, 5 November 2023 (UTC)

Disallow insertion of old-colored WP:WPTC track maps

Since User:Supportstorm, the primary maker of new track maps, has tried to fillibuster and override the consensus at Wikipedia:WikiProject Weather/Color RfC by continuing to make old-colored maps, many users have been violating the consensus to discontinue usage of the old-colored maps for new storms by inserting Supportstorm's maps, which they have designated as explicitly for other wikis and not enwiki. Example diffs are:

among countless others.

The filter conditions should be, at a high level:

  • Page was created after the RfC, or is a 2023 season page
  • Page is a tropical cyclone article (*(Hurricane|Cyclone|Typhoon)*) or other WPTC article
  • Edit is adding *track.png

or

  • Replacing *path.png with *track.png.

and the actions for now should be warn, and disallow if users keep saving the edits anyways.

Edit: A simple regex to realize this would be to look for .*202[3-9].*track\.png or .*202[3-9].*path\.png, in addition to disallowing replacement of .*path\.png with .*track\.png

As this concerns WP:WEATHER and WP:WPTC I will link this discussion at those WikiProject talk pages. It is unfortunate that we need to consider a filter to this end but I see no other way to enforce not only the RfC consensus but WP:ACCESSIBLE–the old-colored maps do not comply with that, so inserting them anew (as opposed to grandfathering in the old articles, which are going to be migrated) is in direct violation of that policy. Jasper Deng (talk) 09:03, 11 October 2023 (UTC)

  • Comment  - @Jasper Deng: I strongly feel that you are opening up a big can of worms here and that such an edit filter is unenforceable, until new maps have been made for older systems.Jason Rees (talk) 11:35, 11 October 2023 (UTC)
    It wouldn't affect the older systems that already have the maps, only the new. I would support this since this only affects new and current season articles. There is a standing consensus to not use the old colors in new articles and people should abide by it. Noah, AATalk 12:18, 11 October 2023 (UTC)
    @Hurricane Noah: As far as I can see it would impact older high impacting systems that do not currently have an article and would have to use the old map, until a new one could be created by another user as some editors including myself do not have access to the trackmap generator for various reasons.Jason Rees (talk) 13:03, 11 October 2023 (UTC)
    @Jason Rees: It could be tweaked to check that the storm year is 2023 or later, but such a filter is definitely enforceable. I am experienced with what the filter can do; you are not.--Jasper Deng (talk) 16:51, 11 October 2023 (UTC)
    @Jasper Deng: Whatever happened to assuming good faith as I am familar with what an edit filter is and what it would do. I just strongly feel that it is unenforcable until all old track maps are updated to use the new colours and not just post 2023.Jason Rees (talk) 17:05, 11 October 2023 (UTC)
    @Jason Rees: You keep saying "unenforceable" yet you are unable to provide any technical evidence. The categories and storm date can be used to filter; perhaps most simply, using the file name: 20(3-9|2(3-7)).*(track|season summary map)\.png is an example regex. You are clearly not familiar with the edit filter because otherwise you wouldn't be saying this. Good faith edits can still be disruptive, as is the case here.--Jasper Deng (talk) 17:08, 11 October 2023 (UTC)
    One possible issue could arise with the summary maps since all we have done is just remove the map word from the new names. Not sure if that would cause errors or allow some to slip by. MarioProtIV (talk/contribs) 23:33, 14 October 2023 (UTC)
    In the worst case we just don't filter them. The precise regex will have to account for that.--Jasper Deng (talk) 00:50, 15 October 2023 (UTC)
I don't see how an edit filter would be appropriate here. If someone adds the wrong image, they should be reverted and politely notified about the issue. If they continue to go against community consensus or edit war, they should be brought to the appropriate venue and blocked or topic banned. What am I missing here?
If it's about finding the presence of these images, I drafted a query at quarry:query/73157 according to the provided criteria, however there's a lot of unknowns since I can't really tell the difference as to what is the correct vs. incorrect color scheme in these maps and the RfC was quite lengthy. There's File:Daniel_2023_track.png which was created by Supportstorm but was updated in the past few days by another user, so maybe it's now correct? It still retains the track.png file name, nonetheless. There's also File:BOB01 2023 track.png which was not created or edited by Supportstorm. I'm not really sure of a reliable way to tell which articles contain incorrect maps.
It would be more dependable to do a cross-server query between enwiki and Commons using something like wikitech:PAWS (not possible with Quarry) to look for any WPTC articles that contain images that Supportstorm has created or edited, but if users are updating his images to give them the correct color scheme then this wouldn't be any good either. Uhai (talk) 13:06, 15 October 2023 (UTC)
@Uhai: It's creating a ton of work for me to be constantly reverting those edits and some editors are doing it willfully, e.g. Special:Contribs/EPicmAx4. The filter is necessary because everyone is going for the low-hanging fruit. Many filters exist that stop people from going for the low-hanging fruit.
Also, you missed my regexes that clearly allow distinguishing of them, maybe because I wasn't clear enough. Old-colored maps have the following names: <storm> 2023 track.png, 2023 <basin> season summary map.png. The new ones have <storm> 2023 path.png and 2023 <basin> season summary.png (notice no map suffix).--Jasper Deng (talk) 21:06, 15 October 2023 (UTC)
If it's being done willfully, then the user you cited should be reported and topic banned. I updated the query to account for the season summary map case but am not seeing any additional results, so if what's already appearing in the results isn't an issue, then I'm not seeing any of the incorrect maps present at the moment unless there exists an article that isn't tagged as being part of WPTC or it's a weird case of an article created before 2023 without 2023 in the title to which the new map rules should apply under the RfC.
Feel free to fork and run the query periodically on your own to more easily identify when the wrong maps are inserted into articles. I'm more than happy to accept feedback and improve it if there's false positives or false negatives in the result set. Uhai (talk) 22:04, 15 October 2023 (UTC)
@Uhai: If there aren't any incorrect maps present, it's because I've actively tracked down and reverted each and every instance. That doesn't mean there will be no more such edits.--Jasper Deng (talk) 22:19, 15 October 2023 (UTC)
Right, that's why I recommend running periodically to catch new instances easily without needing to look at the watch list or however you find them currently. Uhai (talk) 22:21, 15 October 2023 (UTC)

Prevent new users from creating talk pages for nonexistent articles and users

I've noticed lately, that because non-autoconfirmed users cannot create articles in mainspace, some try to create them in other namespaces including talk space, template space, and project space. Such pages created in talk space qualify for speedy deletion under G8, so we might as well not allow it. Perhaps an edit filter could prevent new users from creating such pages, with a message directing them to start a potential article in draftspace instead. Some have also created talk pages for nonexistent users as well, but these are often vandalism. TornadoLGS (talk) 18:18, 16 October 2023 (UTC)

Unfortunately the extension is not capable of checking whether pages or users exist, but database queries such as quarry:query/65041, quarry:query/68085, and quarry:query/68613 are available as an alternative. Uhai (talk) 19:28, 16 October 2023 (UTC)
{{EFR}}: Per Uhai, and for the bot to archive. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 11:03, 26 October 2023 (UTC)
@TornadoLGS: Perhaps Mediawiki:newarticletext could be tweaked a bit to make the "Note that the corresponding article ... does not exist" more visible in the talk namespace. Not sure how to handle nonexistent users. Suffusion of Yellow (talk) 21:57, 26 October 2023 (UTC)

Tag repeated self reversions

  • Task: If an editor rapidly reverts their own edits on a page at a level which is well beyond normal levels, then tag the edits
  • Reason: To bring attention to situations like these where a user repeatedly makes edits and reverts themselves to game autoconfirmed rights.
  • Diffs: First edit and Last edit to page. All revisions in between are repeated self reverts that add up to exactly ten.

Deauthorized. (talk) 02:14, 17 September 2023 (UTC)

One thing I did notice; they seemed to have purposely avoided using an edit summary. Since edit filters (afaik) don't provide the tags of an action this may be harder to implement than I originally thought. I'll try some stuff on another wiki. Deauthorized. (talk) 02:39, 17 September 2023 (UTC)
I'll say that I spent some time trying brainstorm a query to identify autoconfirmed gaming and eventually put it on the backburner. There's a lot of ways that it can be gamed (and in ways to avoid notice) and I struggled with how to identify the problem without having too many false positives or false negatives.
I've seen most autoconfirmed gaming occur in the user space, though it does occur in the main space. This is typically in the form of useless edits that add or remove whitespace, such as around template parameters or in tables. The reversion or manual reversion form of gaming more commonly occurs in the user space, so the diffs you provided are unusual. But also sometimes, in the user space, they add characters one at a time without ever reverting. I thought about filtering by account age, but there is/was at least one LTA that would somehow take control of accounts that were registered 10-20 years ago with no edits and then farm the requisite edit count in the accounts' sandboxes.
I suppose it's possible to catch the less subtle abusers like the one you demonstrated by looking for multiple edits with small byte deltas occurring in a short period of time, but I think looking for cases of self-reversion (manually or not) would be limiting because they don't always do this. Notwithstanding, I also think this would be a drop in the bucket. The problem is that the requirements for obtaining autoconfirmed are flawed. Uhai (talk) 09:22, 19 September 2023 (UTC)
Fwiw I created a query at quarry:query/72722 to look for edits to protected pages by newly-confirmed users and, after a quick perusal of the results, (surprisingly) didn't find too much troubling, besides one user (now blocked) who seems to have gamed autoconfirmed by changing random numbers in articles before moving onto less subtle vandalism on a semi-protected article. With some more effort, I may be able to calculate an average or median byte delta for users showing up in this query which may better reveal autoconfirmed gamers who do so by making small changes only.
I still need to write queries to track page moves and direct mainspace creations by newly-confirmed users, though I believe the latter is monitored quite well thanks to NPP. Uhai (talk) 13:30, 17 October 2023 (UTC)

Non-EC ARBPIA article creations

I have little experience with edit filter requests, so sorry if I'm re-raising something that has been discussed before. How about an edit filter that either disallows, or logs, when a non-EC editor creates a new article with the words "Israel" AND "Palestin*" in it? This is to enforce WP:ARBECR in WP:ARBPIA. For examples, see the various threads at ANI right now about non-EC ARBPIA article creations, and a pending ARCA about non-EC ARBPIA editing in general. Disallow would be most efficient (this could be temporary, lifted when editing in this topic area slows down), but even a log would at least give EC editors a list of pages to check. Levivich (talk) 15:34, 4 November 2023 (UTC)

  • This would be doable, and useful. If we're going to restrict it to log only, I'd add a few other keywords as well (probably "Hamas" and "Gaza"). Black Kite (talk) 15:40, 4 November 2023 (UTC)
    It could tag with a tag like "Possible WP:ARBPIA issues", This filter would be fairly useful given what is happening in the world right now. Could work on disallow too. Seawolf35 (talk - email) 02:20, 5 November 2023 (UTC)
    This is definitely doable and I think we should implement this request. The filter will probably start as a log/tag only for a few weeks, then we can discuss the hits and see if we want to warn/disallow the edits with a custom informational message. Note:I have advertised this at WT:Arbitration committee. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 13:19, 5 November 2023 (UTC)
I think most of the issue right now is the process isn't quite established for getting rid of these articles, right now it isn't clear if they should be WP:G5ed or draftified or what, so people just go to WP:ANI. If people just G5ed the articles I don't think the volume of the articles is that problematic to need a filter.
A log-only filter would probably be more useful than a disallow here, since it'd allow adding a bunch more keywords than could be added to a disallow filter. Galobtter (talk) 22:14, 5 November 2023 (UTC)
Anwways, I created a log-only filter at Special:AbuseFilter/1276, since a simple keyword filter for new article creations is very cheap and easy to create. Galobtter (talk) 22:23, 5 November 2023 (UTC)
Thank you, and I agree completely with what you said above. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:26, 5 November 2023 (UTC)
Thanks, everyone! Levivich (talk) 02:44, 6 November 2023 (UTC)

Add AI crap to Filter 54

  • Task: Add something along the lines of "AI", "generative AI", "GenAI", "AI-powered", "leverag[ing/es] AI", "harness AI", "fueled by AI", etc. to Special:AbuseFilter/54.
  • Reason: Since I created a few pages like GPT-4, DALL-E etc, I get notifications when a new link is added to them. A surprisingly high number of these are promotional/advertising, and some are straightforward G11s. Lots of people are figuring out that adding "AI" to a company's description causes its valuation to increase dramatically, and so lots of people are doing this.
  • Diffs: Draft:Middleware (company), Preamble, Inc. (deleted revisions), Phraser (deleted revisions); these are just the few I saw from skimming my Twinkle logs.

jp×g🗯️ 21:55, 8 November 2023 (UTC)

Pinging @Oshwah:, who wrote Filter 54 and probably knows the most about it. Would this be a good idea? I'm not very experienced with edit filters so feel free to tell me if this is just dumb. jp×g🗯️ 22:27, 8 November 2023 (UTC)
@JPxG The filter you referenced only applies to account names during account creation. Something like Special:AbuseFilter/627 would be a better candidate for this. Uhai (talk) 22:39, 8 November 2023 (UTC)
Ah, I see. — Preceding unsigned comment added by JPxG (talk • contribs) 02:00, 9 November 2023 (UTC)
JPxG - Are you seeing a large influx of accounts with these kinds of usernames being created solely in order to be promotional? If so, I have no problem whatsoever adding your suggestion to #54. ;-) ~Oshwah~(talk) (contribs) 02:38, 9 November 2023 (UTC)
No, I was just mistaken about which filter it was. I was talking about new article creations with those in the body text. jp×g🗯️ 03:17, 9 November 2023 (UTC)
Correct, but I'm happy to add any strings if there's a pattern with username issues that apply here... :-) ~Oshwah~(talk) (contribs) 04:02, 15 November 2023 (UTC)

Filter 869: Al Mayadeen (please confirm)

—siroχo 09:05, 19 November 2023 (UTC)

 Already done by Red-tailed hawk - see Special:AbuseFilter/history/869/diff/prev/29982 0xDeadbeef→∞ (talk to me) 09:12, 19 November 2023 (UTC)

Log or disallow new users closing deletion discussions

Task: Log or prevent IPs and non-confirmed users closing deletion discussions, namely at AfD

Reason: Per LTA discussions at Special:Permalink/1185686476#IP-hopping anonymous AfD-closing vandal and Wikipedia:Administrators'_noticeboard/Incidents#Vandal closing AfDs with forged signature (permalink, may be out of date).

According to WP:NACD, IPs and inexperienced users should not close deletion discussions. Therefore, an edit filter may be beneficial to identify or prevent this, along with mitigating the aforementioned LTA.

Diffs:

  1. Special:Diff/1185802579
  2. Special:Diff/1104082169
  3. Special:Diff/1184891493
  4. See linked ANI discussions for many more

Uhai (talk) 05:34, 19 November 2023 (UTC)

I've added a filter, log-only at this time. I've made it private as it's an LTA who has a history of attempting to work around filters. -- zzuuzz (talk) 13:27, 19 November 2023 (UTC)
Thanks. Without getting into technical details, I think there's an avenue where this could be made to disallow and do so with few false positives and negatives, at least to the extent where the deletion discussion can't be made to look like it's been closed and fool editors coming across it into thinking so. Obviously there's a near-infinite number of ways a discussion page could be vandalized that can't be reliably caught using filters. Uhai (talk) 20:24, 19 November 2023 (UTC)

Nick Turani

  • Task: Stopping non-autoconfirmed editors from adding "Nick Turani" to articles (or at least tagging the edit)
  • Reason: It seems to be a new form of vandalism to add "Nick Turani" to articles. This may be premature (I haven't anti-vandalized in a while), but there's a chance it'll help people later on if there's already been a request for this (establishing a pattern, etc.).
  • Diffs: Special:Diff/1186226425, Special:Diff/1186226416, Special:Diff/1186226131

I dream of horses (Contribs) (Talk) 19:11, 21 November 2023 (UTC)

+1 I also remember seeing this around recently. I think adding it to a current tag filter is our best bet. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:56, 22 November 2023 (UTC)
Please! I have been seeing this kind of nonsense today.[38][39][40] It looks like a disruption campaign of some sort. Binksternet (talk) 20:12, 22 November 2023 (UTC)
There is filter 11, which warns and tags as possible vandalism. I'm sure there's others in the list of filters, but that seems like a clear description for it. This seems a bit low-scale, though, so while no objections, obviously, to adding it to a filter, I'm not sure if we need an entirely new filter just for this. EggRoll97 (talk) 06:35, 4 December 2023 (UTC)

Do we have a (presumably private) filter for Meme of the Month, where we can filter out whatever is hip and cool amongst today's trendiest vandals, removing anything which haven't been hit for a while to avoid slowing the system down long-term? Certes (talk) 20:43, 22 November 2023 (UTC)

blanking of pages and replacing content with flags

  • Task: disallow flag vandalism
  • Reason: Nazi Germany, and more recently Palestinian and Israeli flags have been added after blanking a page in some sort of protest or vandalism https://en.wikipedia.org/wiki/Special:AbuseLog/36740627 ill find more •Cyberwolf•talk? 16:19, 9 January 2024 (UTC)
    Would this not be caught by Special:AbuseFilter/3 if it hadn't been in user space? Note filter 3 is disallow. Can you provide a diff where an edit like you describe made it through the abuse filter? Philipnelson99 (talk) 16:59, 9 January 2024 (UTC)
    I tested the edit you linked in your request, and it is indeed caught with the rule specified in filter 3, you just would need to change the namespace. I'm not really convinced it's worth changing since this specific edit was caught by a different disallow filter. Philipnelson99 (talk) 17:01, 9 January 2024 (UTC)

Edit filter 614 (Memes) edit

  • Task: disallowing the word/meme 'gyat' to be added to wikipedia.
  • Reason: to prevent this sort of meme vandalism. I would also suggest that the RegEx for disallowing this thing is something like this: [gG]+[yY]+[aA]+[tT]+[\ ]?
  • Diffs: [41]

– PharyngealImplosive7 (talk) 16:05, 11 January 2024 (UTC)

Can it be limited to whole words to avoid FPs such as Thangyat? Certes (talk) 16:13, 11 January 2024 (UTC)
Yes it can. I did not have time to make a full and functioning RegEx. \b[gG]+[yY]+[aA]+[tT]+[\ ]? should work. That should only allow it at word boundaries, but it probably isn't perfect. – PharyngealImplosive7 (talk) 18:29, 11 January 2024 (UTC)
@Certes: I have done some tests and the previous code (in my previous response) seems to work quite well, but it will detect words that start with 'gyat', like Gyatso. This still needs some refinement.
However, \b([gG]+[yY]+[aA]+[tT]+(?(R1)\ )|[gG]+[yY]+[aA]+[tT]+|\ |)(?1)+\b seems to work quite well. It probably can be simplified though, but I'm running short on time. – PharyngealImplosive7 (talk) 22:15, 11 January 2024 (UTC)
Since this has been open for days and no one has objected/responded, would an edit filter manager care to implement the changes described above, or make any more objections? – PharyngealImplosive7 (talk) 22:41, 15 January 2024 (UTC)
I added \bgyat\b. Untested, but there are only 19 hits in article space, so the FPs can be dealt with as they come up. What are you trying to mach with that regex? It matches any string containing a word boundary. Suffusion of Yellow (talk) 22:47, 15 January 2024 (UTC)
@Suffusion of Yellow: I was trying to match the word 'gyat' while allowing FP's like Thangyat and Gyatso. However, I seem to have overcomplicated the RegEx in my response. – PharyngealImplosive7 (talk) 23:30, 15 January 2024 (UTC)

Filter name: Text-made images

  • Task: Disallow the addition of text-made images.
  • Reason: I have seen a user attempting to vandalize by adding a text-made image, but the triggered filter had a different description.
  • Diffs: Special:AbuseLog/36791661
  • Actions: Disallow
  • Conditions: action == "edit" & page_namespace == 0 & ccnorm_contains_any(added_lines, "[🔴⚪⚫🔵🟨🟠]")

Faster than Thunder (talk | contributions) 18:24, 16 January 2024 (UTC)

@Faster than Thunder: I saw that too, but it's already covered in Special:AbuseLog/36791660 (ie. Filter 680) which is set to disallow. –MJL ‐Talk‐☖ 18:31, 16 January 2024 (UTC)
Yeah since this is hitting a disallow filter already, is it really necessary to write a new filter for this? Philipnelson99 (talk) 18:33, 16 January 2024 (UTC)
Also, this would completely miss edits like this. Ignoring the namespace obviously. Philipnelson99 (talk) 18:40, 16 January 2024 (UTC)
More symbols will be added as they are encountered in illegitimate text-made images. Faster than Thunder (talk | contributions) 18:46, 16 January 2024 (UTC)
If someone were to bypass the filter by adding a reference, adding this filter will catch that vandalism if not caught by another filter. Faster than Thunder (talk | contributions) 18:42, 16 January 2024 (UTC)
Can you show me an example of where emoji being added with a reference does make it through? Philipnelson99 (talk) 18:55, 16 January 2024 (UTC)
I think that would be sockpuppetry, as I need to log out to provide an example. Faster than Thunder (talk | contributions) 20:44, 16 January 2024 (UTC)
I'm not asking you to do it. I would like to see diffs that didn't trigger an existing filter. Philipnelson99 (talk) 20:46, 16 January 2024 (UTC)
Attempt to (but do not) submit an edit to a mainspace page containing "🟠". Faster than Thunder (talk | contributions) 23:26, 16 January 2024 (UTC)
@Faster than Thunder again, can you provide diffs of existing edits that you want to catch and previously were saved successfully? I.e. if the filter was started lets say 3 months ago, what edits would it have prevented that were not caught by another filter? DannyS712 (talk) 01:30, 17 January 2024 (UTC)
I have attempted to submit edits matching my filter idea, but I get met with a warning for not providing an edit summary and not an edit filter message. Faster than Thunder (talk | contributions) 02:37, 17 January 2024 (UTC)
So those edits were disallowed? It would help if you could provide links to diffs showing exactly what your requested filter would prevent. I'm not asking you to make those changes yourself. Philipnelson99 (talk) 15:55, 17 January 2024 (UTC)
I unfortunately cannot provide some example edits. Try monitoring recent changes, especially from anonymous users, and the abuse log. As you find revisions matching my idea, add them to the "Diffs" list. Faster than Thunder (talk | contributions) 19:50, 18 January 2024 (UTC)
I monitor recent changes frequently and have not seen any of this type of edit make it through a filter. I'm not sure adding a filter specifically for this type of edit would be useful especially when it's not clear to me that it's needed. Philipnelson99 (talk) 19:58, 18 January 2024 (UTC)
 Not done It seems that this discussion is going in circles due to the lack of actual diffs that the filter should try to target. Unless and until this becomes a problem we shouldn't create a filter unnecessarily. Thanks, --DannyS712 (talk) 20:16, 18 January 2024 (UTC)

Filter that stops only series of swears from being added to the article

Task: to stop edits that only add swear words to the article, except on articles with a title containing a swear word. Reason: Recently there have been posts that slip through the filters with excessive n-words, s-words, f-words etc. Diffs: [42] 2601:647:4800:2AA8:58A3:E427:DE12:28C2 (talk) 04:14, 8 January 2024 (UTC)

I believe that filter 384 intentionally avoids the Wikipedia namespace and maybe some others, but not the article namespace where it prevents bad words on articles, and the same probably goes for 260. – 64andtim (talk) 04:40, 8 January 2024 (UTC)
Well, if such blatant vandalism can go through, at least a change to the filter is needed. Or maybe (like the OP says) a new filter that detects repeated series of swears. PharyngealImplosive7 (talk) 01:51, 9 January 2024 (UTC)
That edit was to WP:EFFPR, which is intentionally excluded from most filters. Suffusion of Yellow (talk) 02:09, 9 January 2024 (UTC)
Oh I did not check what article it was on. I see. PharyngealImplosive7 (talk) 02:14, 9 January 2024 (UTC)
 Not done such edits to articles are caught by existing filters, the false positives report page is intentionally excluded from most of our filters so that false positives can be reported, the page is frequently patrolled and the linked edit was reverted within a minute. --DannyS712 (talk) 20:09, 19 January 2024 (UTC)

Catch attempts to insert 10.14325/mississippi/9781496811325.003.0047

  • Task: Catch attempts to convert/insert "Citation Needed". Retcon Game. 2017. doi:10.14325/mississippi/9781496811325.003.0047. ISBN 978-1-4968-1132-5. instead of {{citation needed}}
  • Reason: I've spent half an hour cleaning up 20-30 instances.
  • Diffs: [43]

Headbomb {t · c · p · b} 01:17, 22 January 2024 (UTC)

Is this source deprecated or inappropriate somehow? I'd like more context as to why this needs a filter. Thanks. Philipnelson99 (talk) 02:02, 22 January 2024 (UTC)
@Philipnelson99: It's a source about the [Citation Needed] tag itself. –MJL ‐Talk‐☖ 04:58, 22 January 2024 (UTC)
I feel like a tracking-only tag might work to start. Seems reasonable if we've got an active vandal on the loose. — Red-tailed hawk (nest) 05:16, 22 January 2024 (UTC)
Along those lines, @MJL: Do you have any recent examples of this sort of vandalism, or is this all cleanup of an old pattern? The sample diff is from 2021, so I wanted to check before taking action and writing a filter. — Red-tailed hawk (nest) 05:17, 22 January 2024 (UTC)
@Red-tailed hawk: You'd have to ask Headbomb about that. I was just answering Philip's question. –MJL ‐Talk‐☖ 06:26, 22 January 2024 (UTC)
The ones I undid were nearly all from random accounts, some by established accounts, and spanned more or less 2021-2023. Headbomb {t · c · p · b} 07:21, 22 January 2024 (UTC)
@Headbomb is this an ongoing issue, meaning have you seen it happen in the past 4 weeks or so? Philipnelson99 (talk) 19:30, 24 January 2024 (UTC)
The last times were a few weeks ago in draft space at [44] and [45]. Headbomb {t · c · p · b} 20:12, 24 January 2024 (UTC)
Alright, then I'm thinking @Red-tailed hawk's suggestion of a log only filter is a good idea, but I'm really not convinced this needs a filter yet. Philipnelson99 (talk) 20:14, 24 January 2024 (UTC)
 Done Added to 979 (hist · log). This is unlikely to be vandalism; it's just people who don't know about Template:Citation needed typing "citation needed" into the VisualEditor citation tool. . Suffusion of Yellow (talk) 02:33, 25 January 2024 (UTC)

Prevent Israel from being replaced with Isnotreal/Isnotrael

  • Task: This could be applied to all pages in main space and all non-confirmed editors.
!("confirmed" in user_groups) &
page_namespace == 0 & (
 abuseStr :="isnot(real|rael)"

old_wikitext irlike 'Israel' & added_lines irlike abuseStr
)

Philipnelson99 (talk) 19:37, 4 February 2024 (UTC)

I have seen this more than these diffs but not since I started tracking it and locating more diffs would be quite difficult without having come across them in rc patrol. Philipnelson99 (talk) 19:41, 4 February 2024 (UTC)
Seems like a good idea to me. We should create new filters for this sort of thing. – PharyngealImplosive7 (talk) 21:27, 4 February 2024 (UTC)
Also, this behavior may occur in other namespaces (I’m mainly thinking about templates about Israel/Palestine and project namespace articles about Israel/Palestine sanctions/restrictions by ARBCOM), but we may want to wait before applying this proposed filter to other namespaces as vandalism may not occur in those namespaces as much if at all. – PharyngealImplosive7 (talk) 21:32, 4 February 2024 (UTC)
 Done Added to 614 (hist · log). No need for any more complicated logic when there are zero legitimate uses according to Special:Search. Suffusion of Yellow (talk) 03:00, 7 February 2024 (UTC)
great thanks @Suffusion of Yellow! Philipnelson99 (talk) 03:02, 7 February 2024 (UTC)

Prevent users from adding user wikilinks to main space articles

  • Task: Prevent users from added wikilinks (e.g. [[User:UserNameHere]]) to user pages to mainspace articles. The regex would look like: \[\[User:.*?\]\]
  • Diffs: The diff I have is revision deleted (sent to mailing list)
  • Reason: I cannot think of a good reason for users adding wikilinks to user pages to main space articles. A disallow filter preventing this would have very little chance of FPs.

Philipnelson99 (talk) 04:11, 10 February 2024 (UTC)

There may be legitimate cases like in articles about Wikimedia and its projects or Wikimedians, e.g. Jason Moore (Wikipedia editor) (see external links). I wrote this query a while ago to look for this issue but I believe there's another (possibly better) report somewhere else as it appears there's at least one editor who regularly monitors and fixes these occurrences. If this is implemented, it may also be worth preventing Template:Reply to and its aliases per this diff. Uhai (talk) 09:13, 10 February 2024 (UTC)
Right, I was actually looking at your query before I saw this reply. I think limiting the filter to non-confirmed editors could cut down on potential false positives. Philipnelson99 (talk) 09:34, 10 February 2024 (UTC)
Here's the list without filtering out Wikimedia-related pages, so there's not much. For the filter, it would be important to look at the wikitext rather than the HTML as some templates, like Template:Proposed deletion/dated will introduce links to user pages in them. Substituted templates, if they contain user space links, could also be a problem? Though I haven't tested this so I'm not sure about how the abuse filter extension interacts with template substitutions. But yeah, non-confirmed only would likely limit issues, though the ratio of these links added by non-confirmed vs. confirmed is unclear. I want to say, anecdotally, that the times I've seen this issue, it's been by confirmed+ users. Uhai (talk) 10:00, 10 February 2024 (UTC)
This is filter 1090 (hist · log). A quick look at the log suggests that it could definitely be set to warn+tag, and possibly be set to disallow. The filter currently requires the link to be in both added_lines and new_html, no neither templates (where the link is in HTML only), nor "signed" comments (where the link is in the wikitext only) should be a problem. This is, however, mostly a problem with good faith editors getting, so we will need a custom message. Suffusion of Yellow (talk) 21:59, 10 February 2024 (UTC)
Gotcha. Philipnelson99 (talk) 22:33, 10 February 2024 (UTC)
Filter 1090 currently doesn't take any actions. We might want to move it to tag/warn + tag before disallow to test how many FPs are there also
. – PharyngealImplosive7 (talk) 22:38, 10 February 2024 (UTC)
Added a tag. Suffusion of Yellow (talk) 20:07, 11 February 2024 (UTC)

ScienceDirect topics

Hemiauchenia (talk) 22:34, 1 December 2023 (UTC)

I'm pretty sure that the Spam-blacklist can handle this. 0xDeadbeef→∞ (talk to me) 09:34, 4 December 2023 (UTC)
@Hemiauchenia: To be clear, the request is for a warning filter to be applied, not a deny filter, right? — Red-tailed hawk (nest) 15:36, 5 December 2023 (UTC)
Hmm. While reading the discussion linked I saw someone favoring a blacklist so I was unsure about this request. 0xDeadbeef→∞ (talk to me) 22:47, 5 December 2023 (UTC)
I also see that when reading the discussion, but I'm trying to reconcile that with the adding a warning language in the request above. — Red-tailed hawk (nest) 01:03, 6 December 2023 (UTC)
I honestly do not care whether a warning or blacklist is given. Do what you think is likely to be effective. Hemiauchenia (talk) 02:52, 6 December 2023 (UTC)
@0xDeadbeef: What if we were to add this to filter 869? It would require community consensus for deprecation, but I think that might be the way forward here if we don't have consensus to blacklist. Otherwise, if there's consensus to blacklist, we could just make a post at MediaWiki talk:Spam-blacklist to request it. — Red-tailed hawk (nest) 02:56, 6 December 2023 (UTC)
@Red-tailed hawk: While blacklisting was discussed at RSN, I think 869 would probably get the job done better. Looks like it could be done with changing |ruptly\.tv)" to |ruptly\.tv)|sciencedirect\.com" in line 3. EggRoll97 (talk) 01:41, 25 December 2023 (UTC)
Uhhh, we shouldn't do that for sciencedirect.com since that's actually a reliable source 0xDeadbeef→∞ (talk to me) 03:15, 25 December 2023 (UTC)
It would be possible with something like sciencedirect\.com\/topics; 0xDEADBEEF is correct that there are many, many reliable publications on the domain more broadly. Might be worth starting an RfC at RSN if the goal is to add this to filter 869, and if we can be certain that this url construction only points to machine-generated pages. — Red-tailed hawk (nest) 04:05, 25 December 2023 (UTC)
That looks like a good regex. Going to propose it at the spam-blacklist page. Uh wait, do we have consensus on RSN to do anything about that source? I count 6 "deprecate (filter)" and two "actually, we can go further and blacklist". I think the RSN consensus only allows deprecation; I support both, for the record. Artoria2e5 🌉 09:03, 2 February 2024 (UTC)
In my opinion we either use the spam blacklist or we don't do anything because filters are optimised to catch problematic text not links. Zippybonzo | talk | contribs (he|she|they) 14:15, 27 December 2023 (UTC)
Filter 869 is designed to catch deprecated sources (warns the user, not disallow), while the blacklist catches blacklisted sources. See Wikipedia:Reliable sources/Perennial sources#Legend. 0xDeadbeef→∞ (talk to me) 14:20, 27 December 2023 (UTC)
Just a note that the discussion has been archived to Wikipedia:Reliable sources/Noticeboard/Archive 422#Machine-generated text at ScienceDirect used as source --DannyS712 (talk) 20:11, 19 January 2024 (UTC)

Opened a RfC in order to get a consensus for an edit filter: Wikipedia:Reliable_sources/Noticeboard#RfC:_ScienceDirect_topics. Hemiauchenia (talk) 23:25, 19 February 2024 (UTC)

Substitutions

Add some common substitutions to Filter 260, 384 or another applicable filter. Getting around the current filters is trivial. It shouldn't be.

- Sumanuil. (talk to me) 01:48, 26 January 2024 (UTC)

Sounds good to me. – PharyngealImplosive7 (talk) 02:59, 26 January 2024 (UTC)
All the diffs presented originally have been revision deleted. – PharyngealImplosive7 (talk) 16:01, 26 January 2024 (UTC)
My concern is that practically I'm not sure there is a finite list of possible character substitutions. I do think adding the examples you listed to either Special:AbuseFilter/260 or Special:AbuseFilter/384 (or both) would be a good start. Could you find examples that haven't been revdeled? Philipnelson99 (talk) 18:01, 26 January 2024 (UTC)
Is there a way to search for edits that meet this criteria? Because it would painful to find more diffs manually. – PharyngealImplosive7 (talk) 18:13, 26 January 2024 (UTC)
There's not really a way to do this without tons of API queries or getting the extremely large database dumps that contain revisions as far as I know. Philipnelson99 (talk) 18:24, 26 January 2024 (UTC)
Oh. That would be quite hard to do. Maybe the original requester of this filter has some more diffs. If not, I can try to find some.
@Sumanuil: This is just to ask you if you have any non-revdelled diffs with the substitutions you are referring to. If not, it's still ok. – PharyngealImplosive7 (talk) 18:31, 26 January 2024 (UTC)
Sorry. I'll try to find some. - Sumanuil. (talk to me) 19:43, 26 January 2024 (UTC)
It's ok. It is to anticipate when things like this will be revdelled. – PharyngealImplosive7 (talk) – PharyngealImplosive7 (talk) 20:28, 26 January 2024 (UTC)
This is for anyone who didn't see the diffs before they were revdelled and wants to edit any filters. The things that we want to disallow are ni993r (n-word), peen (penus), tard (retard, retarded), and idi0t (idiot, but zeros can replace o's in many places). I would suggest adding these and seeing if any false positives or new phrases to get around the filters arise. – PharyngealImplosive7 (talk) 22:20, 28 January 2024 (UTC)
The string "tard" appears in inoffensive words such as "custard" and "stardom". Even "retard[ed]" as a whole word has many legitimate uses. Certes (talk) 22:42, 28 January 2024 (UTC)
And the string "peen" may run into issues when it comes metallurgy (peening, ball-peen hammer); Chinese sugar candy (peen tong); quotes from and reference titles in Dutch in a food context, where it simply means carrot; a number of uncommon surnames including Peen, Peene and Peenstra; the German river Peene; the cities, villages, industrial districts etc. Peene, Kent, Peenemünde, Peenya and Peenehagen, as well as anything named for these. AddWittyNameHere 23:04, 28 January 2024 (UTC)
@Certes: @AddWittyNameHere: I see. Maybe stuff like \btard\b would work better than “tard”, but “peen” might be a little hard to filter properly without so many FPs. But it seems that things like ni993r and idi0t would have little to no FPs. – PharyngealImplosive7 (talk) 00:34, 29 January 2024 (UTC)

PharyngealImplosive7 (talk · contribs): It was actually c0ck, but idi0t should probably be added as well if possible. - Sumanuil. (talk to me) 01:53, 29 January 2024 (UTC)

I must of misremembered. Oh well. – PharyngealImplosive7 (talk) 02:15, 29 January 2024 (UTC)
id10t (with one before zero) is also common. Certes (talk) 09:20, 29 January 2024 (UTC)
There is also another one that should be put into at least one of the filters listed above: ped0 (pedophile), as can be seen in this edit. – PharyngealImplosive7 (talk) 01:56, 1 February 2024 (UTC)
This has been open for a while. Would any EFM mind implementing some of these (including c0ck, idi0t, \btard\b, ni993r etc? The amount of FPs seem minimal for these examples. – PharyngealImplosive7 (talk) 17:12, 4 February 2024 (UTC)
Testing at 839 (hist · log) and 1014 (hist · log). The first two would be covered by ccnorm(), but we've never used ccnorm() at filter 384, and few of the other words might be problematic. "Tard" is French for "late" and has 905 mainspace uses, often in references, so it's question of the ratio of good to bad. "ni993r" shouldn't cause any problem, but I want to see how common it is first. Suffusion of Yellow (talk) 20:56, 11 February 2024 (UTC)
ni993r looks like a job for ccnorm as there are so many potential variants such as n199er. We may or may not want to include the actual all-letters form, which has limited legitimate uses in quotations and in discussing offensive language. Certes (talk) 21:31, 11 February 2024 (UTC)
ccnorm("9") == "9"; that's why 260 (hist · log) didn't stop this already. If by "all-letters form" you mean "nigger" and "nigga"; those have been disallowed for years by both 384 (hist · log) and 260 (hist · log), but there are various exceptions for e.g. discographies. Yes, there are many legitimate uses (or mentions if you want to get picky) in article-space, but the ratio of good to bad edits from new users is very very low.
It's not necessarily worth chasing every minor variation, once someone is committed to playing the game of defeat-the-filter, they're going do to something disruptive just to prove they're cleverer than us. "Low-effort" substitutions (I.E. those that they're in the habit of using to defeat other sites' filters) might be worth stopping, though. Suffusion of Yellow (talk) 21:42, 11 February 2024 (UTC)
I'd stupidly assumed from the previous comment that we had a custom function called ccnorm which somehow magically guessed that 1 means i rather than L today. A simple pattern such as n[i1][g9][g9][e3]r seems far more practical. Certes (talk) 22:02, 11 February 2024 (UTC)
@Suffusion of Yellow: I've been monitoring the filters for the past couple of days, and 1014 (hist · log) has gotten some hits but 839 (hist · log) hasn't got any since late 2022. It might just be that there are more substitutions in 1039 though. – PharyngealImplosive7 (talk) 17:23, 16 February 2024 (UTC)
@Suffusion of Yellow: The filters have been going for 2 weeks, and 839 (hist · log) got its first 2 hits, while 1014 (hist · log) has gotten 50+ hits, which are almost all unconstructive. I would support adding these substitutions to the disallow filter. – PharyngealImplosive7 (talk) 01:54, 28 February 2024 (UTC)

Identify removal of short description

Task: Identify mainspace edits that remove or otherwise disrupt the functioning of the short description template

Reason: Per Wikipedia:Short description, every mainspace article should have a short description. In other words, every article should either directly transclude Template:Short description or transclude it via another template. If an editor has a problem with an added short description, they should correct it rather than remove it. Ultimately, the template should never be removed from an article once it has been placed. The only three exceptions I can think of are:

  • Reversion of vandalism, though vandalism where a vandal both knows how to add a short description and does so despite other low hanging fruit is unlikely
  • Reverting to status quo when there is a disagreement/edit war as to what a page's short description should be (also rare)
  • Removing an override short description from a page that transcludes one from another template (also rare)

The reason for this filter is that removal or disruption of the short description template can serve as an indication of unconstructive edits, vandalism, or test edits, as the diffs below demonstrate.

Diffs:

  1. Special:Diff/1169358517: unconstructive edit in which an IP user pasted text in place of the existing templates and lead
  2. Special:Diff/1170711636: vandalism where an IP user replaced the short description template to soapbox
  3. Special:Diff/1173114952: blanking test edit or vandalism
  4. Special:Diff/1178029085: test edit or vandalism
  5. Special:Diff/1178012566: test edit or vandalism

I can anecdotally say that I've come across many more instances of the template being removed or disrupted, hence this edit filter request, but I'm unable to provide more diffs at this time because of the difficulty locating them amongst my edit history of adding short descriptions.

I think something along these lines could work for the filter: 

!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
page_namespace == 0 &
old_wikitext irlike "{{short description\|.+}}" &
!(new_wikitext irlike "{{short description\|.+}}")

I'm not overly familiar with the filter rules syntax, so someone else could probably improve this. Basically we just need to check if an intact short description template was present on the previous version of the page and is now absent from the new version. Also, because of the exceptions above, I think it's probably best to exclude extended confirmed users. Uhai (talk) 18:50, 15 September 2023 (UTC)

Removing an override isn't that rare. I've reverted quite a few edits which override a bland but adequate SD provided by a template with a poor manual SD which has little to do with the topic. Certes (talk) 21:16, 15 September 2023 (UTC)
Fair enough. Maybe the filter could trigger only for non-confirmed users instead of non-extended confirmed if false positives are a concern. Uhai (talk) 23:30, 15 September 2023 (UTC)
I added two more diffs that I encountered this month in my pages without short descriptions by view count report generation. So, uh, could we please get a trial run of the filter at least? I think this could uncover a lot of things that go missed. Uhai (talk) 17:31, 1 October 2023 (UTC)
@Uhai: Testing at 1014 (hist · log). This is going to overlap hugely with filters like 3 (hist · log) and 957 (hist · log), but I'll add some exclusions once I see which hits are getting saved successfully. Suffusion of Yellow (talk) 21:05, 26 October 2023 (UTC)
@Suffusion of Yellow: Thanks! It's already caught some edits like Special:AbuseLog/36222921 and Special:AbuseLog/36222983 that are along the lines of what I was hoping to be able to identify, though additional exclusions for the overlaps you mentioned would be nice. My only concern is your regex may not catch more subtle changes like {{short description|Test}} to {{short descriptionTest}} or {{short description|Test} which would still break the template, though I don't have any diffs at the moment to evidence any frequency of this happening. Uhai (talk) 21:33, 26 October 2023 (UTC)
Good point. Checking for shortdescription in new_html instead. Suffusion of Yellow (talk) 21:51, 26 October 2023 (UTC)
The saved hits look pretty darn good in terms of FP rate and there's a good amount of them. I think with an exclusion for blankings/redirects and {{Short description|none}} (which doesn't produce any html) it'll do very well. I designed Special:AbuseFilter/957 before {{short description}} was as widespread as it is now, but now this filter would probably catch ~70-80% of 957's hits. Galobtter (talk) 23:36, 29 October 2023 (UTC)
I concur that it's looking good. Fortunately, most of the saved hits are getting reverted quickly—how many of these are due to the existence of the filter is hard to say (probably very few since it doesn't have a descriptive name yet)—though I am finding an average of 2-3 out of every 50 saved hits that have been missed that I am going in and fixing, so it has been useful in that regard. Whether these stats justify permanent inclusion of the filter, I'll leave to others' opinions. I have since come up with the idea of doing a day-to-day delta of pages belonging to Category:Articles with short description on Toolforge to generate a report of pages that have had disruption or removal of the short description template, which may serve as a better alternative to this filter, or could just supplement it; I don't know.
@Suffusion of Yellow: My remaining concern is that the filter currently does not catch removal or disruption of a "none" short description because of line 8 and the fact that there's no HTML for this case, as Galobtter stated above, combined with line 7 checking for the existence of shortdescription in the HTML. There are currently 184,017 articles that have "none" as their SD, so it's not an insignificant number. I suppose I'm wondering at the reasoning for line 7 being 
!(new_html contains "shortdescription")
rather than something like 
!(added_lines irlike "\{\{short description\|[^\{\}\[\]\|\=]+\}\}")
(and negating any other characters that would break the template) Uhai (talk) 22:49, 14 November 2023 (UTC)
Ugh, maybe I was being too clever by half. Trying it your way for a while. Suffusion of Yellow (talk) 21:22, 23 November 2023 (UTC)
@Suffusion of Yellow Thoughts on how this has been doing? The hits have been looking good though there's still some co-triggering with Special:AbuseFilter/957 (which may be okay).
I'd like to suggest a change of the regex to \{\{\s*short[ _]description\s*\|(\s*1\s*\=[^\{\}\[\]\|]+|[^\{\}\[\]\|\=]+)\}\} since it turns out the equals sign doesn't break the template if the parameter name has been explicitly defined. The current pattern also does not match in this scenario which could be causing false negatives depending on how many transclusions there are out there doing as such. Uhai (talk) 23:40, 27 December 2023 (UTC)

@Uhai: Now in 1285 (hist · log). I put the new_html check back (though it catches remove of "none" templates" now), because no regex is going to catch every edge case, and a catch-all should prevent any FPs. Zero false negatives is just not possible with any filter, and with a disallowing filter the focus should always be on preventing FPs. So the next step is creating a custom message. Rough draft:

Sorry for all the delays. Suffusion of Yellow (talk) 22:50, 31 December 2023 (UTC)

That seems reasonable. Would support disallowing assuming the filter works properly. Galobtter (talk) 23:08, 31 December 2023 (UTC)
Looks good and all, but I would suggest replacing "If you believe this page needs no short description, use {{Short description|none}} instead of removing the template. Otherwise, please report this error." with "If you believe this page doesn't need a short description, please use {{Short description|none}} instead of removing the template. Otherwise, you may report this error." (or something similar like that). Also, we may or may not need to remove the report error button because the "Otherwise, you may report the error" notice makes it redundant. – 64andtim (talk) 08:37, 5 January 2024 (UTC)
@64andtim: The redundancy is intentional; there are many different editing interfaces, and I'm not sure if the "fancy" button will work from all of them, nor am I sure how clear it is to screen reader users. But I guess your wording flows a bit better, and I'll go with that. Will propose disallowing at EFN shortly. Suffusion of Yellow (talk) 20:12, 11 February 2024 (UTC)
@Suffusion of Yellow It wasn't my initial intention when requesting this for this to be a disallow filter however I have gone through almost all of the ~1500 hits as of this post and have not seen a single false positive, so I also support changing it to disallow as this should reduce some of the burden on RC patrollers. Thanks for all your effort and iteration on this. Uhai (talk) 23:37, 11 January 2024 (UTC)
@Suffusion of Yellow: @Uhai: It has been over two months and the filter has gotten over 10,000 hits, which mostly seem to be illegitimate. Any progress on making the filter disallow? – PharyngealImplosive7 (talk) 13:46, 12 March 2024 (UTC)
There appears to be consensus in favor of setting to disallow at the EFN discussion. The sole oppose !vote was from 1AmNobody24 but they appear to have changed their opinion in the ensuing discussion. Uhai (talk) 14:00, 12 March 2024 (UTC)
Filter is now disallow! – PharyngealImplosive7 (talk) 22:49, 21 March 2024 (UTC)

Protection/Unprotection requests for Example Article Name

I’ve noticed that WP:RFPP/I/WP:RFPP/D seem to get an (at least slightly) noticeable number of requests to [un]protect the page Example Article Name (diffs from the start of 2024: [46], [47], [48], [49], [50], [51], [52], [53]). My assumption is that these come from submissions of the protection & unprotection forms where the default page name hasn’t been changed - either as a test, or because the requestor forgot to specify the page. Is it worth having an edit filter in place to catch these (which would hopefully prevent the test requests, while acting as a reminder to editors who’ve forgotten to enter a page name)? Will notify WT:RFPP of this request. All the best, ‍—‍a smart kitten[meow] 14:33, 9 February 2024 (UTC)

…and I’ve just noticed that there was a format I was meant to follow when adding a request. My apologies./gen Best, ‍—‍a smart kitten[meow] 14:38, 9 February 2024 (UTC)
(edit conflict) Lovely idea, and yes, that would be quite useful; I don't know if it is a problem which turns up when using mobile editing. They also frequently appear at Wikipedia:Requests for page protection/Edit. Lectonar (talk) 14:41, 9 February 2024 (UTC)
Searching through the edits to the /Edit page with summaries "requesting an edit to" since the start of December shows no hits for "Example Article Name". On the other hand, the provided diffs indicate that this has been an issue for the increase and decrease pages. I'll use filter 1 to log any of these for a bit with the following conditions:
equals_to_any(
    page_id,
    59689745, /* [[Wikipedia:Requests for page protection/Increase]] */
    59689765 /* [[Wikipedia:Requests for page protection/Decrease]] */
) &
action = 'edit' &
'=== [[Example Article Name]] ===' in added_lines

to see how frequent this is. --DannyS712 (talk) 21:59, 14 February 2024 (UTC)

Added at Special:AbuseFilter/history/1/diff/prev/31196 as log-only - I'll monitor that for a few weeks, if it gets some hits we can create a warning filter --DannyS712 (talk) 22:02, 14 February 2024 (UTC)
@DannyS712 Just had its first hit a minute or so ago, see Special:AbuseLog/37018801. Philipnelson99 (talk) 03:59, 16 February 2024 (UTC)
No need to let me know each time, I'll monitor the filter --DannyS712 (talk) 06:44, 16 February 2024 (UTC)
I understand, just wanted to let you know that it did get its first hit with a day or two of the change being added. I don't expect to notify you any more. Philipnelson99 (talk) 13:13, 16 February 2024 (UTC)
It's been almost 2 weeks since this was added and it's gotten four hits, of those hits only one editor added a real report after the filter logged the action, the rest were cleared by another editor. Philipnelson99 (talk) 20:31, 27 February 2024 (UTC)
The filter doesn't seem to get hits often, but I think that's expected. I would support making a new filter and setting it to tag or warn, because it works quite well. If it is set to warn, we'd need a new message to show of course. – PharyngealImplosive7 (talk) 01:48, 28 February 2024 (UTC)
As the filter requester, my opinion is that warn would be better than tag in this instance; as the idea behind my original post was to prevent test requests, & remind editors to enter a page name when they've forgotten to. All the best, ‍—‍a smart kitten[meow] 03:12, 28 February 2024 (UTC)
Then warn seems like it would work better as you say, but it's up to the EFMs to decide what they want to do ultimately. – PharyngealImplosive7 (talk) 04:24, 28 February 2024 (UTC)
I was going to let it run for another week or two to get a larger sample size --DannyS712 (talk) 18:20, 28 February 2024 (UTC)
Okay, this seems to be an ongoing thing and while its just a few edits, no harm in adding a warn-only filter (especially since its actually valid to request decreasing protection for the example page so not disallowing, though unlikely to be intentional). I'm thinking something like

as a first draft for the message - @Philipnelson99, A smart kitten, and Lectonar: thoughts? The actual filter conditions would be the same as those that I tested out (noted above), at least to start with. --DannyS712 (talk) 17:55, 8 March 2024 (UTC)

LGTM @DannyS712. Philipnelson99 (talk) 18:03, 8 March 2024 (UTC)
LGTM also @DannyS712: – PharyngealImplosive7 (talk) 18:07, 8 March 2024 (UTC)
I've created Special:AbuseFilter/1291 and will enable it once my request at MediaWiki talk:Abusefilter-warning-protection-request is actioned by an administrator --DannyS712 (talk) 22:35, 10 March 2024 (UTC)
Enabled and confirmed to work (triggered the filter for both the increase and decrease page, got warnings but was able to save) - disabled from filter 1. --DannyS712 (talk) 16:30, 11 March 2024 (UTC)
 Done (In case the bot looks for something like this to archive) --DannyS712 (talk) 18:16, 16 March 2024 (UTC)

Prevent major actions on AfC-related categories

  • Task: The filter is supposed to prevent major actions on AfC-related categories.
  • Reason: What if someone accidentally performs a major action on an AfC-related category?
  • Conditions: equals_to_any(action,"move","delete") && page_namespace == 14 && "AfC " in page_title && !"bureaucrat" in user_groups

Faster than Thunder (talk | contributions) 20:22, 14 February 2024 (UTC)

@Faster than Thunder is this something that has happened in the past? Just want to see if there are log entries for it. Philipnelson99 (talk) 20:24, 14 February 2024 (UTC)
Indeed, moving categories is already restricted to bots, page movers, and admins (per the move-categorypages right) and deletion is already only available to admins. Unless this has actually been a problem a filter isn't needed --DannyS712 (talk) 21:42, 14 February 2024 (UTC)
 Not done No response, does not seem needed --DannyS712 (talk) 18:03, 8 March 2024 (UTC)

Salt evasion

Something like this might work:
equals_to_any(page_id, 0, 118) & equals_to_any(page_title, "Dadasaheb Phalke International", "Dada Saheb Phalke International" /* add more names of articles if needed */) & !"extendedconfirmed" in user_rights
This is a really basic version of what could be added if a whole new filter were to be created. I'd also suggest that this filter (if created of course) be private to stop users from being able to use their knowledge of regex/filter syntax to evade the filter. – PharyngealImplosive7 (talk) 20:50, 9 March 2024 (UTC)
I concur that maintaining the filter's privacy is crucial to prevent gaming. Therefore, imo, only sysops should be granted creation privileges, particularly in light of the recent incident. GSS 💬 05:00, 10 March 2024 (UTC)
Yeah. Also, for future cases like this, you should understand that there are only two levels of protection in the edit filter: public (everyone, registered or not) can see the filter, or just admins, EFHs, and EFMs can see it. – PharyngealImplosive7 (talk) 05:51, 10 March 2024 (UTC)
What are some recent attempts to recreate such a page? (user logs, page titles, etc) ProcrastinatingReader (talk) 15:26, 11 March 2024 (UTC)
The most recent recreation, 'Dadasaheb Phalke International Film Festival,' was an attempt to evade the salting of the 'Dadasaheb Phalke International Film Festival Awards' page. GSS 💬 15:38, 11 March 2024 (UTC)
Done I've added this to one of my private LTA filters that covers a variety of wikispaces. OhNoitsJamie Talk 15:57, 11 March 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter/Requested/Archive_21&oldid=1218744272"