Wikipedia:Edit filter/Requested/Archive 21

Archive 15

←

Archive 19

Archive 20

Archive 21

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, 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

• Task: Flag revisions in articles with word changes matching at least one of the following regex, case-insensitive:
  • alternative medic([a-z]*) → medic$1
  • fringe (scien[a-z]*|theor[a-z]*) → $1
  • medical quack[a-z]* → anything matching medic[a-z]*
  • pseudo[- ]?arch(a?e[a-z]*) → arch$1
  • pseudo[- ]?hist([a-z]*) → hist$1
  • pseudo[- ]?math([a-z]*) → math$1
  • pseudo[- ]?scien([a-z]*) → scien$1
  • pseudo[- ]?scholar([a-z]*) → scholar$1
  • quack[a-z]* → anything matching medic[a-z]*
  • A word matching any of the above regex, except quack[a-z]* not preceded by medical, is deleted entirely.
• Reason: Edits of this type are often promoting a fringe POV, which is common in articles about fringe theories. Makes it easier to catch and revert these edits on sight. See also Wikipedia:Fringe_theories/Noticeboard#Would_it_be_worthwhile/possible_to_get_a_filter_showing_removals_of_"pseudo".
• Diffs: changing pseudoarcheology to archeology; deleting pseudoscientific and pseudohistoric; deleting pseudoscientific, along with many other examples at the same article.

–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:
  • [[Special:Diff/1142971753 March 5, 2023], 37.111.245.208
  • [[Special:Diff/1140262032 February 19, 2023], 37.111.244.118
  • February 19, 2023, 37.111.246.48
  • February 19, 2013, 37.111.246.48
  • February 17, 2023, 37.111.245.233
  • February 17, 2023, 37.111.243.86

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 852 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)

   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.

• Diffs: adds link to predatory journal, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds proxy link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, adds blacklisted link, and I can find a lot more too.

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 (log)
• 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

• Task: This filter is used to prevent non-AfC reviewer from accepting or declining draft submmisions by if the filter matches with the string {{AfC submission|D}}, {{AfC submission/declined}}, {{AfC submission/rejected}}, {{AfC submission|reject}}, and {{AfC submission/created}} it then triggers a message to prevent users from doing that action. This filter only applies to drafts and userspaces and to the user who are not extended-confirmed and administrators which includes confirmed/autoconfirmed user(s), new user(s), and unregistered/IP/anonymous editor(s).
• Reason: Because the criteria to become an AfC reviewer is from the excerpt that the criteria required to become AfC reviewer is:

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

• Diffs: Diff 1159819666.

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)

• Task: Would it be possible to track or mark edits where a footnote has been added to an article, but the URL is surrounded by "nowiki" tags? Example rev: Here the user added quit some footnotes where the URLs are not "clickable" due to the nowikis.
• Reason: Nowiki's are in most cases never intentional
• Diffs: https://en.wikipedia.org/w/index.php?title=Cyberlindnera&diff=prev&oldid=1146460395

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 ^talk_contribs^she_her 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:

• [34]
• [35]
• [36]
• [37]

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, AA^Talk 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)

• {{EFR}}. Disruptive editing like this shouldn't be handled using an edit filter — I'd encourage users to report any edit warring/disruptive editing at the appropriate venue. Other reviewing EFMs may wish to read Wikipedia talk:WikiProject Weather#Updating old tracks and season summary maps for context — TheresNoTime (talk • they/them) 21:20, 15 October 2023 (UTC)
  • @TheresNoTime: Can we have it at least as a tagging filter so it's easier to track down these edits? Note that I created this with easy technical feasibility in mind.--Jasper Deng (talk) 22:19, 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)

• Task: This filter may need to be updated to include https://*.almayadeen.net
• Reason: The source has been deprecated by a consensus of editors Wikipedia:Reliable sources/Noticeboard § RFC: Al-Mayadeen. What I'm not sure about is whether a source is added to the filter if nobody specifically called for it in the RfC, so I would appreciate someone endorsing or rejecting this request. I'm raising it so it doesn't get forgotten in case it's necessary.
• Diffs: RfC close performed by me

—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
)

• Reason: I've seen this a couple of times and it could be easily prevented by a filter. I don't think there will be many false positives if the above filter is used.
• Diffs:
  • Special:Diff/1201055005
  • Special:Diff/1203377271

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

• Task: Adding a warning to editors adding any url containing the string www.sciencedirect.com/topics/
• Reason: See Wikipedia:Reliable_sources/Noticeboard#Machine-generated_text_at_ScienceDirect_used_as_source. The "topics" pages are AI generated collections of snippets from different ScienceDirect publications that change over time, meaning that they cannot be considered stable references.
• Diffs: These "topic" pages have been cited over 1,000 times per sciencedirect.com/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.

• Diffs: Zero for an O; 993 for gge; "peen"; "tard"

- 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

• Task: Detect title containing "Dadasaheb Phalke International" or "Dada Saheb Phalke International" and disallow page creation.
• Reason: An article for Dadasaheb Phalke International Film Festival has been repeatedly created under various titles indicating attempts to evade WP:SALT in both main and draft namespaces by multiple users over the years. Notably, the subject appears to be an award mill taking advantage of the reputation of the genuine Dadasaheb Phalke Award. For further information, please refer to WP:DADASAHEB, Wikipedia:Sockpuppet investigations/Abhibabamishra/Archive and Wikipedia:Sockpuppet investigations/Arshifakhan61/Archive. Thank you. GSS ^💬 18:03, 9 March 2024 (UTC)

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)

Danny Duncan

• Task: Warn and possibly disallow users attempting to add "Danny Duncan" or "dannyduncan69.com" to articles
• Reason: Repeated addition of this non-notable YouTuber (per multiple AfDs) to articles, including recreations of his deleted article. I suspect this YouTuber (or one of his fans) is encouraging Wikipedia vandalism. One thing I will point out though is that this Forbes article establishes more WP:N than the subjects we cover in some articles have ever known, leading part of me to wonder if the AfD should be revisited.
• Diffs: See entire history of this page along with these edits to various articles (non-exhaustive list): [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69]

PCHS-NJROTC ^{(Messages)Have a blessed day.} 03:44, 24 March 2024 (UTC)

If this type of trend continues, then maybe we should add this to filter 614. Codename Noreste 🤔 talk 20:29, 24 March 2024 (UTC)

This trend has been going on for several years, not sure why we would need to wait to add it. PCHS-NJROTC ^{(Messages)Have a blessed day.} 14:18, 25 March 2024 (UTC)

Possible RegEx includes danny duncan and dannyduncan69\.com. – PharyngealImplosive7 (talk) 01:17, 28 March 2024 (UTC)

PI7, the correction would be (?:daniel|danny) duncan|danny duncan69\.com, and I have tested the new regex under FilterDebugger. No false negatives or positives have happened. Codename Noreste 🤔 talk 18:21, 28 March 2024 (UTC)

@Codename Noreste: I think you may have made a mistake in the regex. The requester said that there isn’t any space in the website name that is being spammed, so correct me if I’m wrong but (?:daniel|danny)\bduncan|danny\b?duncan69\.com might work better, and allow all types of word-boundaries (if needed). – PharyngealImplosive7 (talk) 23:32, 1 April 2024 (UTC)

Did you mean \s instead of \b there? The first \b can't match – it's between [ly] and d – and I've never seen \b? in the wild but logically it would have no effect. Certes (talk) 07:58, 2 April 2024 (UTC)

Yeah. It should be (?:daniel|danny)\sduncan|danny\s?duncan69\.com. Thanks for correcting me. – PharyngealImplosive7 (talk) 13:48, 2 April 2024 (UTC)

Add BUST A NUT to a existing filter

• Task: See Title.
• Reason: Vandalism phrase
• Diffs: Diff

Probably reasonable to add to either filter 225, 260 or 384. Nobody (talk) 08:43, 8 March 2024 (UTC)

Might be worth it to add it to one of those filters, because it seems like it could be common enough but not legitimate at all. – PharyngealImplosive7 (talk) 14:49, 8 March 2024 (UTC)

Probably could just be added with modification to 225, as that seems like the most relevant of the three, by adding to the end of line 3's string (included the last word in the code block for reference on where it probably should go), |(W|WANKA)KNIGHT|B+U+S+T|BUST A NUT"; . EggRoll97 ^(talk) 18:54, 22 March 2024 (UTC)

 Done EggRoll97 ^(talk) 23:58, 4 April 2024 (UTC)

Add Marville City Rail to existing filter

• Task: See title
• Reason: This phrase is used exclusively for vandalism. It is being added by a wide variety of IP addresses across dozens of articles, and neither a range block nor page protection will solve the issue by itself. A simple range block would not work because the IP addresses known to have added this phrase include 110.54.190.201 (talk · contribs · WHOIS), 110.54.191.52 (talk · contribs · WHOIS), 122.3.45.189‎ (talk · contribs · WHOIS), 180.191.20.121 (talk · contribs · WHOIS), 180.191.14.175 (talk · contribs · WHOIS), 180.191.49.19‎ (talk · contribs · WHOIS), 180.191.36.77‎ (talk · contribs · WHOIS), 180.191.59.88 (talk · contribs · WHOIS), 180.191.59.89 (talk · contribs · WHOIS), and 202.60.12.123 (talk · contribs · WHOIS). Page protection would not work because this is affecting dozens of articles, as seen in their contributions.
• Diffs: [70], [71], [72]

I think this could be added to filter 260. Epicgenius (talk) 14:41, 8 March 2024 (UTC)

At first glance, I'd say this looks like an LTA. Philipnelson99 (talk) 14:43, 8 March 2024 (UTC)

So I don't like the idea of adding it to Special:AbuseFilter/260. Philipnelson99 (talk) 14:45, 8 March 2024 (UTC)

"Marville City Rail" has no mentions in the search bar, so it could be added to a new LTA filter, with marville\bcity\brail. I also dislike the idea of adding it to a public filter like 260. – PharyngealImplosive7 (talk) 14:48, 8 March 2024 (UTC)

Sounds good; I think it might be better as a private filter now that you mentioned it. – Epicgenius (talk) 14:59, 8 March 2024 (UTC)

I've sent an email regarding a new private filter to track this vandal to EggRoll97, which in turn they've forwarded it to the edit filter mailing list. Codename Noreste 🤔 talk 01:18, 5 April 2024 (UTC)

Memes and trends with obviously no encyclopedic value

• Task: Sure, memes and vandalism trends are done by autoconfirmed users sometimes, but there are some which never have encyclopedic value.
• Reason: Some memes and vandalism trends never have encyclopedic value, so this filter would catch and disallow those edits.
• Diffs: Special:Diff/1213282387
• Conditions: vandalism:="*nigg(er|a|ar)*";
action == "edit" & page_namespace == 0 & added_lines irlike vandalism & !page_title irlike vandalism
• Notes: Can be bypassed on certain pages because such language is sometimes necessary.

Faster than Thunder (talk | contributions) 17:31, 12 March 2024 (UTC)

There is alreadgy a general filter for vandalism. The diff you linked may actually be a legitimate edit. See Special:search/insource:niggardly. Philipnelson99 (talk) 17:50, 12 March 2024 (UTC)

As for the other terms your proposed filter would match. Special:AbuseFilter/384 handles those cases for non-confirmed users. Philipnelson99 (talk) 17:58, 12 March 2024 (UTC)

Also chiming in to say this seems a bit unnecessary. The current filters, as far as I can tell, are doing the job well. EggRoll97 ^(talk) 19:14, 22 March 2024 (UTC)

I also agree with them that the proposed filter in this section is unnecessary, 260 also covers the job of preventing the N word slur as well. Codename Noreste 🤔 talk 19:43, 22 March 2024 (UTC)

I also think that this is not necessary. – PharyngealImplosive7 (talk) 19:49, 23 March 2024 (UTC)

 Not done Does not seem to be necessary. EggRoll97 ^(talk) 00:39, 5 April 2024 (UTC)

Skibidi Toilet vandalism

• Task: Prevent addition of Skibidi Toilet-related words to articles.
• Reason: If you look in the filter log for edits blocked by filter "Memes and vandalism trends", a lot of them try to add "skibidi." This filter distinguishes users who trigger the "Memes and vandalism trends" filter who should be blocked from those that should be warned.
• Diffs: Look in the filter log for edits blocked by filter "Memes and vandalism trends".
• Code: !"extendedconfirmed" in user_groups & rmdoubles(ccnorm(added_lines)) rlike "skibidi" & !ccnorm(removed_lines) rlike "skibidi" & !page_title rlike "skibidi"
• Actions: Block

Faster than Thunder (talk | contributions) 17:37, 2 April 2024 (UTC)

@Faster than Thunder: This is already covered by 614 (hist · log). The edits are already disallowed, so what are you trying to do here? If you would like to block users adding it, that is not possible on enwiki. – PharyngealImplosive7 (talk) 00:17, 3 April 2024 (UTC)

@Faster than Thunder: As stated above, this is already dealt with by 614 (hist · log). Further, for various reasons, we do not enable actions on filters until the filter is fine-tuned, and especially not blocking actions...? Finally, the ability to block users is also disabled as a restricted action per this Phabricator commit. EggRoll97 ^(talk) 23:38, 4 April 2024 (UTC)

I suspect the change they wanted was to make that part of the filter affect autoconfirmed users. They mention "If you look in the filter log for edits blocked by filter[..]"(emphasis mine), so I assume that's just another way of saying disallowed edits - but the one obvious change they do make is !"extendedconfirmed" in user_groups, currently the filter starts with !("confirmed" in user_groups).

No comments on the merits of the suggestion, or on if the start of that code would actually work(which I guess is a comment) – 2804:F1...53:DD84 (talk) 00:10, 5 April 2024 (UTC)

Replacement of Israel with Palestine

• Task: No knowledge of wikicodes, but it should apply to article namespaces, scanning for unautoconfirmed/IP edits, triggering when mentions of Israel/Hebrew is replaced with words like Palestine/Arabic/Levant.
• Reason: There is a increase, likely due to recent events in the number of disruptive edits around Israel articles being replaced with irrelevant informations and Palestine mentions.
• Diffs:

IP edit replacing contents. AlphaBetaGamma (Talk/Report any mistakes here) 00:54, 1 March 2024 (UTC)

I personally don't think this a good candidate for an edit filter because while it's sometimes disruptive this can be contextually dependent and should probably not be disallowed automatically. Philipnelson99 (talk) 01:07, 1 March 2024 (UTC)

@Philipnelson99I see. Where should this belong then? AlphaBetaGamma (Talk/Report any mistakes here) 01:37, 1 March 2024 (UTC)

I mean you're in the right place to request an edit filter, I'm just not sure this would be a good edit filter. If restricted to IPs/non-autoconfirmed that might reduce false positivess but I'm not convinced that would eliminate false positives altogether since it's hard to say if all replacements are disruptive. Happy to hear other opinions on it and it's really up to an EFM to decide to implement it. Philipnelson99 (talk) 01:47, 1 March 2024 (UTC)

This is 1154 (hist · log). Note that it logs both Israel -> Palestine and Palestine -> Israel. As Philipnelson99 points out, setting this sort of filter to disallow would be a bad idea, and even warning might open up a can of worms. Suffusion of Yellow (talk) 02:59, 1 March 2024 (UTC)

Suffusion of Yellow thanks for pointing out the logging filter, didn't realize it existed. I think logging is really the only reasonable course of action here. If an edit is indeed an issue, it will likely be reverted speedily. Setting a filter to warn when there's a chance that the edit was good faith and not intentionally disruptive seems unproductive to me. Philipnelson99 (talk) 03:09, 1 March 2024 (UTC)

Maybe tagging would work, as any good faith edits wouldn't be reverted but bad faith ones would be easier to see and thus revert? – PharyngealImplosive7 (talk) 14:41, 1 March 2024 (UTC)

I don't think tagging these filter hits is necessary. Philipnelson99 (talk) 17:31, 1 March 2024 (UTC)

Why do you think that? And I'm just curious that's all. – PharyngealImplosive7 (talk) 18:48, 1 March 2024 (UTC)

I’d like them tagged. I see these changes frequently, usually from IPs. Doug Weller talk 19:19, 6 April 2024 (UTC)

What would you suggest the tag be @Doug Weller? Something like Possible ARBPIA issue maybe? My concern with tagging is the area is a contentious topic and tagging these edits as a possible ARBPIA issue may need consensus elsewhere. Philipnelson99 (talk) 13:44, 9 April 2024 (UTC)

Possible a-i issue would be better. It seems obvious enough that I wouldn't think it needed consensus. I wouldn't mention ARBPIA as that's probably too strong. Doug Weller talk 13:52, 9 April 2024 (UTC)

Gotcha, as long as the tag isn't too strongly worded then I'm okay with tagging these. Just don't want someone to get the wrong idea that every filter hit has a problem. Philipnelson99 (talk) 14:09, 9 April 2024 (UTC)

References

Block "Billy Flowers" edits

• Task: For the last few days I've found various IPs adding material about a Billy Flowers(see [73]) Examples are "(the Quora user who is a big rival of Billy Flowers}", "Billy Flowers, the world famous debunker of atheism, attended this university.", "He has engaged in debates with [https://www.quora.com/profile/Billy-Flowers-21 Billy Flowers before, such as when he created a YouTube video with a response to Billy Flowers's famous question about skydiving wit, h a Christian baby.", "* Billy Flowers  – (born 1990), the man who debunked atheism"," Billy Flowers  – (born 1990), the man who debunked atheism". See also the edit susmmaries, link to two IPs below.
• Reason: to block the spam
• Diffs: See [[74]]. Unfortunately I didn't keep samples from other IP addresses. ALso found [75].

Doug Weller talk 12:26, 2 April 2024 (UTC)

Another IP. The usual plus a serious BLP violation. [[[Special:Contributions/70.33.148.202]] Doug Weller talk 20:46, 2 April 2024 (UTC)

Maybe we should add this to 614 (hist · log), with the regex billy?\sflowers, but the amount of false positives might be high due to legitimate uses of the name, so I would suggest that we test this out first on log only in a test filter to see how common these edits are and if the amount of false positives is manageable. – PharyngealImplosive7 (talk) 00:48, 3 April 2024 (UTC)

@PharyngealImplosive7 Now from Special:Contributions/70.33.148.202 Doug Weller talk 17:48, 3 April 2024 (UTC)

Yeah. It’s clear to me at this point that this needs to be filtered. – PharyngealImplosive7 (talk) 20:46, 3 April 2024 (UTC)

I've sent an email to the private abuse filter email list about this. Philipnelson99 (talk) 14:07, 9 April 2024 (UTC)

Thanks. Doug Weller talk 14:15, 9 April 2024 (UTC)

Filter 614

• Task: Prevents meme and vandalism trends
• Reason: Missing | between toilet and sigma causing it to not prevent “sigma” vandalism.
• Diffs: Special:Diff/1218047295

Nagol0929 (talk) 12:31, 9 April 2024 (UTC)

The issue here is that "sigma" has a lot of legitimate uses so we would need to see how many FPs are there first because it is used many times in articles like sigma, summation, and cross section, so maybe I'm wrong, but I think that was intentional. – PharyngealImplosive7 (talk) 13:28, 9 April 2024 (UTC)

You're correct. Preventing editors from adding the word sigma would cause far too many FPs. Philipnelson99 (talk) 13:37, 9 April 2024 (UTC)

 Not done "sigma" has plenty of valid uses --DannyS712 (talk) 19:32, 9 April 2024 (UTC)

This part of 1297 (hist · log) ("Mixed-use words"), which I just set to tag, and am refining to the point where it can be set to disallow. It will not catch every addition, only those with a some other hints of vandalism. Suffusion of Yellow (talk) 19:56, 9 April 2024 (UTC)

Also added "what the sigma" to filter 614. Suffusion of Yellow (talk) 01:26, 21 April 2024 (UTC)

Sciencedirect topics again

Following on from Wikipedia:Edit_filter/Requested/Archive_21#ScienceDirect_topics, per Wikipedia:Reliable_sources/Noticeboard/Archive_432#ScienceDirect_Topics_(AI-generated_pages), there is now clear consensus to implement an edit filter warning people against using Sciencedirect topics. Can this now be implemented? Thanks. Hemiauchenia (talk) 16:16, 10 April 2024 (UTC)

 Done ProcrastinatingReader (talk) 12:11, 11 April 2024 (UTC)

I've added it to the deprecated sources filter, as it's marked as deprecated at RSP and I think it's good to have our source-related filters limited to the deprecated subset as that's a streamlined community process. But I think the message in MediaWiki:abusefilter-warning-deprecated might be confusing to someone citing sciencedirect, at first glance very reliable in general.

I wonder if that message can be improved to indicate a) that it may not be the entire source that's deprecated, just a particular part of it; b) to have less focus on linking to RSN and more on "To see the restrictions that apply to this source and reasons, visit WP:RSP and find the relevant source in the list." ProcrastinatingReader (talk) 12:16, 11 April 2024 (UTC)

The is not going to be the last AI-generated source we want to stop. Maybe a separate filter for AI sources? Suffusion of Yellow (talk) 01:31, 21 April 2024 (UTC)

I think that's a great idea @Suffusion of Yellow! Philipnelson99 (talk) 02:02, 21 April 2024 (UTC)

I also think that's a good idea. – PharyngealImplosive7 (talk) 02:47, 21 April 2024 (UTC)

Sports team infobox (owner) vandalism

• Task: strengthen filter 735 to prevent vandal edits to sports infobox (unsure about technical feasibility; see discussion at WikiProject Ice Hockey archive)
• Reason: frequent vandalism, infrequent ownership changes (see discussion on WikiProject Ice Hockey archive)
• Diffs: waves of vandalism happen during playoffs and after significant losses, most recently [76][77][78]

Wracking ^talk! 17:21, 29 April 2024 (UTC)

I notified WT:HOCKEY, where this discussion began, of this request. Wracking ^talk! 17:27, 29 April 2024 (UTC)

The filter tags such edits for patrollers to review, but I'm a bit hesitant to allow this filter to disallow. Codename Noreste 🤔 La Suma 18:27, 29 April 2024 (UTC)

Given the examples of diffs you provided were reverted within minutes, I'm not sure this really needs to be set to disallow. I think the risk of FPs is too high for making this disallow. Philipnelson99 (talk) 18:44, 29 April 2024 (UTC)

I tweaked the filter to exclude whitespace and other minor changes. But there will probably still be too many FPs. Suffusion of Yellow (talk) 22:27, 29 April 2024 (UTC)

Your tweaks look fine to me @Suffusion of Yellow but I still don't think disallow is a good idea for this filter. Philipnelson99 (talk) 22:37, 29 April 2024 (UTC)

Thanks, Suffusion of Yellow, for the tweaks. I understand why the filter can't be set to disallow—I've edited my watchlist to try to catch more of these, and I'll just hold out hope that people realize at some point that it isn't that funny Wracking ^talk! 22:59, 29 April 2024 (UTC)

Disallow removing dates from maintenance templates

• Task: Preventing removal of dates from maintenance templates, except when also removing the template entirely.
• Reason: Dates are not meant to be removed from maintenance templates.
• Diffs: Special:Diff/1219740646 Special:AbuseLog/37613570 (add diffs as you see more such edits)
• Conditions: maintenance := "( |)(Citation needed|merge|Cite web|Cite Journalenumerate more maintenance templates here)";
temp := "(?i){{" + maintenance + "\|date=(January|February|March|April|May|June|July|August|September|October|November|December)*}}";
dateless := "{{" + maintenance + "}}";
!"confirmed" in user_groups & rcount(temp,new_wikitext) < rcount(temp,old_wikitext) & rcount(dateless,new_wikitext) = rcount(dateless,old_wikitext)

Faster than Thunder (talk | contributions) 16:08, 20 April 2024 (UTC)

Is this a common problem? This doesn't seem worth a filter if it only happens occasionally. There's the general issue of people opening a page and removing all the parts they don't understand before getting down to editing, but that's probably more frequent with references and lead-section templates. Suffusion of Yellow (talk) 20:02, 20 April 2024 (UTC)

The IP that made that edit also tried doing vandalism edits like these: log1, log2 and log3. Kind of puts all their other edits into question. – 143.208.238.228 (talk) 21:23, 20 April 2024 (UTC)

The inappropriate use of obscenities is the problem in the edits you brought up, but it is not the goal of my filter suggestion, which targets a different issue. Faster than Thunder (talk | contributions) 20:48, 21 April 2024 (UTC)

I was just pointing out that you picked an apparent vandal as your example of this happening. The point is that if you don't have any other examples then this could be a general issue like SoY says of people removing what they don't understand, but it could also just be one of this user's choice of vandalism - at which point maybe warning or blocking them would stop it from happening.

But I can't assume what it is, or that you don't have any other examples, so I just noted that the IP was trying to vandalise too. – 143.208.239.226 (talk) 02:52, 22 April 2024 (UTC)

Maybe we could start the filter with no actions enabled first. If the number of edits caught by the filter is significant enough, then we should set the filter to disallow. Faster than Thunder (talk | contributions) 22:50, 23 April 2024 (UTC)

Faster than Thunder, rather than edit_delta < 25 * rcount(temp,removed_lines), do you have another rule format to check the removal of dates in the {{Citation needed}} template? I tested your filter conditions under FilterDebugger and it only showed a check, meaning that there was no indication of the removal of the date, and the regular removed_lines rlike temp did not detect that removal at all.

Also, I'm a little bit hesitant to support the implementation if this only happens occasionally. Codename Noreste 🤔 La Suma 03:57, 24 April 2024 (UTC)

Yeah I agree with you here. Filters should only be used when something problematic happens frequently enough to warrant an entire filter. – PharyngealImplosive7 (talk) 13:39, 24 April 2024 (UTC)

I was saying that we should start the filter with no actions enabled first, then eventually decide whether to set the filter to disallow. Faster than Thunder (talk | contributions) 18:47, 25 April 2024 (UTC)

I think what me and the others mean is that there is no purpose to make a filter, even if it's only going to be log-only, if this isn't a common problem. And disallow filters to warrant having disallow need to have no other way but to stop the problematic action from happening at all. – PharyngealImplosive7 (talk) 19:53, 25 April 2024 (UTC)

How do I use FilterDebugger to test a filter idea on an edit? I want to see if my idea works on the edit in question. Faster than Thunder (talk | contributions) 15:53, 26 April 2024 (UTC)

Faster than Thunder, see User:Suffusion of Yellow/FilterDebugger#Installation. Codename Noreste 🤔 La Suma 18:38, 27 April 2024 (UTC)

I fixed any issues, and intentionally triggered another edit filter. After debugging its filter log entry, I found that it works correctly. Faster than Thunder (talk | contributions) 23:34, 30 April 2024 (UTC)

Filter 260 (Common vandal phrases)

I think we should add "skibidi" to this filter because a lot of disallowed vandalism tries to add "skibidi" if you check in the filter log. Faster than Thunder (talk | contributions) 18:11, 1 May 2024 (UTC)

See also #Skibidi Toilet vandalism above. Certes (talk) 18:51, 1 May 2024 (UTC)

I don't see the point in adding the same phrase to multiple filters. Philipnelson99 (talk) 19:14, 1 May 2024 (UTC)

The purpose of filter 260 is to distinguish vandals who should be blocked from those that should be warned. Faster than Thunder (talk | contributions) 23:16, 1 May 2024 (UTC)

Yeah, that comment is way out of date. 260 (hist · log) is just a cruft-magnet of slurs, dick jokes, stale memes, and even more stale LTA phrases. I'm slowly moving various bits into other filters. Suffusion of Yellow (talk) 23:36, 1 May 2024 (UTC)

No rcats?

• Task: Simple, see created redirects without any rcats, tell the editor to add some rcats.
• Reason: Too many redirects without rcats.
• Diffs: I can add links if needed, but seems self explanatory.

~~~~ Geardona (talk to me?) 05:04, 12 March 2024 (UTC)

It might be useful for this to not be a in-the-face notice but rather a filter that passively tags edits, atleast as a start. Sohom (talk) 05:27, 12 March 2024 (UTC)

Possibly through the following?

article_articleid == 0 &

(
 article_namespace == 0 &
 (
  new_wikitext rlike "#REDIRECT" &
  !new_wikitext rlike "(?i)(\{\{R from}\})"
 )
)

I checked this through batch testing, it already matched two redirects created and didn't show any false positives for the 2 edits it matched. Probably best to start on a filter with no actions rather than straight to tagging. EggRoll97 ^(talk) 19:03, 22 March 2024 (UTC)

Just to note that there are rcats/rcat redirects/rcat wrappers that don’t start with {{R from - e.g. {{avoided double redirect}}, {{NASTRO comment}}, {{television episode redirect handler}}. As an aside, should pages like Wikipedia talk:Redirect be notified of this proposal? All the best. ‍—‍a smart kitten_[meow] 20:38, 22 March 2024 (UTC)

Interesting, might just have to add those to a list, or change it to {{.*(Redirect|R from).*}}
Yes they should be notified Geardona (talk to me?) 21:28, 22 March 2024 (UTC)

Tested that new condition, and it should work, with a modified proposed filter of:

article_articleid == 0 &

(
 article_namespace == 0 &
 (
  rcats := "\{\{.*(redirect|r from|r to).*\}\}|\{\{NASTRO comment\}\}";

  new_wikitext rlike "#REDIRECT" &
  !new_wikitext irlike rcats
 )
)

Verified against 3 different redirect creations, it matched each one. EggRoll97 ^(talk) 02:57, 23 March 2024 (UTC)

Nice, if that is all for the filter work, I will inform the talk page for redirects. Geardona (talk to me?) 03:02, 23 March 2024 (UTC)

This would probably miss {{R to section}}. Sohom (talk) 03:09, 23 March 2024 (UTC)

It would, this will fix that
{{.*([Rr]edirect|R from|R to).*}} Geardona (talk to me?) 03:11, 23 March 2024 (UTC)

Modified the one I just pasted in for easy review. EggRoll97 ^(talk) 04:26, 23 March 2024 (UTC)

I'm also editing the proposed filter syntax so everything can start uppercase or lowercase, not just 'redirect'. – PharyngealImplosive7 (talk) 19:52, 23 March 2024 (UTC)

Also adding NASTRO Comment as part of the functionality. – PharyngealImplosive7 (talk) 19:57, 23 March 2024 (UTC)

There is a "irlike" for case insensitive matching. – 2804:F1...01:18F4 (talk) 00:49, 29 March 2024 (UTC)

Yeah I will change that. – PharyngealImplosive7 (talk) 00:53, 29 March 2024 (UTC)

Implementing some more edits to the proposed filter to make it more efficient. – PharyngealImplosive7 (talk) 01:38, 3 April 2024 (UTC)

@EggRoll97: would you mind implementing the filter and creating it as log only or maybe tag now that you are an EFM? 24.4.109.4 (talk) 00:31, 5 April 2024 (UTC)

@24.4.109.4: I'm doing so right now, just double-checking through batch for good measure, even for log only. EggRoll97 ^(talk) 00:32, 5 April 2024 (UTC)

Ok great. 24.4.109.4 (talk) 00:37, 5 April 2024 (UTC)

This is now  Done as 1298 (hist · log) as log-only. EggRoll97 ^(talk) 00:38, 5 April 2024 (UTC)

@EggRoll97: You might want to change rcats := "\{\{.*(redirect|r from|r to).*\}\}|\{\{NASTRO comment\}\}"; into rcats := "\{\{.*(redirect|r from|r to|NASTRO comment).*\}\}" to condense the regex a bit more. – PharyngealImplosive7 (talk) 01:02, 5 April 2024 (UTC)

@EggRoll97: Also, turns out article_articleid and article_namespace are deprecated: Rules format – 2804:F14:80EC:AB01:DD3F:A8CA:F653:DD84 (talk) 01:20, 5 April 2024 (UTC)

In addition, the filter's conditions should be the following:

page_id == 0 &
(
    page_namespace == 0 &
    (
        rcats := "\{\{.*(redirect|r from|r to|NASTRO comment).*\}\}";

        new_wikitext rlike "#REDIRECT" &
        !new_wikitext irlike rcats
    )
)

One question: do we need the filter to log every single redirect creation without rcats, regardless if the user who created it is experienced or not? Codename Noreste 🤔 talk 01:26, 5 April 2024 (UTC)

We should. This is a mistake that even experienced users make sometimes. 24.4.109.4 (talk) 01:28, 5 April 2024 (UTC)

Excuse me if this question comes across as rude, but who are you? I tried looking at the previous history of your IP, but it has been mostly vandalism. – 2804:F14:80EC:AB01:DD3F:A8CA:F653:DD84 (talk) 01:35, 5 April 2024 (UTC)

It’s perfectly fine to ask and no offense taken. I am just a regular IP, and if you look back to my edits from January, it will look more clear. My IP just changed sometime in February to a vandal. 24.4.109.4 (talk) 02:12, 5 April 2024 (UTC)

I've added in the regex and changed the deprecated variables out for page instead of article. As for user experience, it might be worthwhile to exclude bots, but other than that, it seems as though valid filter hits even occur on sysops, so given this is just a log-only filter, it may be best to keep it without exceptions for now. EggRoll97 ^(talk) 04:30, 5 April 2024 (UTC)

It might be worthwhile to add something like !("bot" in user_groups) but I know of no bot that creates redirect pages (though I could be mistaken as I don’t go into that part of Wikipedia often). – PharyngealImplosive7 (talk) 18:18, 5 April 2024 (UTC)

Shouldn't the filter exclude exoerienced users? Every 10 minutes or so, one of the redirect creations are, and would be tagged with this. Any thoughts? Toadette ^{(Let's talk together!)} 21:21, 5 April 2024 (UTC)

@ToadetteEdit: No objections to limiting this a bit, though experienced users seem to be the main ones actually tripping this filter. If we limit it down to only new editors that are creating non-categorized redirects, there would indeed be a lower filter rate though, yes, though as far as I can tell the intent of the filter request was to catch all the uncategorized redirects. Will leave for feedback for a day or two before limiting though. Obligatory ping to @24.4.109.4, Codename Noreste, PharyngealImplosive7, and Geardona: as they were involved in creation. EggRoll97 ^(talk) 21:41, 5 April 2024 (UTC)

Exempting bots should do, although experienced editors do make redirects but sometimes forget to add rcats. My redirect creation (La Sultana del Norte) to Monterrey counts as one. Codename Noreste 🤔 talk 21:44, 5 April 2024 (UTC)

I also believe that experienced editors should be included on this filter because they do forget to categorize their redirects. – PharyngealImplosive7 (talk) 21:53, 5 April 2024 (UTC)

@EggRoll97: I believe that this would work well as a filter that tags edits also as most of the 500 ish edits triggered are non-FPs and it would work well to categorize such edits. – PharyngealImplosive7 (talk) 21:56, 5 April 2024 (UTC)

Also pinging another IP, @2804:F14:80EC:AB01:DD3F:A8CA:F653:DD84:, who was involved in creation. – PharyngealImplosive7 (talk) 21:58, 5 April 2024 (UTC)

Pinging IPs doesn't do anything btw, though you might already know that. I just helped with the syntax. I want to point out though, that @Geardona said "[..]tell the editor to add some rcats", which sounds like they want a warn filter - pretty sure that would require community consensus, in whatever forum is most appropriate(i.e. likely not here). Unless just logging is sufficient?

Also on the syntax thing again, it looks like there are still a few variations of rcats listed at WP:ALLRCATS that the filter wouldn't recognize, other "R word" variations. – 2804:F14:8090:C501:8CF5:7412:F217:B3C2 (talk) 22:54, 5 April 2024 (UTC)

Would prefer a warning before saving, having a log would be fine as well. What other variations may need to be added? not sure about the community consensus bit, although WP:VPM, WP:VPR or WP:VPT might work Geardona (talk to me?) 22:59, 5 April 2024 (UTC)

Looking at it now, what would the issue with doing {{.*R.*}} that should hit every possible redirect template, as long as it stays only on #redirect pages. Geardona (talk to me?) 23:07, 5 April 2024 (UTC)

{{R avoided double redirect}}, {{R mentioned in hatnote}}, some {{R ME ..}}(Middle-earth) ones, some {{R comics ..}} ones, {{R for convenience}}, {{R with possibilities}}, etc(?).

Might be better to just look for an r, yeah. – 2804:F1...17:B3C2 (talk) 23:10, 5 April 2024 (UTC)

True. I don’t think people would add other templates on a redirect page with r in them, and we shouldn’t forget about {{NASTRO comment}}. – PharyngealImplosive7 (talk) 23:14, 5 April 2024 (UTC)

It would pick up the R in NASTRO so thats not a huge issue. Geardona (talk to me?) 23:17, 5 April 2024 (UTC)

I just realized that. See my next comment. I’m extremely worried about the amount of FPs though, as this will match huge numbers of different templates, many having nothing to do with rcats. – PharyngealImplosive7 (talk) 23:19, 5 April 2024 (UTC)

Except {{NASTRO comment}} has an r in it so it would be included too by the filter. The amount of FPs might be concerning in here though, so maybe .*\br\b.* and code for NASTRO comment should work and minimize the amount of FPs. – PharyngealImplosive7 (talk) 23:18, 5 April 2024 (UTC)

False negatives, you mean? And I don't think so, though admittedly I haven't checked, how common is it for people to create a redirect with a template that includes an R that isn't an rcat? Also this isn't looking for abuse or anything, so presumably no one is going to try to bypass the filter. – 2804:F14:8090:C501:8CF5:7412:F217:B3C2 (talk) 23:21, 5 April 2024 (UTC)

That sounds good, is there a way to look for FP's using logging? Geardona (talk to me?) 23:21, 5 April 2024 (UTC)

Yeah. Look through all the times the filter was triggered and see if you find a false positive or negative. It’s tedious but the only method I know of. If the amount of templates with r in them is small enough, the regex could always be changed to \{\{.*r.*\}\} but someone should check the logs to understand how many false negatives we’re going to be dealing with, telling us whether we need something generic or to specify every variation individually. – PharyngealImplosive7 (talk) 23:39, 5 April 2024 (UTC)

All right, we should get the regex ready and tested before going to any of the village pumps, if someone could set that up so we could review it that would be great. (log only, no warning) Geardona (talk to me?) 23:42, 5 April 2024 (UTC)

Having now properly read the thread, I see the filter. Geardona (talk to me?) 23:52, 5 April 2024 (UTC)

@Geardona: I think the main question to you, before I pinged you because I was sure you wanted a warn filter, was what you think of Toadette's question about making the filter not go off on extended-confirmed edits *experienced users, which EggRoll97 then pinged you about.

@PharyngealImplosive7: A false negative in this case, would be an edit that creates a redirect without an rcat, but that does not set off the filter, so there would be no logs to check. You would need to use a test filter or something to see if those edits even exist. – 2804:F14:8090:C501:8CF5:7412:F217:B3C2 (talk) 00:05, 6 April 2024 (UTC) *edited 00:14, 6 April 2024 (UTC)

Oh I am sorry, I would say that theres no reason to keep it to new users/ip's as its supposed to be a filter that gets rcats on every single new redirect. (sorry, I clearly need to focus) Geardona (talk to me?) 00:09, 6 April 2024 (UTC)

I think that going through the list of rcat templates and seeing what doesn’t match the current regex, for example all the comic and middle earth templates could be the best thing us non EFMs can do. Otherwise an EFM could always use a test filter. My point about false positives and negatives still does stand though. – PharyngealImplosive7 (talk) 00:19, 6 April 2024 (UTC)

I'll try to summarize:
0. The filter created for this was 1298 (hist · log);
1. Toadette asked "Shouldn't the filter exclude exoerienced users?[..]"

Comment by Geardona about that above (Geardona is the one who suggested the filter);

2. EggRoll97 also commented on the possibility of excluding bots (2 people agreed with that);
3. There are more rcat variants listed in WP:ALLRCATS (examples: link);

On that end it might be possible to just match \{\{.*r.*\}\}, discussion ongoing;

4. I point out and asked that Geardona appears to be asking for a warn filter, Geardona confirmed that.

I'm pretty sure this would require community consensus, though Geardona wants the regex ready and tested before starting any discussion about that (no one else besides Geardona commented on this yet);

– 2804:F1...17:B3C2 (talk) 00:31, 6 April 2024 (UTC)

As PharyngealImplosive7 briefly commented on, is there actually a bot that creates redirects? – 2804:F1...17:B3C2 (talk) 00:45, 6 April 2024 (UTC)

I see a few, but they all use rcats. AnomieBOT and RussBot. Geardona (talk to me?) 00:50, 6 April 2024 (UTC)

I support excluding bots, but oppose adding a warning. Log-only seems to do the job well. Codename Noreste 🤔 talk 00:51, 6 April 2024 (UTC)

Oh no, SoY is ranting again. Allow me to strenuously object to any sort of warning. Last night when I was bit tired, I decided to create a new redirect at maximal repeat. I usually don't bother with rcats, but this time I decided to do the "right" thing. It took me about five minutes to sift through the sea of tiny text at Template:R template index and figure that, no, even through I was redirecting from a phrase, the correct (?) template was {{r from related word}}. Or wait, was it {{r to related topic}}? Whatever, toss a coin. I can easily understand why people don't bother.

This is about edits that are unfinished, not harmful. A redirect without rcats is a net positive. A tagging filter is an excellent idea; it helps people who like categorizing redirects find the redirects to categorize. But a warning filter would be bitey to new users and irritating to experienced ones. Suffusion of Yellow (talk) 00:57, 6 April 2024 (UTC)

Yeah. Tagging would be a better idea in my opinion to. I also don’t categorize my redirects and sometimes it’s just annoying to find the correct category to use. – PharyngealImplosive7 (talk) 01:17, 6 April 2024 (UTC)

Also pinging @EggRoll97: as I’m sure they’re interested in the recent ideas for changing the filter by possibly making it more generic and making it exclude bots and tag edits passively. – PharyngealImplosive7 (talk) 02:51, 6 April 2024 (UTC)

Also not seeing any value in a warning filter. This filter is specifically designed to catch good-faith edits so someone else can come along and fix the redirect. I'm not a fan of tagging yet though until this whole idea of the r versus the current code is figured out. I did a couple of batch tests with that new \{\{.*r.*\}\} instead, and it seems to be working, but I'll hold off until the morning before I run it against a couple more edits and implement. Probably will go ahead and apply the tags at that point unless any objections arise overnight. EggRoll97 ^(talk) 05:11, 6 April 2024 (UTC)

As an update, tagging is now  Done and fully enabled as uncategorized-redirect . You can track changes in Special:RecentChanges as well as via the hit log for 1298 (hist · log). EggRoll97 ^(talk) 18:52, 6 April 2024 (UTC)

@EggRoll97: Would it be better to check if the user is a bot after you check if it's a new page in article space? I think currently it's always checking if every user doing any action is a bot, probably why the average conditions are now 1.9 instead of 1.

Also, unless bots are going to create a significant amount of redirects (and often), this check is probably pointless. – 2804:F14:8090:C501:5CC4:7D96:1106:13FE (talk) 21:36, 6 April 2024 (UTC)

Looks like changes were made by Zzuuzz. EggRoll97 ^(talk) 01:35, 7 April 2024 (UTC)

New Filter Request - "Skibidi Toilet"

• Task: Stop users from inserting the word "skibidi", "skibidi toilet", and such into talk pages.
• Reason: Vandalisers are adding this internet meme into Wikipedia talk pages.
• Diffs: https://en.wikipedia.org/w/index.php?title=Talk:Battle_of_Antietam&diff=prev&oldid=1223088641

Myrealnamm (💬talk · ✏️contribs) at 20:47, 9 May 2024 (UTC)

Oh, the previous request is similar. Myrealnamm (💬talk · ✏️contribs) at 20:47, 9 May 2024 (UTC)

That could be accomplished by expanding 614 (hist · log) to article talk pages. Here's a quick test from last month. Suffusion of Yellow (talk) 21:05, 9 May 2024 (UTC)

@Suffusion of Yellow Example: https://en.wikipedia.org/w/index.php?title=Stuart_Gibbs&curid=54184329&diff=1223521681&oldid=1223051823 Myrealnamm (💬talk · ✏️contribs) at 18:13, 12 May 2024 (UTC)

They didn't use "skibidi", they used "skbidi". Maybe all forms of "skibidi", including typos such as "skbidi" and "skibid" should be added to the filter as well. Myrealnamm (💬talk · ✏️contribs) at 18:14, 12 May 2024 (UTC)

Creating mainspace articles which begin with your username

• Task: (This is my first post here, so please let me know how I borked it up.)

  I think a filter which logs (and eventually warns?) people who attempt to create an article which begins with your username would be beneficial. I have seen multiple people who create (e.g.) HouseBlaster/sandbox as opposed to User:HouseBlaster/sandbox (and I have personally done something similar).

  It also might catch people who try to write autobiographies and people whose usernames violate WP:CORPNAME, both of which seem like positive side-effects.

• Reason: Self-explanatory
• Diffs: They are all deleted fairly quickly as WP:G6 (if it is a benign mistake), and I don't have any evidence that the autobiography/CORPNAME thing is a problem (I just think that it is a something else which this filter would happen to catch).

Thanks, HouseBlaster (talk · he/him) — Preceding undated comment added 13:49, 17 May 2024 (UTC)^<diff>

Something like the following, maybe? '''[[User:CanonNi]]''' (talk • contribs) 13:54, 17 May 2024 (UTC)

Don't we already have Special:AbuseFilter/148 or something similar? Codename Noreste 🤔 La Suma 00:51, 18 May 2024 (UTC)

My proposal is slightly different, in that it would catch people with more than 100 edits who make a mistake rather than a deliberate attempt to create an autobiography. HouseBlaster (talk · he/him) 01:09, 18 May 2024 (UTC)

page_id == 0 &
(
 page_namespace == 0 &
 (
  page_title rlike user_name | user_name in page_title
 )
)

Such a filter might make life interesting for the likes of User:F, but generally there seem to be few false positives. Certes (talk) 17:43, 18 May 2024 (UTC)

Would it make sense to additionally check that the title/username is longer than x? Not sure which is more efficient. HouseBlaster (talk · he/him) 17:46, 18 May 2024 (UTC)

Possibly. We might also need to convert spaces to underscores in user_name before matching to page_title. This query may be of interest. Certes (talk) 18:13, 18 May 2024 (UTC)

Disallow changing result parameter on Infobox military conflict by IPs/new users

Per this discussion (pinging @GreenC):

• Task – In the |result= parameter of {{Infobox military conflict}}, disallow edits between sides of "X victory", in addition to edits away from or between "X victory", "Inconclusive", and "See (article section)" by IP addresses or very new users.
• Reason – Widespread tendentious editing by those unfamiliar with site guidelines, at a bare minimum with MOS:MILHIST. After parameter is in accordance with said guideline, it almost never needs to be changed.
• Diffs:
  • Fourth Crusade
  • Battle of Karnal
  • First Chechen War

Remsense诉 01:17, 11 May 2024 (UTC)

This is a hard one, because there could be so many false positives, like if someone corrects a typo in the result parameter and gets a disallow message. I would suggest something like tag or warn at most unless someone can find a non FP-prone way of filtering these types of edits, but this should definitely be a log-only filter at first. The regex should also probably be similar to something like 391 (hist · log). – PharyngealImplosive7 (talk) 02:15, 11 May 2024 (UTC)

Agreed that initial caution is required, but unfortunately I don't see a warning saying "changes require reliable sources" being effective in the end? Remsense诉 02:21, 11 May 2024 (UTC)

Totally agreed. But first we should make the filter ready to be disallowed by minimizing the amount of FPs as much as possible. – PharyngealImplosive7 (talk) 03:15, 11 May 2024 (UTC)

@Remsense: As to the prospect of disallow, I'm going to say  Not done. The top of this page even states, Edit filters are used primarily to prevent abuse. Contributors are not expected to have read all 200+ policies, guidelines and style pages before editing, and I don't think it's a far stretch to assume that edits are all in bad faith. Even in the diffs provided, the edit to Fourth Crusade seems misguided and wrong, but not necessarily in bad faith. Any filter that catches this would end up with a non-zero amount of false positives. I'm not against a log or maybe a tag filter, though. I'll see if I can work one up, but if anyone wants to have a shot at trying the code in the meantime feel free. EggRoll97 ^(talk) 04:04, 24 May 2024 (UTC)

Vandalism to meme pages

• Task: Filter 614 exists for a reason, but it doesn't catch edits like the ones mentioned below:
• Reason: To catch vandalism to meme pages like Skibidi Toilet
• Diffs: Special:AbuseLog/35756965 Special:AbuseLog/35699619 Special:AbuseLog/37436369 Special:AbuseLog/30671860
• Conditions: meme := "(?i)(" + str_replace(str_replace(page_title,"(the|or|and)","")," ","|") + ")";

bad_desc := "(cringe|worst|best)"; any_meme := "(skibd|skidibi|skibid|rizz|bozo|\(meme\))"; meme_cat := "(meme\}\}|fads\]\]|trends\]\]|slang\]\])"; !"confirmed" in user_groups & page_title irlike any_meme & ( rcount(meme, added_lines) / 3 > rcount("\.", added_lines) + 0.5 | /* prevent excessive use of the meme */ rcount(bad_desc,added_lines) > 3 | /* prevent defamation of the meme */ (removed_lines irlike meme_cat & !old_wikitext irlike meme_cat) /* prevent decategorization from meme categories */ )

• Actions: Disallow

Faster than Thunder (talk | contributions) 01:06, 6 May 2024 (UTC)

Looks like the third filter log entry should be disallowed by filter 1233 (hist · log) but wasn't caught, the second log entry looks like your everyday run-of-the-mill disruption, and the first log entry is likely low-effort disruption that may want to be prevented by some filters. Maybe we could set 1163 (hist · log) to warn+tag or disallow.

By the way,  !( (removed_lines + page_title) irlike abuseStr) basically means that Skibidi Toilet additions are excluded from said article describing this meme itself. Codename Noreste 🤔 La Suma 02:13, 6 May 2024 (UTC)

Also, please note that before disallowing, we always test filters on log or tag before to minimize the possibility of a huge amount of false positives. If this is made into a seperate filter then, I highly doubt it will be set to disallow immediately. – PharyngealImplosive7 (talk) 13:45, 6 May 2024 (UTC)

I hereby retract saying to set 1163 to disallow after seeing your comment, but couldn’t we at least set this to warn with the tag? Codename Noreste 🤔 La Suma 14:58, 6 May 2024 (UTC)

Yes, but I believe that usually, filters are first set to log or tag just to see if they work well or not, as even warning could be problematic if the filter has too many FPs. – PharyngealImplosive7 (talk) 15:01, 6 May 2024 (UTC)

Can someone start this filter with no actions enabled first please? Faster than Thunder (talk | contributions) 20:43, 8 May 2024 (UTC)

Can you break down what each part of that filter is trying to do? It doesn't make sense to me. Suffusion of Yellow (talk) 21:06, 8 May 2024 (UTC)

Done. Faster than Thunder (talk | contributions) 22:45, 8 May 2024 (UTC)

Done. Faster than Thunder (talk | contributions) 21:22, 8 May 2024 (UTC)

Alright. So we have:

meme := "(?i)(" + str_replace(page_title," ","|") + ")";

and

length(meme) * 2 < rcount(meme,added_lines) | // prevent excessive use of the meme

First, you're generating meme by splitting apart the title. That's clever, but what about a title like "Bozo the Clown"? One of your words is going to be "the". Second, rcount() counts the total number of matches, not the total length of the matches put together. If you want to prevent excessive use of a word, say something more like:

rcount(meme, added_lines) - rcount(meme, removed_lines) > 2

But I don't that's a good idea. It's natural for the title of the article to be repeated many times throughout the page.

Now we have:

get_matches(bad_desc,added_lines) > 3 | // prevent defamation of the meme

But get_matches() returns a fixed-size array. I'm not sure what the "3" is supposed to mean.

And finally:

(removed_lines irlike meme_cat & !old_wikitext irlike meme_cat) // prevent decategorization from meme categories

This won't match anything, but could be fixed by using added_lines instead of old_wikitext. But we already have 132 (hist · log) for category removal.

Thanks for this, but I think it's just inevitable that "meme pages" are going to end up semi-protected, at least temporarily. There are just too many creative ways to vandalize. Suffusion of Yellow (talk) 21:24, 9 May 2024 (UTC)

Maybe the 3 in get_matches(bad_desc,added_lines) > 3 | // prevent defamation of the meme is supposed to be compared to the array length so maybe @Faster than Thunder really just meant length(get_matches(bad_desc,added_lines)) > 3. I also do sadly agree that vandalism to meme pages is bound to happen, and we'll probably need to protect them at some point. – PharyngealImplosive7 (talk) 22:34, 9 May 2024 (UTC)

@Faster than Thunder: Also, if we have a bad_desc variable to prevent defamation, wouldn't another issue be to say that the meme is the "best"? So would it also be a good idea to create a separate variable to prevent additions like that? – PharyngealImplosive7 (talk) 02:57, 10 May 2024 (UTC)

I implemented your suggestions. Faster than Thunder (talk | contributions) 17:40, 14 May 2024 (UTC)

Could we also block "skibidi toilet", "skibidi", and such as per the thread below? I don't know how the filters work. Myrealnamm (💬talk · ✏️contribs) at 19:17, 14 May 2024 (UTC)

They are already added because of "skibid." Faster than Thunder (talk | contributions) 19:34, 16 May 2024 (UTC)

See this, which an IP vandalized using "skibidi toilet" as the edit summary. This should be added @Faster than Thunder. Myrealnamm (💬talk · ✏️contribs) at 23:37, 23 May 2024 (UTC)

That is the wrong filter to request it in, because that was in another article, but this could be added to a new filter idea or something like 614 (hist · log). – PharyngealImplosive7 (talk) 00:32, 24 May 2024 (UTC)

Very funny. XD Faster than Thunder (talk | contributions) 20:22, 24 May 2024 (UTC)

Now that some improvements have been made to the filter idea, what new changes need to be made to the filter before it can be created? Faster than Thunder (talk | contributions) 17:39, 22 May 2024 (UTC)

I share the same concerns as SoY. Vandals on meme pages are going to come up with new ways faster than a filter can catch them, and it's far more efficient to just protect the small number of "meme-type" pages than to try and craft a filter that has every single variation and type of petty vandalism out there. It's possible for general vandalism filters, because the terms in those are spread throughout the encyclopedia, but for specific pages, it's going to just end up with vandals getting around the filter on purpose. EggRoll97 ^(talk) 22:29, 26 May 2024 (UTC)

@EggRoll97 That's very true. However, these vandals seem to vandalize with "meme words" on all the pages, so hmmmm. Myrealnamm (💬talk · ✏️contribs) at 00:22, 27 May 2024 (UTC)

Yeah. I think the best thing to do is to just semi-protect the meme pages, instead of creating and constantly changing a filter that won't catch all the vandalism sadly. – PharyngealImplosive7 (talk) 04:45, 27 May 2024 (UTC)

"Skibidi" username filter

I've noticed that new usernames which contain "Skibidi" in them often are used only for disruption/vandalism/trolling. Is there any way we could add a filter which blocks all usernames with "Skibidi" and/or sends them to UAA? If you reply here, please ping me. Thanks — thetechie@enwiki: ~/talk/ $ 02:33, 29 May 2024 (UTC)

I'm not sure if creating a filter that prevents Skibidi (toilet) usernames is necessary (after all, it compares every account creation when set to action == "createaccount"); there is User:AmandaNP/UAA/Blacklist in which you can propose adding s+k+[i1bdt]{4,}y*\b on the talk page. Codename Noreste 🤔 La Suma 03:15, 29 May 2024 (UTC)

Also note that the regex above would need to be continuosly updated as the filter changes. – PharyngealImplosive7 (talk) 19:47, 29 May 2024 (UTC)

Not really; there's no need to catch them all. I don't like disallowing usernames which scream "I am NOTHERE" but aren't so offensive as to require a revdel; those usernames just make the vandalism easier to spot. (Plus the first word to disallow should be "Truth".) And reporting to UAA on account creation isn't really helpful unless the username is block-on-sight. They might wait hours or days to edit, or never edit at all. Now, we could have filter which reports to UAA on the first edit, at which point it's usually clear what the user is up to. But as CN points out, DeltaQuadBot already does that, so why not just add to DQB's list? Suffusion of Yellow (talk) 19:56, 29 May 2024 (UTC)

Malformed requests at WP:AFC/R

• Task: Prevent the addition of malformed requests at WP:Articles for creation/Redirects
• Reason: Persistent spam
• Diffs: Proper:[79][80]; Malformed:[81][82]

I'm not good at this, but something like this might work:

format := "
^== .* ==\n
*Target of redirect:\[\[.+\]\]\n
*Reason:.*\n
*Source (if applicable):.*\n
<references />\n
~~~~$
"

!( "confirmed" in user_groups ) &
page_title == "Articles for creation/Redirects" &
!(added_lines_pst rlike format)

'''[[User:CanonNi]]''' (talk • contribs) 07:09, 3 June 2024 (UTC)

@CanonNi: This seems like a single-page issue, which is more of an WP:RFPP thing. Maybe pending changes protection to that page could help? EggRoll97 ^(talk) 18:58, 3 June 2024 (UTC)

Yeah. That is a fair point, but we do have similar filters for WP:RFPP (filter 1291 (hist · log)) so this is not unheard of. – PharyngealImplosive7 (talk) 21:55, 3 June 2024 (UTC)

Good point. I've requested protection at RFPP. '''[[User:CanonNi]]''' (talk • contribs) 23:57, 3 June 2024 (UTC)

Prevent addition of word "incel"

• Task: Prevent non-autoconfirmed from adding the word "incel" to article space.
• Reason: This word is mostly used for vandalism and particularly affects BLPs. It should be prohibited like the rest of zoomer/moomer slang used in vandalism.
• Diffs: example

Air on White (talk) 21:21, 9 June 2024 (UTC)

I can see legitimate use for the word as something someone has called themselves, or for talking about such people. So this shouldn't be done without a whitelist. - Sumanuil. _{(talk to me)} 08:02, 10 June 2024 (UTC)

Yes. There are literally hundreds of articles that use the word correctly, most of which are not BLPs. There's also a company and a drug called "Incel". Black Kite (talk) 08:24, 10 June 2024 (UTC)

At least add it. Filter 614 allows individual use of terms like "gyatt" and "rizz" but bans them in combination. Air on White (talk) 09:14, 10 June 2024 (UTC)

What about that at least add this to tag-only 189 (hist · log) for BLP articles? Codename Noreste 🤔 Talk 18:23, 10 June 2024 (UTC)

How many times does a person add "incel" to a BLP to vandalize it? How many times in contrast does a living person actually describe themselves as an incel with RS to back it up? The ratio is too high for non-autoconfirmed to keep adding the term. We ban Blogspot, the Daily Mail and Breitbart for the same reason even though they have conceivable legitimate uses. Air on White (talk) 09:17, 10 June 2024 (UTC)

Here's another catch: pages where the use of "incel" is legitimate are likely already semi-protected due to incel-related vandalism. Air on White (talk) 09:49, 10 June 2024 (UTC)

I would suggest that we test it out and refine the regex at 189 (hist · log) as Codename Noreste suggested, where we can see the FP rate and if this addition is really needed first. If it seems to be effective and useful, we can move it to a disallow filter. – PharyngealImplosive7 (talk) 18:28, 10 June 2024 (UTC)

Prevent self-promotion on Talk:Instagram

• Task: A new filter could prevent the non-autoconfirmed from adding links to instagram[.]com to Talk:Instagram.
• Reason: There has been a persistent problem with self-promotion on Talk:Instagram where users link their Instagram profiles or posts in an attempt to gain followers. This advertising is quickly reverted. Semi-protection has been applied as a countermeasure, though the protecting admin has admitted that this isn't ideal (see Wikipedia:Requests for page protection/Archive/2024/06). I believe that this filter would be a better alternative than protecting a talk page.
• Diffs: Examples of such promotion: [83] [84]

Air on White (talk) 00:21, 5 June 2024 (UTC)

Support such a filter, with the result being Disallow. thetechie@enwiki: ~/talk/ $ 02:08, 5 June 2024 (UTC)

Wait... isn't the talk page already semi-protected? '''[[User:CanonNi]]''' (talk • contribs) 02:10, 5 June 2024 (UTC)

Semi-protection recently expired; immediately after, the page started being bombarded with promotion. It was soon semi-protected again. I am requesting a filter because it is better than semi-protecting. Air on White (talk) 02:47, 5 June 2024 (UTC)

Which is why I agree. Just saying. thetechie@enwiki: ~/talk/ $ 03:12, 5 June 2024 (UTC)

I took a superficial look of the last 50+ edits and I'm not convinced that self-promotion (adding links) is even 1/4th of the disruption, so I don't foresee the protection being removed even if this filter is made. – 2804:F14:80BE:B501:BC28:2F:9049:1F4D (talk) 07:16, 5 June 2024 (UTC)

Also, in general, I would say that this is a too temporary (probably) and localized issue to warrant a whole new filter. Page protection (semi or pending changes) should be the way to work. – PharyngealImplosive7 (talk) 18:20, 10 June 2024 (UTC)

Yeah...I can't see a filter being much better at this than semi-protection. Probably going to be more of a  Not done for now. EggRoll97 ^(talk) 04:05, 12 June 2024 (UTC)

Prevent non-autoconfirmed creating IP userpages

• Task: Non-autoconfirmed users and IPs should not be able to create userpages that are not of their own IP.
• Reason: I discover and nominate at least one such page every week. Most seem to be created in error, and users should be warned to create pages at the right title. A disproportionate number of such pages, however, are spam or vandalism. There is also an LTA who persistently creates userpages for IPv4s starting with "85."
• Diffs: User:154.115.222.191/sandbox created by a registered user to post a biography. User:154.115.231.75/Sample page, User:177.223.175.103, etc. are similar.

Air on White (talk) 00:14, 14 June 2024 (UTC)

Did you ask about this anywhere else? This suggestion seems very familiar. – 2804:F14:8086:B701:80CC:FCD6:43E3:855B (talk) 03:01, 14 June 2024 (UTC)

I asked in WP:VPT, but the discussion never picked up. Air on White (talk) 03:03, 14 June 2024 (UTC)

I was remembering this Teahouse question, actually. Anyways, I have no other comment, but the edit notice may be relevant for your suggestion. – 2804:F1...E3:855B (talk) 03:11, 14 June 2024 (UTC)

I misremembered then. There were three types of arguments against such a filter: The first fundamentally misunderstands either the problem or the proposal. The second straw mans or slippery slopes my argument as a ban on IP editing. The third is a fallacious sentiment that too much effort would be needed for this. It would only save editor time if I didn't have to deal with these bullshit userpages in the first place - how hard is it to just add the filter and the necessary warning to not create sandboxes for random IPs that aren't your own? Air on White (talk) 03:15, 14 June 2024 (UTC)

Mind you, IPs already can't create pages except in various talk namespaces, so IP's can't create their own user pages, would make a filter even simpler.

Also I wasn't making any sort of point, I just remembered it - do read the edit notice before discussing the LTA part of this suggestion in any detail though (if it's even significant enough to be relevant).

– 2804:F14:8086:B701:80CC:FCD6:43E3:855B (talk) 03:57, 14 June 2024 (UTC)

Edit filter 803

Hi. Could the line !('/' in page_title) & be removed from 803 (hist · log)? I can't think of a scenario where a new user would need to edit someone else's subpage, and I've seen users vandalizing guestbooks and other subpages before. Thanks. '''[[User:CanonNi]]''' (talk • contribs) 10:32, 13 June 2024 (UTC)

If you only remove that line then new users editing their own subpage will be hit. Nobody (talk) 11:03, 13 June 2024 (UTC)

Adding page_first_contributor != user_name could work for already created subpages. Nobody (talk) 11:23, 13 June 2024 (UTC)

Yeah I think that will work too. (sorry I'm not that familiar with edit filters) '''[[User:CanonNi]]''' (talk • contribs) 11:29, 13 June 2024 (UTC)

I don't have a solution for hitting subpage creations on other users yet. Can non-confirmed editors even do that? Nobody (talk) 11:31, 13 June 2024 (UTC)

I don't think so... I tried creating a subpage of my userpage logged out and it won't let me. '''[[User:CanonNi]]''' (talk • contribs) 11:34, 13 June 2024 (UTC)

Then this change could be worthwile. Nobody (talk) 11:41, 13 June 2024 (UTC)

Unregistered users can't create any pages in userspace, including their "own". Registered but not confirmed editors can create pages anywhere in userspace. Suffusion of Yellow (talk) 21:00, 13 June 2024 (UTC)

@Suffusion of Yellow Do you think it would need a RfC if we wanted to block non-confirmed users from creating subpages for other users? Nobody (talk) 05:10, 14 June 2024 (UTC)

I'm asking since the edits tagged by 733 (log) don't look that good. Nobody (talk) 05:15, 14 June 2024 (UTC)

It would still need some sort of wider discussion, though maybe not a giant RFC. I'm not convinced this is a good idea. This edit seems to be from a student editor who is (according to their userpage) participating in some sort of translation project. Again, if users want to collaborate on a draft, does it really matter where they put it? Suffusion of Yellow (talk) 22:14, 14 June 2024 (UTC)

I've been keeping an eye on Filter 733 and I don't think that the one translating clatt that User:OberMegaTrans is running is a good enough reason for not changing it to disallow. But I agree that the change to 803 would need a bigger discussion. Nobody (talk) 05:13, 17 June 2024 (UTC)

This is simple enough technically, but 803 was only enabled after an RFC which specifically excluded supages. An obvious use-case is collaborating on a draft. If you want to start a second RFC, let me know, and I'll create a log-only filter tracking subpage edits so people don't have to speculate. Suffusion of Yellow (talk) 20:56, 13 June 2024 (UTC)

Modify filter 1076

I propose that 1076 (hist · log), with a filter's description of "Draftified article more than 180 days old", be modified from a threshold of 180 days to 90 days. The notes in the filter say the following:

• 2020/09/20 - changed from 90 to 120 days - NPP often takes longer than 90 days (bv)
• 2021/12/10 - change to 180 days (bv)

Since these changes where the filter moved from 90 to 180 days, there has been a RfC on the matter of draftifications and how long after creation is appropriate. It was closed March 24, 2022, and the result was that pages over 90 days should not generally be draftified. As such, it makes sense for the filter to reflect this. Hey man im josh (talk) 13:49, 19 June 2024 (UTC)

I second this as well. Codename Noreste 🤔 Talk 22:10, 20 June 2024 (UTC)

User:Drmies wants a filter

• Task: Drmies left a note at WP:AN linking to Special:Contributions/Learoy4, all of whose edits had the same summary, all of which have been revdelled as Grossly insulting, degrading, or offensive material. Example, if you're an admin and able to see the revdelled content
• Reason: Based on the AN request, I suspect that this summary is being used by other accounts or IPs. Drmies blocked Learoy4 for vandalism, so we won't see further problems from this account.
• Diffs: Every edit by Learoy4 has the same summary, so preventing further edits by other accounts or IPs should be trivial. If the wording is changed a little, well, you're the filter maintainers and I'm not; maybe you could find a way to make things better.

Nyttend (talk) 12:54, 24 June 2024 (UTC)

@Nyttend, @Drmies: see the comments for Special:AbuseFilter/1314. —Ingenuity (t • c) 14:57, 24 June 2024 (UTC)

Nyttend, you can check Smalljim's log--I blocked a few but they blocked more. Thanks. Drmies (talk) 15:00, 24 June 2024 (UTC)

Yup. Dozens of them. It's some known LTA case, but I don't care which. I'll keep playing whack-a-vandal while I can. Keep an eye on 1314.  —Smalljim  16:19, 24 June 2024 (UTC)

Maybe, just maybe, there's a tiny chance if we can set to disallow or add the summary regex to 52 and disable 1314, but further discussions should not happen here. Codename Noreste 🤔 Talk 04:01, 25 June 2024 (UTC)

Just curious, is there any page where discussion can happen securely (something requiring admin or filter-editor rights just to view) without relying on the email address provided in the edit notice? I've looked at filter 1314's notes, and I can see people saying "To explain why..." and "Is this so-and-so" (as Ingenuity recommends), but nowhere that's being used for discussion. Nyttend (talk) 10:03, 25 June 2024 (UTC)

Nope. I've proposed a private wiki for facilitating this kind of discussion before but it did not get much traction. The current canonical venue is always the mailing list. 0xDeadbeef→∞ (talk to me) 10:53, 25 June 2024 (UTC)

COI filter

• Task: Prevent edits common COI edit summaries
• Reason: Reduce the workload of patrollers, help out new users who may be unfamiliar with Wikipedia's policies.
• Diffs: Don't have any on hand right now, but generally use phrases like "I am/We are ______ and am/are updating the article...", etc.

Rusty ^{talk contribs} 23:21, 30 June 2024 (UTC)

That wouldn't be in keeping with policy. COI edits are discouraged, but not outright forbidden. We certainly should not be preventing COI editors from removing obvious BLP violations, vandalism, etc. Spicy (talk) 13:31, 1 July 2024 (UTC)

Would you also object to a warn-only filter? This would certainly be in line with "discouraged, but not outright forbidden". Animal lover |666| 12:33, 7 July 2024 (UTC)

{{EFR}} Not a bad idea, but this would at most end in a tagging filter, and that would just increase and overlap patroller workload, which is a bit redundant to the point of your request. EggRoll97 ^(talk) 18:50, 27 July 2024 (UTC)

{{AfC submission}}

• Task: Prevent the removal of past AfC decline and rejections.
• Reason: They're not supposed to be removed by non-reviewers. (There's a invisible comment that says <!-- Important, do not remove this line before article has been created. --> beside the templates)
• Diffs: A lot.

I've tested possible code for this filter on Test Wiki (see here), and it seems to work well. '''[[User:CanonNi]]''' (talk • contribs) 13:12, 25 June 2024 (UTC)

Looks good, except you forgot exempting new page reviewers in the test wiki code, so maybe make it something like !contains_any(user_groups, 'extendedconfirmed', 'sysop', 'bot', 'patrol')? – PharyngealImplosive7 (talk) 01:36, 26 June 2024 (UTC)

Ultimately it doesn't particularly have much effect, since I can't really think of any patroller who isn't extendedconfirmed already. The only ones who would be are bots, who already operate with a bot flag. EggRoll97 ^(talk) 03:02, 26 June 2024 (UTC)

True. I didn't think of that, but one might keep it there just to be safe? – PharyngealImplosive7 (talk) 01:52, 27 June 2024 (UTC)

This probably needs wider discussion. I'd support it, but I suspect the anti-draftspace people would object. At a minimum, should probably make a post at WT:AFC. –Novem Linguae (talk) 02:01, 26 June 2024 (UTC)

Good idea. I've posted a {{please see}} there. '''[[User:CanonNi]]''' (talk • contribs) 03:43, 26 June 2024 (UTC)

meh. There are two situations where the AFC submission tags are being removed. In the first case, the draft-writer is attempting to hide past declines and/or unaware that they shouldn't replace declines with a new submit tag. In the second case, someone (and it could even be the draft creator) is moving the draft to the article space, which meets the before article has been created clause of the hidden comment. Can the filter tell the difference between these two cases? If not, then I do not think it will be a helpful filter (unless it is log-only). Primefac (talk) 13:19, 26 June 2024 (UTC)

I think it can. The !added_lines irlike '#redirect' line is used to not catch drafts that were turned into redirects (likely from a page move). '''[[User:CanonNi]]''' (talk • contribs) 13:26, 26 June 2024 (UTC)

I suppose my concern is if someone wants to clean up the draft before they move it to the article space, it will flag it as a violation, no? Primefac (talk) 14:57, 26 June 2024 (UTC)

Hmm... that's a good point. Maybe the template can say something like "Only remove this template if the draft has been moved into mainspace."? '''[[User:CanonNi]]''' (talk • contribs) 02:14, 27 June 2024 (UTC)

Setting the filter to warn rather than disallow as you propose sounds like a good compromise. –Novem Linguae (talk) 03:14, 27 June 2024 (UTC)

I can see that a draft is OVERWRITTEN by a different draft. That could cause an issue here. There is no collision detection at Article Wizard, so if you select an existing draft article name, and create a new draft, that will delete any rejection notices with a fresh draft. I've seen different users create new drafts overwriting one another. -- 64.229.90.32 (talk) 07:08, 1 July 2024 (UTC)

I expect that trapping conversion to redirect would help with if someone merges a nonnotable-rejection into a broader topic draft that could be notable. the Merge-and-Redirect activity would capture the edit history as a redirect's contribution history. ? -- 64.229.90.32 (talk) 07:08, 1 July 2024 (UTC)

Support Apart from the correct housekeeping removal on acceptance, ideally but not always done by the AFCH script, I see only two reasons an editor, not necessarily the creating editor, will remove the material:

1. With goodwill, thinking this is correct despite the hidden comment
2. To conceal prior review history.

I see this proposal as a benefit provided the exception cases are sorted out. I have no objection to offering a warning, though would prefer outright prohibition. 🇺🇦 Fiddle^Timtrent Faddle^Talk to me 🇺🇦 07:58, 1 July 2024 (UTC)

Prevent publication of red-linked example at a Help page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• Task: This filter should prevent publication of any page at Underwater astronomy, which is intentionally red-linked from Help:Your first article#How to create a new page (just added) as an example to new editors creating their first article. This applies to all editors, at Help:Your first article. Theoretically only on that one page, although hopefully no one will try to create it from somewhere else. I suppose admins should be allowed to publish there, although I don't think their article would survive Afd .
• Reason: Help:Your first article is a page which attracts brand new editors that habitually try things out—as well they should—but also including stuff they shouldn't, which is why the page itself is indefinitely semi-protected: the page was routinely altered/corrupted with test edits by brand new users viewing it and trying it out as their sandbox. It would be annoying to have this sample red link turn blue and constantly have to deal with it. But the new editors are encouraged to click the link, to see what a preview window looks like, and even to type stuff into it; they just should not be allowed to publish it.
• Diffs: No diffs yet, this red link was added moments ago. However, because of a glitch during an operation today, the page was briefly unprotected for a few minutes, and right on cue, almost instantly had its TemplateStyles link corrupted by a test edit (diff; quickly removed and reprotected). It's only a matter of time before someone tries to publish something at that red link as Their First Article. Let's not let that happen, and then have to chase it down afterward. Thanks, Mathglot (talk) 02:38, 3 August 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

{{EFR}} Due to request being withdrawn. EggRoll97 ^(talk) 08:17, 4 August 2024 (UTC)

Removal of {{BLP-PROD}} filter

• Task: This filter would tag a diff if it removes the {{BLP-PROD}} tag without adding any new references, possibly distinguished if the edit does not add a <ref> </ref> tag.
• Reason: This filter would be useful in RCP and in the page history in general for abuse management, so editors can identify when the {{BLP-PROD}} tag is removed without adding references.
• Diffs: Many, most diffs of this kind are deleted along with the page, but I believe it is pretty self-explanitory

Lordseriouspig 11:31, 25 July 2024 (UTC)

Convenience link: WP:BLPPROD. –Novem Linguae (talk) 20:56, 25 July 2024 (UTC)

Requires more information The use-case seems fine, as far as I can tell, but I'll need some diffs for these or at least pages to go off of. I looked through your prod log but all the removals of those tags that I can see are valid and have references in the article. Also likely would result in a lot of false positives if one was to remove the tag before adding the references, or to add the references and then remove the tag in another edit. EggRoll97 ^(talk) 06:24, 1 August 2024 (UTC)

{{EFR}} No diffs provided within a couple weeks. EggRoll97 ^(talk) 05:42, 20 August 2024 (UTC)

Flagging edits made purely to obfuscate the page preview

• Task: This filter would tag a diff it detects as purely intended to obfuscate the page preview (for example, a user adding a period . after an article's short description template), and send a warning after the behaviour is repeated.
• Reason: Diffs that add a period after the short description template entirely replace the contents of that article's page preview with the character, which makes the browsing experience more difficult for readers. I imagine that there are other methods of obfuscating the page preview, but this is the only one I know of.

This kind of vandalism is subtle, and difficult to catch at the moment. On one vandalism spree using this method, no existing edit filters flagged the IP's edits as suspicious until they began conducting mass-scale reverts.

• Diffs: Note that all of the pages targeted in this attack were on the main page at the time, and some of them weren't caught until over 40 minutes after the edit was made. See examples one, two, and three.

SupremeLordBagel (talk to me) 00:57, 10 August 2024 (UTC)

Honestly, it seems like you have only provided diffs of one user doing this. Do you have any other evidence of multiple users conducting this same type of edit, because if you don't, an edit filter would most likely be unnescesary. – PharyngealImplosive7 (talk) 01:39, 14 August 2024 (UTC)

{{EFR}} and Deferred to WP:AIV. EggRoll97 ^(talk) 19:03, 20 August 2024 (UTC)

POVPUSH removal of "Black"

Moved to Wikipedia:Administrators' noticeboard § POVPUSH removal of "Black"

• Task: Test for a no-insertion one-line removal of / ?[Bb]lack ?/. Tag or only log articlespace edits by non-autoconfirmed editors.
• Reason: Some instances of this subtle POVPUSH may remain undetected for a long time. An EF can produce a list to review.
• Diffs: [85] [86]

142.113.140.146 (talk) 01:24, 1 August 2024 (UTC)

Deferred to WP:RFPP, WP:AIV, and similar. The diffs provided are a singular IP, but that can be dealt with via blocks and protection. Generally the disruption should be somewhat widespread for a filter to have much effect here. EggRoll97 ^(talk) 06:04, 1 August 2024 (UTC)

Here are more UCR diffs, all by different IPs: [87] [88] [89] [90].

Those IPs did not edit more than 2 articles so WP:AIV would say "insufficiently warned". In the [91] that I caught, the page was over a year old so would not normally qualify for WP:RFPP, and it was undetected for half a month. Those edits were reverted by multiple editors with long edit histories. This hit-and-run disruption is attempting to hide the alteration of POV. A tagging EF will have the effect of revealing the full extent of the damage. 142.113.140.146 (talk) 06:33, 1 August 2024 (UTC)

{{EFR}} following move to AN. EggRoll97 ^(talk) 17:32, 25 August 2024 (UTC)

Projectspace Redirect Vandalism

• Task: Reduce Redirect vandalism in Project namespace
• Reason: After my discussion with Suffusion of Yellow and seeing this search I noticed a consistent amount of vandalism (average of around 2-2.5 edits per day for the last 2 months), some get picked up by Filter 1151 but most aren't.
• Diffs: See search above.
• Code:The code for this I've been working on is at: /Projectspace Redirect blanking

Nobody (talk) 15:14, 24 July 2024 (UTC)

Testing at 1318. EggRoll97 ^(talk) 19:00, 27 July 2024 (UTC)

@EggRoll97 Made an update to the code. Nobody (talk) 11:59, 28 July 2024 (UTC)

Implemented, still in testing. EggRoll97 ^(talk) 15:06, 28 July 2024 (UTC)

@EggRoll97 Refined it a bit more. Nobody (talk) 05:53, 30 July 2024 (UTC)

Done. EggRoll97 ^(talk) 15:05, 30 July 2024 (UTC)

Update: No false positives since the last change. Nobody (talk) 06:01, 5 August 2024 (UTC)

@EggRoll97 Eliminated another false positive. Please update the filter. Thanks Nobody (talk) 05:42, 8 August 2024 (UTC)

Added. EggRoll97 ^(talk) 15:21, 8 August 2024 (UTC)

@EggRoll97 Made another update based on filter hits. Nobody (talk) 05:32, 20 August 2024 (UTC)

Added, same as last time. This seems to be productive and doesn't produce too many false positives, so I have no objection to starting to tag this with possible vandalism in a day or so. EggRoll97 ^(talk) 05:36, 20 August 2024 (UTC)

Great, I'll still keep my eyes on the log to eliminate any false positives. Nobody (talk) 05:40, 20 August 2024 (UTC)

Filter moved up to tagging, 1AmNobody24. EggRoll97 ^(talk) 06:41, 24 August 2024 (UTC)

@EggRoll97 this can probably be marked as done, since the filter is working with no problems. Nobody (talk) 14:03, 2 September 2024 (UTC)

Per above, {{EFR}} EggRoll97 ^(talk) 18:43, 2 September 2024 (UTC)

Vandalism from changing IPs with a recognizable edit summary pattern

• Task: Can something be done about the vandalism from changing IPs like the examples below with a recognizable pattern especially with their edit summaries?
• Reason: Continued vandalism from changing IPs
• Diffs: Some examples:
• https://en.wikipedia.org/wiki/Special:Contributions/2001:16A4:251:1C67:4DB7:6E66:2C56:70ED
• https://en.wikipedia.org/wiki/Special:Contributions/46.184.122.159
• https://en.wikipedia.org/wiki/Special:Contributions/46.184.120.17
• https://en.wikipedia.org/wiki/Special:Contributions/46.184.122.114
• https://en.wikipedia.org/wiki/Special:Contributions/2A02:88D:8030:53B:7CF9:FC9:D756:FBCE
• https://en.wikipedia.org/wiki/Special:Contributions/2001:16A4:23E:6404:F52B:32AC:7B9C:ABF3
• https://en.wikipedia.org/wiki/Special:Contributions/2A02:88D:8030:53B:C03:E4D9:82F9:FE8F

Tehonk (talk) 05:07, 3 August 2024 (UTC)

Tehonk, I'm not a regular here, but I'm pretty sure you are on the wrong page. For starters, have a look at WP:Vandalism#How to respond to vandalism. The § For beginners section on that page has a useful checklist: Assess, Revert, Warn, Watch, Report. Bottom line, if it really is vandalism, revert it and warn them at their talk page, using escalating template warnings, starting with {{subst:uw-vandalism1}}, then -2, -3, -4 and if it's still happening after a 4-level warning, you can go to Wikipedia:Administrator intervention against vandalism to report it. By the way, you can search all of their contributions for all three with a CIDR-range search: Special:Contributions/46.184.120.17/22; that will pick up all three IPs (as well as some unrelated stragglers from 2 years ago). HTH, Mathglot (talk) 09:34, 4 August 2024 (UTC)

There's no use in sending warnings to expired/old IPs Tehonk (talk) 17:29, 4 August 2024 (UTC)

{{EFR}} and Deferred to AIV and similar. At this rate it'd probably be faster to just AO-block the /22. EggRoll97 ^(talk) 19:29, 1 September 2024 (UTC)

False / forged signature detection

• Task: Detect when users insert other user's signatures. This should not apply to undos or archiving.
• Reason: False signatures are typically added in bad faith, and can cause legitimate confusion. Either way, they are typically not helpful.
• Diffs: Diff of an impersonating sock inserting the signature of a user they impersonate.

GeorgeMemulous (talk) 14:47, 30 August 2024 (UTC)

{{EFR}} The example you cite with a diff was immediately re-signed by SineBot, and then undone by an admin. These don't seem to be necessarily too disruptive. EggRoll97 ^(talk) 19:27, 1 September 2024 (UTC)

Can this be filtered for somehow?

See Wikipedia:Administrators'_noticeboard#New_sneaky_reference_vandalism_-_needs_a_filter?_RC_patrollers,_please_take_note. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:48, 29 August 2024 (UTC)

Not sure how often this happens. But if needed something like this could work as a start.

user_age == 0 &
page_namespace == 0 &
edit_delta < 100 &
removed_lines irlike "ref name\s?=\x22:\d+" &
ip_in_ranges(user_name, "204.18.0.0/16")

Nobody (talk) 13:29, 29 August 2024 (UTC)

When linking to non-existing refs, it is more apparent sabotage but a root fix would be changing ref names to something more human friendly. And that would also avoid confusing diffs where adding an article changes the name of all numerically subsequent ones. ~ 🦝 Shushugah (he/him • talk) 14:20, 29 August 2024 (UTC)

I made some changes to the code above, since if implemented without said changes will be broken and potentially have false positives. I also changed rlike to irlike (case insensitive). Codename Noreste 🤔 Talk 04:41, 30 August 2024 (UTC)

How common are edits like this? Unless there's a consistent pattern, I don't think that creating a filter is worthwhile. —Ingenuity (t • c) 13:43, 30 August 2024 (UTC)

I don't think this is necessarily a common occurrence, I'd lean towards this probably being unsuited for a filter. EggRoll97 ^(talk) 19:31, 1 September 2024 (UTC)

Given no response, {{EFR}} due to lack of a common occurrence. EggRoll97 ^(talk) 22:02, 5 September 2024 (UTC)

Log edits to template-protected pages

• Task: Log edits to template-protected pages
• Reason: Template protection is generally for high-risk pages, so it would be helpful to log these changes to check when something breaks (or just to watch generally for interesting/bad changes to important templates). Compare Special:AbuseFilter/942 ("Log edits by administrators to fully protected pages"). It would also be helpful for administrators evaluating requests at Wikipedia:Requests for permissions/Template editor for extension of previous template editor permissions.
• Diffs: N/A
• Code:

"templateeditor" in page_restrictions_edit &
!("bot" in user_groups) &
action == "edit"

SilverLocust 💬 04:05, 4 September 2024 (UTC)

Maybe also add "templateeditor" in user_groups, but otherwise looks good. – PharyngealImplosive7 (talk) 14:44, 4 September 2024 (UTC)

Wouldn't that condition exclude administrators? Animal lover |666| 16:21, 4 September 2024 (UTC)

That's why I didn't include it. SilverLocust 💬 16:32, 4 September 2024 (UTC)

Yes that is true now that I think about it. – PharyngealImplosive7 (talk) 18:43, 4 September 2024 (UTC)

I don't really see the use case in practice tbh. I also don't see the point of 942 (hist · log).

The use case of seeing recent changes to TE protected templates is better served using Special:RecentChanges, along with a userscript that filters out pages by protection level. For extending TE... eh, one can just as easily view a user's contributions in the template namespace, it's usually not going to be that big of a list. ProcrastinatingReader (talk) 19:02, 5 September 2024 (UTC)

@Xaosflux: do you know why we have filter 942? ProcrastinatingReader (talk) 19:03, 5 September 2024 (UTC)

Mostly to have a source of data for these 'admin actions' that don't appear specifically in other logs. — xaosflux ^Talk 19:07, 5 September 2024 (UTC)

When filtering recent changes to edits by extended-confirmed humans to templates, it only goes back about 16 hours before hitting the maximum of 1000 recent changes. I would like to be able to look more than a day back. Pages may also later have their protection level changed. This should be a cheap filter, and I believe it would often be useful to have a log of templateeditor actions. SilverLocust 💬 20:48, 5 September 2024 (UTC)

I see the point here, but I'm not sure I see the use-case. 942 seems like more of an admin activity tracking filter, which isn't really needed for template editors. Requests to extend template editor permissions already have a template space contribs link, so I'm doubtful as to how helpful this filter would really be. EggRoll97 ^(talk) 22:01, 5 September 2024 (UTC)

All right. Consider this  Request withdrawn. SilverLocust 💬 00:08, 6 September 2024 (UTC)

{{EFR}} For the bot. EggRoll97 ^(talk) 23:24, 6 September 2024 (UTC)

Warn about a Wikipedia mirror

Ed-Tech Press, also known as "Scientific E-Resources, is a Wikipedia mirror. They print copies of books that are just Wikipedia articles. Per WP:CIRCULAR, we should never cite them in articles. Unfortunately, these books are listed in Google Books, and there's no obvious warning on them. I've inadvertently cited them twice recently. While I really appreciate reversions like this one, it seems like this is an area where an ounce of prevention is worth a pound of cure. Could we please have an abuse filter set up for this string:

|publisher=Scientific e-Resources

which should catch most {{cite book}} uses? If it would be great if it could produce a warning message like "Ed-Tech Press and Scientific E-Resources are Wikipedia mirrors. They are not reliable sources and should not be cited in articles per WP:CIRCULAR." I think that the 'warn' setting should be sufficient. WhatamIdoing (talk) 01:42, 7 July 2024 (UTC)

Thank you making this request - this publisher is just the worst. There is deliberately no attempt to identify the nature of the copied materials; it's just a straight up scam. There are three things I usually search for: "Ed-Tech Press", "Scientific e-Resources" (which is typically displayed when a google books link is resolved in a template), and the URL of "edtechpress.co.uk". I do agree with the warning being sufficient as I don't recall this ever being used on-wiki by a bad-faith actor. Sam Kuru (talk) 02:35, 7 July 2024 (UTC)

Yeah. Possible filter code for catching this could be:

page_namespace == 0 &
!contains_any(user_groups, "bot", "sysop", "extendedconfirmed") & (
   mirrors := "(?:\|publisher\s*\=\s*(?:(?:[Ss]cientific [Ee]\s?-\s?[Rr]esources)|(?:Ed\s?-\s?[Tt]ech [Pp]ress)))|(?:\|url\s*\=\s*edtechpress\.co\.uk)";
   added_lines irlike mirrors &
   !(removed_lines irlike mirrors)
)

I would create a log-only filter at first, and if it does well, ramp it up to warn. – PharyngealImplosive7 (talk) 22:05, 13 July 2024 (UTC)

Thanks for this. I understand that starting as a long-only filter is common, and I've no objection. WhatamIdoing (talk) 00:20, 14 July 2024 (UTC)

@WhatamIdoing, Kuru, and PharyngealImplosive7: If there is consensus for deprecation, it could just be added to 869 (hist · log), which might be better than a new filter just for this. Most likely Deferred to WP:RSN. EggRoll97 ^(talk) 18:48, 27 July 2024 (UTC)

@EggRoll97, I don't think that it should be handled through the RSP system. It's not a case of "deprecated at RSN"; instead, it's a case of "banned by policy" (Wikipedia:Verifiability#Wikipedia and sources that mirror or use it being the most relevant policy). The deprecation message wouldn't be appropriate. Instead, I think it needs a message that is specific to Wikipedia:Mirrors and forks. WhatamIdoing (talk) 21:44, 27 July 2024 (UTC)

Requires more information Do you have any diffs to go off of by chance for this? It would be helpful to see this being added in a diff to be able to test a possible filter on one. EggRoll97 ^(talk) 06:26, 1 August 2024 (UTC)

Sure. Look at this one. WhatamIdoing (talk) 17:25, 1 August 2024 (UTC)

Still doing... I've been trying to build this filter, but I'm running into syntax errors. Still working on it, but this one seems to be taking time. EggRoll97 ^(talk) 13:40, 12 August 2024 (UTC)

Thanks for working on it. WhatamIdoing (talk) 19:37, 12 August 2024 (UTC)

I'm getting syntax errors, but I'm not sure what exactly is going wrong. This may be past my expertise, I'm not sure why it's throwing Expected a ) at character 53, not found (found T_STRING bot instead). From all I can tell, the code above seems fine, but batch testing doesn't like it, and I've got no idea currently on how to fix it. I've tried adding more parentheses, but everything seems to be closed up, so it shouldn't be throwing the error as far as I'm aware. EggRoll97 ^(talk) 05:40, 20 August 2024 (UTC)

Would finding another pair of eyes be helpful? We could ask at VPT. WhatamIdoing (talk) 05:50, 20 August 2024 (UTC)

There is supposed to be a comma after user_groups(example). Sorry I didn't notice this before. – 2804:F1...A7:C558 (talk) 15:29, 20 August 2024 (UTC)

I've added the comma. – 2804:F1...A7:C558 (talk) 15:34, 20 August 2024 (UTC)

I actually happened to try that when trying to build the filter in /test, adding the comma removes that error there, but adds a new syntax error on line 4, Syntax error detected: Expected a ) at character 256, not found (found T_ID added_lines instead). EggRoll97 ^(talk) 19:02, 20 August 2024 (UTC)

Maybe additionally the mirrors := declaration? Supposedly needs a semicolon at the end: User-defined variables.

I've added that in too. – 2804:F1...A7:C558 (talk) 19:56, 20 August 2024 (UTC)

Testing at 1323. Apologies for this taking so long, I've been a bit busy with other matters. EggRoll97 ^(talk) 06:24, 24 August 2024 (UTC)

\o/

Congratulations. I hope that the testing proves conclusive. WhatamIdoing (talk) 20:09, 24 August 2024 (UTC)

Just noting here that there have been no hits so far. We might want to wait for another 2 weeks and if there are still no hits then, consider deleting the filter. – PharyngealImplosive7 (talk) 22:38, 7 September 2024 (UTC)

Alternatively we could add lulu books and several others. All the best: Rich Farmbrough 21:40, 12 September 2024 (UTC).

No objections to the above, might as well make this broader if possible. EggRoll97 ^(talk) 22:42, 20 September 2024 (UTC)

Another week and no hits. Might be worthwhile to disable this at this point. Any opinions either way? EggRoll97 ^(talk) 18:54, 28 September 2024 (UTC)

Yeah I think it's best to disable now. It's been over a month and we've gotten no hits. – PharyngealImplosive7 (talk) 13:38, 3 October 2024 (UTC)

{{EFR}} EggRoll97 ^(talk) 03:59, 5 October 2024 (UTC)

Duplicate Disambiguation Entries

• Task: Disallow edits to disambiguation pages that add an entry already on the page.
• Reason: This filter would be useful on long disambiguation pages such as King (disambiguation), where adding a duplicate entry is easy.
• Diffs: Special:Diff/1243174404

Faster than Thunder (talk | contributions) 22:57, 12 September 2024 (UTC)

Does this happen often? If it happens once every few months occassionally, it seems like a filter isn't worth it. Do you have edits recently done by multiple editors that are duplicate disambiguation entries? – PharyngealImplosive7 (talk) 01:13, 13 September 2024 (UTC)

I am wondering if there is not a way to provide a pre=save notice to the editor, rather than blocking the edit altogether. BD2412 T 03:12, 13 September 2024 (UTC)

That sounds like a warning filter with a custom warning message. Nobody (talk) 08:59, 13 September 2024 (UTC)

{{EFR}} Without examples past just the one, this doesn't seem like a frequent enough occurrence to warrant a filter. EggRoll97 ^(talk) 16:04, 9 October 2024 (UTC)

School articles

• Task: Prevent vandalism to school articles
• Reason: There's some sort of social media competition going on to insert the name of a rapper as head teacher of the editor's school. These are not setting off any other filters and are being missed.
• Diffs: [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109]
• Match: new editor or IP and inserting Sean Combs or Sean "Diddy" Combs or Diddy or Diddler or Sean John or Puff Daddy or P Diddy (and variations). Refinement: perhaps trigger only if the article has school or academy or similar words in the article title. 81.2.123.64 (talk) 11:36, 30 September 2024 (UTC)

Seeing this a lot right now. Would be best to filter by Category:High schools as well. Catalyzzt (talk) 14:34, 30 September 2024 (UTC)

Maybe not directly related to the tiktok trend, but since I started working on reverting Diddy vandalism, I've also noticed youtubers often being similarly inserted into articles, most notably Markiplier as seen with these diffs [110][111][112][113][114][115] LaffyTaffer (talk) 20:30, 30 September 2024 (UTC)

I think we could just add some regex to filter 614 (hist · log), which covers these meme trends. Some regex we could add could be (?:sean\s(?:\"?diddy\"?\s)?(?:(?:combs)|(?:john)))|(?:p?\s?didd(?:(?:y)|(?:ler)))|(?:puff\sdaddy)|(?:p\sdiddy) to the already existed filter. – PharyngealImplosive7 (talk) 23:35, 30 September 2024 (UTC)

Comment Disruption is still ongoing and indeed a disruption-only account for this specific type of disruption has popped up: see Special:diff/1248790500 — Preceding unsigned comment added by GeorgeMemulous (talk • contribs) 14:09, 1 October 2024 (UTC)

Still ongoing. It's relentless. — ClaudineChionh (she/her · talk · contribs · email) 22:53, 2 October 2024 (UTC)

• Related: We have an existing filter — changing height and/or weight — that could be adapted here. I’m assuming it works by spotting changes in infoboxes. If so, the same filter could be used to flag changes to principal= and superintendent= in the schools infobox. 81.2.123.64 (talk) 00:05, 3 October 2024 (UTC)
• {{EFR}} Added PharyngealImplosive7's code in, should do the trick based on testing prior to implementation. EggRoll97 ^(talk) 16:00, 9 October 2024 (UTC)

  FYI, Ohnoitsjamie added free diddy using \s* around letters on this change to 614. Codename Noreste 🤔 Talk 18:37, 9 October 2024 (UTC)

Disallow extremely large edits

• Task: Disallow editors from making extremely large disruptive edits to pages. This should not apply to undoing previous vandalism, nor should it apply to existing redirects or new pages; this only should apply to the addition of large amounts of text to a page.
• Reason: There's almost no purpose for edits over a specific size threshold to be sent to mainspace; I would guess they'd be only disruptive. Any individual edit larger than the largest article (currently Opinion polling for the 2024 United Kingdom general election, 885,708 bytes), or perhaps a lower threshold of around 500,000 bytes should be disallowed and not allowed to exist as a diff (Wikipedia is not a file host and these edits would take up a significant and unnecessary amount of space). These edits, while typically quickly reverted, really shouldn't happen in the first place.

Diffs: Special:Diff/1248611730 - A WP:GAMEing editor adding 1.6 million bytes of disruptive content to a WP:BLUELOCK page. GeorgeMemulous (talk) 16:12, 30 September 2024 (UTC)

I mean that's clearly an LTA, so it would probably be better to discuss this in the recommended places (mentioned in the red banner that shows up in the edit notice of this page).

On the other hand, is any amount of filtering going to stop them from being disruptive with less bytes? If the edits are quickly reverted that seems good enough?

Mind you, ignoring the LTA part, we do have a filter that prevents 1 million+ bytes changes, though expanding it to cover extended-confirmed users might warrant discussion. – 2804:F1...11:99EF (talk) 20:47, 30 September 2024 (UTC)

I wasn't interested in this as an LTA case. ECP users shouldn't be able to make million-byte edits either, I would think? Either way, anyone else who games the system or uses a compromised account can produce this form of disruption. I'd personally set the limit at 500,000 as well, but 1,000,000 is a number we can all agree on. GeorgeMemulous (talk) 21:24, 30 September 2024 (UTC)

The existing filter is 812 (hist · log) ("Unreasonably large addition of content"). Honestly it should at least be changed to apply to autoconfirmed users.

This board can be a bit slow and, if my reading of past edits in this board is accurate, it's better if there's nothing left to discuss (like reaching a consensus elsewhere on what amount of bytes should be unacceptable and if extended confirmed users should or shouldn't be permitted to make such edits). – 2804:F1...11:99EF (talk) 22:05, 30 September 2024 (UTC)

This does make sense. @EggRoll97 could you change line 1 to !contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &? Nobody (talk) 07:54, 7 October 2024 (UTC)

{{EFR}} Sorry this took a bit. Change made. EggRoll97 ^(talk) 15:43, 9 October 2024 (UTC)

New users adding sock / block templates to other user's pages

• Task: Disallow new users / IPs from adding block templates including sock blocking templates to users that aren't blocked
• Reason: In general there's almost no reason for any but the most seasoned IPs or new accounts to add block templates that are typically automatically added by the blocking admin. Either a total block of new users adding block templates, or only for non-blocked accounts.
• Diffs: Special:Diff/1184722881 (likely) single-time vandal doing this type of disruption happening on an administrator's page. This user may have been auto-confirmed, so this may need to apply to all non-ECP+ users.

GeorgeMemulous (talk) 23:57, 7 September 2024 (UTC)

I'm making some regex right now, but what I'm concerned about is that this edit is from over a year ago. Do you have any other more recent examples? Because otherwise, it wouldn't be necessary to create a whole new filter. – PharyngealImplosive7 (talk) 02:11, 8 September 2024 (UTC)

Don't we already have 1157 (hist · log) that does this purpose? Codename Noreste 🤔 Talk 03:00, 8 September 2024 (UTC)

Clearly that didn't stop this particular instance of disruption. Although, I can't think of many times this was added recently. I do know of an LTA that's recently been adding unblock requests to their own pages as an already unblocked account, so maybe that could be added? Either way, disruption is disruption, but if it isn't that common I suppose a filter is unnecessary. GeorgeMemulous (talk) 18:35, 8 September 2024 (UTC)

Just stumbled upon an example from just now of a disruptive editor adding a block template to an unblocked IP's page. See here. Not disallowed by any existing filter. GeorgeMemulous (talk) 23:56, 9 September 2024 (UTC)

803 (hist · log) could probably also be adjusted for sleeper accounts like this one. Nobody (talk) 05:44, 9 September 2024 (UTC)

Filter 1276 update request

• Task: Update regex from /hamas/ to /\bhamas/.
• Reason: To reduce false positives with new articles, such as with islands of The Bahamas
• Diffs: Special:AbuseLog/38951783, Special:AbuseLog/38951588, Special:AbuseLog/38951525

--Leonidlednev (T, C, L) 16:40, 11 October 2024 (UTC)

Looks good to me. Done -- thanks! ProcrastinatingReader (talk) 22:46, 11 October 2024 (UTC)

{{EFR}} For the bot. EggRoll97 ^(talk) 04:05, 12 October 2024 (UTC)

Warn and tag creations that may violate NOTCHANGELOG

• Task: This filter warns and then tags page creations that may violate WP:NOTCHANGELOG.
• Reason: I just nominated a draft Draft:Google Chrome version history for deletion because it appears to be WP:NOTCHANGELOG. There usually aren't good reasons to create these "version history" pages in most cases.
• Diffs: Not going to include many, but there has been this same shenanigans at Windows 10 version history and Windows 11 version history.

Here is some of the filter code which can be further refined:

page_title rlike ".*version history" & page_last_edit_age == null

Message:

Awesome Aasim 19:35, 1 October 2024 (UTC)

(Non-EFH comment) These type of issues often also occurs when new editors publishes a draft about a software, they just make a bulleted list of updates and changes... My only concern is that these shenanigans aren't really that common. ABG (Talk/Report any mistakes here) 23:51, 3 October 2024 (UTC)

If only there was some intelligent way to detect this... ahhh.... We probably need some sort of AI-powered abuse filter to help detect and warn about these common mistakes. Awesome Aasim 16:48, 4 October 2024 (UTC)

We probably would get false positives no matter how we do this, so tagging might be too much. Nobody (talk) 07:43, 7 October 2024 (UTC)

Recent changes has 12 tags starting with 'possible' and one starting with the word 'possibly', false positives are expected in all of those. – 2804:F1...32:A716 (talk) 07:59, 7 October 2024 (UTC)

Deferred This seems like an easier job for a title-blacklist if it's that much of a problem. I'm not sure a filter is right way to go here. EggRoll97 ^(talk) 16:02, 9 October 2024 (UTC)

{{EFR}} For the bot. EggRoll97 ^(talk) 19:23, 15 October 2024 (UTC)

New tag for WP:AFCH

Apologies if this is a dumb question, or the wrong place, I'm going around in circles trying to figure this out (though I'll admit, I'm somewhat rushing through things because I'm trying to do it in between everything else going on in my life today). We're trying to get Special:Tags set up for the AFC Helper script so that queries like this about users misusing the AFCH edit summaries will be easier to spot. I know how to create a tag but I can't figure out how to make it trigger. Thanks in advance for the help. (please do not ping on reply) Primefac (talk) 11:59, 14 October 2024 (UTC)

The ways to normally make a tag trigger would be: Through an extension, edit filter, external tool or some other softwade defined way. Since it's neither an external tool nor a extension, those are out. Edit filter would be easier if AfC reviewer was a user group. And software defined I don't know how easy it would be, since I've never looked at it. Nobody (talk) 13:15, 14 October 2024 (UTC)

This doesn't require an edit filter. Once the tag is created, AFCH's code can be updated to apply the tag in the API requests used for performing edits. – SD0001 (talk) 14:52, 14 October 2024 (UTC)

Ah, okay, thanks. This is being tracked in the AFCH git so I guess we'll go that route. Primefac (talk) 15:15, 14 October 2024 (UTC)

{{EFR}} Per above. EggRoll97 ^(talk) 19:21, 15 October 2024 (UTC)

Create filters to block the insertion of Battle for Dream Island-related content outside of talk pages

I noticed that Wikipedia is strengthening its efforts against BFDI-related pages by salting and blacklisting them, but the only method of combating BFDI content in legitimate pages is by protecting them and adding wikicomments warning editors not to add any BFDI content; Ctrl+Fing "bfdi" or "battle for dream island" in Special:AbuseFilter shows no hits. For this reason I am suggesting abuse filters to block the insertion of BFDI content in legitimate pages, except for in talk pages. 67.209.129.62 (talk) 02:31, 15 October 2024 (UTC)

I'm not sure I can agree with this. For situations like this, blacklisting has always been the go-to method. Nobody (talk) 05:12, 15 October 2024 (UTC)

{{EFR}} and Deferred to MediaWiki:Titleblacklist. EggRoll97 ^(talk) 19:22, 15 October 2024 (UTC)

Preventing IPs from changing Aurangabad to Chhatrapati Sambhaji Nagar

• Task: This filter prevents IPs from changing Aurangabad to Chhatrapati Sambhaji Nagar on related articles
• Reason: Consensus on the talk page of Aurangabad have concluded to use the Common Name over the Official Name. However, several IPs, often POV driven, have been changing this to the recent official name. This is also true for any related articles containing the name of the city. An edit filter would prevent this while still allowing constructive IPs to contribute.
• Diffs: The edit histories of Aurangabad District, Aurangabad (now protected for that reason), Ajanta Caves, Ellora Caves, Bibi Ka Maqbara and other related pages show this to be a persistent issue.

SKAG123 (talk) 21:35, 18 October 2024 (UTC)

{{EFR}} This is very much a content dispute. Multiple reversions have pointed to the common name policy, but almost no talk page messages have been left for the IPs, nor is any reasoning spelled out in the edit summaries. I don't see any significant consensus either on the talk page you mentioned. It is unreasonable to assume that IPs are aware of CTOPS policies, and the only actual notice that appears to exist not to change the name is located on a singular edit notice on one of the linked pages. EggRoll97 ^(talk) 00:16, 24 October 2024 (UTC)

Warn on inline image usage

Moved to Wikipedia:Village pump (proposals) § Warn on inline image usage

 – Aaron Liu (talk) 11:27, 25 October 2024 (UTC)

Filter 1030

• Task: Removing ANTI-VANDALISM edits from the filter log of filter 1030 (hist · log).
• Reason: Would reduce the filter hits by around 2%.
• Code: Adding !(summary irlike "^(?:undid|rv[vt]?|revert|restored)")

Nobody (talk) 09:37, 25 October 2024 (UTC)

{{EFR}} EggRoll97 ^(talk) 02:03, 26 October 2024 (UTC)