Wikipedia:Edit filter/Requested

Requested edit filters
This page can be used to request edit filters, or changes to existing filters. Edit filters are primarily used to address common patterns of harmful editing. Private filters should not be discussed in detail. If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details to wikipedia-en-editfilterslists.wikimedia.org. Otherwise, please add a new section at the bottom using the following format: == Brief description of filter == *'''Task''': What is the filter supposed to do? To what pages and editors does it apply? *'''Reason''': Why is the filter needed? *'''Diffs''': Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list. ~~~~ Please note the following: Edit filters are used primarily to prevent abuse. Contributors are not expected to have read all 200+ policies, guidelines and style pages before editing. Trivial formatting mistakes and edits that at first glance look fine but go against some obscure style guideline or arbitration ruling are not suitable candidates for an edit filter. Filters are applied to all edits. Problematic changes that apply to a single page are likely not suitable for an edit filter. Page protection may be more appropriate in such cases. Non-essential tasks or those that require access to complex criteria, especially information that the filter does not have access to, may be more appropriate for a bot task or external software. To prevent the creation of pages with certain names, the title blacklist is usually a better way to handle the problem - see MediaWiki talk:Titleblacklist for details. To prevent the addition of problematic external links, please make your request at the spam blacklist. To prevent the registration of accounts with certain names, please make your request at the global title blacklist. To prevent the registration of accounts with certain email addresses, please make your request at the email blacklist.
Click here to create a new request

Filter unsourced tornado / hurricane rating changes

• Task: Prevent or tag new editors that change tornado / hurricane intensity ratings without a source.
• Reason: This is a pretty common and obvious form of disruption, but it's hard to easily find using the edit history (most occur as a 0 byte change with no summary, similar to a standard typo fix) and an unsourced change is hardly ever helpful.
• Diffs:
  • 2024 Greenfield tornado: IP editor changing EF4 to EF5 without a source. This diff is my reversion of those edits.
  • 2024 Greenfield tornado: NOTHERE editor doing the same.
  • 2024 Greenfield tornado: New editor doing the same.
  • Tornado outbreak sequence of April 25 - 28, 2024: IP undoing previous vandalistic edits. Note that the bad edits had no summary.
  • Tornado outbreak sequence of May 19 - 27, 2024: 1, 2, 3, and 4 edits by an LTA of this type of disruption. I know this LTA isn't the primary one doing this.

Also, I know this can happen with hurricanes; see the edits on Hurricane Beryl from early on July 2 and you'll see why it needed protection. GeorgeMemulous (talk) 13:37, 23 October 2024 (UTC)

(denied removed) and Deferred to requests for page protection. The first diff you present seems like it was made in good faith (?) based on the edit summary alone, though I'm not too familiar with tornados. This seems to be something that pending changes would help with more than a filter, though. EggRoll97 ^(talk) 23:46, 23 October 2024 (UTC)

Disruption has been ongoing since 2023 and isn't limited to those four pages, even if they are the most recent targets. Let me assemble a few more diffs from various pages: 2023 Rolling Fork tornado, 2021 Western Kentucky tornado, Tornado outbreak of March 31, 2023, Tornado outbreak of December 10, 2021, Tornadoes of 2020, 2015 Rochelle-Fairdale tornado, Tornadoes of 2014, Tornadoes of 2013, Tornadoes of 2013 again, Tornado outbreak of November 17, 2013, and one, two, three, and four instances on 2013 El Reno tornado. There are probably more out there and there are certainly more to come as this is one of the easiest ways to vandalize a tornado article (literally changing one number). Also note the first diff was a reversion to a clean version after multiple previous disruptive edits, as are at least one of these new examples. All tornado and tornado outbreak articles are vulnerable to this and disruption often occurs years after the event leaves the news cycle so protection may not be the way to go in my opinion. GeorgeMemulous (talk) 00:22, 24 October 2024 (UTC)

Doing... Fair enough. I'll see if I can whip up a preliminary start to this. EggRoll97 ^(talk) 00:29, 24 October 2024 (UTC)

I'll summarize a few points as you said you aren't too familiar with the topic:

• Tornadoes in the US and Canada are rated on the Enhanced Fujita scale, shortened to EF. This scale ranges from 0 to 5.
• Tornadoes in the rest of the world are often rated on the International Fujita scale, shortened to IF. Again, 0 to 5.
• Some countries still use the legacy Fujita scale, shortened to F. This goes from 0 to 12, but only 0 to 5 have ever been final.
• All are formatted similarly: F0, EF1, IF2, F3, EF4, IF5.
• Citations to verify typically come from the NCEI database or ESWD, but preliminary ratings often come from Twitter or a statement from the local NWS office.
• The TORRO scale is more or less unused and obscure to the point where it's an unlikely disruption target.

Cheers! GeorgeMemulous (talk) 00:48, 24 October 2024 (UTC)

Update, Still doing..., though at a fairly slow speed. If anyone wants to take over on coding, absolutely go ahead. Things in the real world have been taking a slight bit of a toll over the last bit. EggRoll97 ^(talk) 22:34, 30 October 2024 (UTC)

Update, probably don't see myself working on this, but a filter should be made. Not sure if anyone wants to pick this up by chance. EggRoll97 ^(talk) 04:55, 9 November 2024 (UTC)

@EggRoll97 and GeorgeMemulous: Here is some basic filter code we could use:

!("extendedconfirmed" in user_groups) &
page_namespace == 0 &
!(added_lines contains "<ref") & (
  scaleStr := "(?:E|I)?F[0-5]";
  removed_lines contains scaleStr &
  added_lines contains scaleStr
  !(removed_lines = added_lines)
)

What this should do is check if anyone is adding hurricane scale numbers and removing different ones without a source. Thanks, – PharyngealImplosive7 (talk) 17:50, 10 November 2024 (UTC).

Testing at 1324 Looks good for testing. I've been busy over the last bit, but I can toss this in and keep an eye on it (by the way, an & was forgotten at the end of line 6). Thanks! EggRoll97 ^(talk) 23:44, 10 November 2024 (UTC)

I think the current filter is broken that it could not catch the changes, even with FilterDebugger. contains would have to look for the entire phrase itself, while irlike is recommended for regex. Here's what I wrote instead:

page_namespace == 0 &
page_title irlike "hurricane|tornado" &
!contains_any(user_groups, "extendedconfirmed", "sysop", "bot") &
edit_delta <= 2 &
(
    scaleStr := "\b[EI]?F[0-5]\b";
    not_intensity_num := "[^0-5]";
    removed_lines rlike scaleStr &
    added_lines rlike scaleStr &
    str_replace_regexp(added_lines, not_intensity_num, "") != str_replace_regexp(removed_lines, not_intensity_num, "")
) &
!(summary irlike "^(?:revert|rv|undid)")

I am pinging both PharyngealImplosive7 and EggRoll97. Codename Noreste 🤔 Talk 01:30, 11 November 2024 (UTC)

I would suggest rlike since the scale ratings are usually marked with capital letters, but otherwise, looks good. Also do bots really make these changes? Anyways thanks for the help. – PharyngealImplosive7 (talk) 03:20, 11 November 2024 (UTC)

Bots make a lot of edits that change a line that doesn't contain '<ref' so excluding bots near the top means the filter doesn't needlessly check all the way to removed_lines or added_lines.

The last line's comparison seems unfinished, I think you meant to compare if the scale added is different than the one removed (i.e. not an unrelated change to the same line), but the current check is if removed and added lines are different, which is (surely?) always the case. – user usually at 2804:F14::/32, currently 143.208.239.58 (talk) 03:52, 11 November 2024 (UTC)

Modified the suggested code to use rlike for the regex, and added a condition piece to only target pages with the title tornado. Codename Noreste 🤔 Talk 04:14, 11 November 2024 (UTC)

Also, I noticed that you changed my original regex to (?:E|I)?F[0-5]{1,2}. Numbers above 5 are not used in any scale we are tracking, though they could exist theoretically on the Fujita Scale. As a result, I think you should delete the "{1,2}" part. – PharyngealImplosive7 (talk) 04:52, 11 November 2024 (UTC)

Looks good, though I've added hurricane to the page_title check, since this appears to occur with hurricane ratings as well. EggRoll97 ^(talk) 04:53, 11 November 2024 (UTC)

@EggRoll97: The regex also might need to be fixed, see my comment above. – PharyngealImplosive7 (talk) 04:56, 11 November 2024 (UTC)

{1,2} denotes that one minimum or two maximum numbers are allowed in the regex, but I will remove it from the filter's regex. Codename Noreste 🤔 Talk 05:05, 11 November 2024 (UTC)

And it's removed, PharyngealImplosive7. Note that I also changed (?:E|I)? to [EI]? as it only denotes a set of these two letters, so I don't think a non-capturing group is needed here. Codename Noreste 🤔 Talk 05:09, 11 November 2024 (UTC)

Yes that looks good. The IP in the conversation suggested we modify the last line of the regex (whether added lines is the same as removed lines. Any ideas on how to fix that like the IP said? – PharyngealImplosive7 (talk) 05:12, 11 November 2024 (UTC)

Maybe changing == to in would work? Codename Noreste 🤔 Talk 05:14, 11 November 2024 (UTC)

Just saw the comment about needing the regex fixed. Sorry, I was working on the filter with an old version of this page, so I didn't see the comment about fixing it until now. I've just removed the {1,2} from the regex, and changed (?:E|I)? to [EI]?. EggRoll97 ^(talk) 05:16, 11 November 2024 (UTC)

@EggRoll97: you should add word boundaries around that regex, this is matching %anything%F[0-5] making the [EI]? redundant.

Anon does have a point about comparing added/removed_lines. This checks if somebody edits an existing line containing that sequence but not if that sequence has been changed (this is what OP wants) - e.g.: if somebody solely adds a period somewhere in a line containing that sequence, this will trip. XXBlackburnXx (talk) 11:09, 11 November 2024 (UTC)

I've added the word boundaries, though I'm not sure if it's supposed to encase just the [EI] or the entirety of the string. Not sure about the comparison of added/removed. Codename Noreste's solution may work with changing == to in. EggRoll97 ^(talk) 13:29, 11 November 2024 (UTC)

I'm pretty sure it is supposed to encase the entire string like you have done, but about the changing of the == to in, I can second that idea. – PharyngealImplosive7 (talk) 14:38, 11 November 2024 (UTC)

And finally, this filter would probably also catch good-faith edits that are reverting this kind of vandalism, so I would suggest adding a line that says !(summary irlike "^(?:revert|rv|undid)") to the filter. – PharyngealImplosive7 (talk) 14:49, 11 November 2024 (UTC)

I've updated the code. – PharyngealImplosive7 (talk) 15:33, 11 November 2024 (UTC)

It's not the best, but you could technically replace all [^0-5] characters (with str_replace_regexp) in both added and removed lines with an empty string and then compare the resulting strings, supposedly what that then would be checking is if any 0 to 5 number was changed, removed or added in the edit (or swapped order...), which would probably reduce most of the potential false positives. A more ideal change would be to get all the matches and compare that, but I don't know how to do that efficiently. Mind you, this would replace the in version, though I'm unsure what that actually does.

Something else: Checking if it's a revert is cheap (and reverts happen often), could move that up. – 2804:F1...DF:61D4 (::/32) (talk) 16:44, 11 November 2024 (UTC)

Yeah I moved the revert code up, though I'm not sure about your other idea. If you could make some code, it would help more. Also pinging @EggRoll97: to see if he could implement the most recent changes to the filter. – PharyngealImplosive7 (talk) 17:39, 11 November 2024 (UTC)

It's an idea based off of Special:AbuseFilter/1248, though instead of replacing the number to see if the rest is the same it would be something like:

scaleStr := "\b[EI]?F[0-5]\b";
not_intensity_num := "[^0-5]";

//.. other code

str_replace_regexp(added_lines, not_intensity_num, "") != str_replace_regexp(removed_lines, not_intensity_num, "")

Essentially removing all characters except 0 to 5, comparing the resulting sequence of numbers to see if it changed. – 2804:F1...DF:61D4 (::/32) (talk) 19:11, 11 November 2024 (UTC)

Yeah, I understand what you mean. I've gone ahead and implemented your suggestion with a few minor changes, but it would be great if an EFH/EFM could review the changes and implement them. – PharyngealImplosive7 (talk) 19:40, 11 November 2024 (UTC)

At the risk of elongating this section even more, just curious, why !(x == y) instead of x != y? – 2804:F1...DF:61D4 (::/32) (talk) 19:54, 11 November 2024 (UTC)

I mean in general it is used to clarify in a more clear way what is supposed to be equal and what is, but it really doesn't matter that much. I can change it if you like. – PharyngealImplosive7 (talk) 20:03, 11 November 2024 (UTC)

Remodified the code again because this is getting nowhere. I placed the summary exclusion code at the very bottom, and intentionally placed page_namespace at the very top of the filter, and page_title at the second top for performance reasons. I removed the reference addition exclusion by replacing it with edit_delta <= 2 (equals or less than 2 bytes) since the edit_delta for these changes are going to be usually 0. Codename Noreste 🤔 Talk 20:39, 11 November 2024 (UTC)

@Codename Noreste, PharyngealImplosive7, and 2804:F14:8092:C01:116E:4A01:43DF:61D4: Implemented the changes, with the exception of the edit_delta check replacing the added refs check. That would seem to me to hit every change to an intensity number even with new references? It seems best to just keep the added references check, no? EggRoll97 ^(talk) 20:46, 11 November 2024 (UTC)

For now, I'm not sure of a good way to actually exclude sourced changes while logging unsourced ones. Codename Noreste 🤔 Talk 20:48, 11 November 2024 (UTC)

Yes I was about to comment about that. After analyzing the edits provided, I noticed that some are above 2 in edit delta, especially when they vandalize other sections of the page. As a result, I believe we should keep the references check. – PharyngealImplosive7 (talk) 20:48, 11 November 2024 (UTC)

However for now, now that the filter has been significantly modified, we should probably leave it to be tested until we get a few hits and can assess how it is doing. Courtesy ping to @Departure–: to let him know the filter should be more or less ready. – PharyngealImplosive7 (talk) 20:54, 11 November 2024 (UTC)

Preventing Page Blanking

• Task: Restricting non-autoconfirmed users (recently registered accounts and IPs) from blanking pages in the Wikipedia: namespace.
• Reason: This is my first time requesting an edit filter, so I apologize in advance if this has already been proposed and declined. Over the past few days, I’ve noticed instances of page blanking in Wikipedia namespace pages, including manuals, policies, and shortcuts. I believe it could be beneficial to implement a filter to prevent such actions. Additionally, I'd like to invite editfilters to consider applying this filter to other namespaces, such as Main: and Portal:.
• Diffs: 1, 2, 3, 4, 5, 6.

— Tres Libras (talk) 19:50, 18 November 2024 (UTC)

We already have filter 1151 (hist · log) for this purpose, but it only allows 2 blankings in 30 minutes before that filter prevents any more from anonymous and non-autoconfirmed users. Codename Noreste 🤔 Talk 21:00, 18 November 2024 (UTC)

Ah, I see. I was surprised that enwiki doesn’t have anti-blanking filters in place. On other wikis, these filters completely prevent blanking, so I assumed the same would apply here. Thank you for your response! — Tres Libras (talk) 21:12, 18 November 2024 (UTC)

The redirect blankings also get picked up by filter 1318 (hist · log) which I've been patrolling daily, so those aren't the big problem. Filter 1151 (hist · log) probably could need improvement, but I don't think any EFM is currently interested in trying it. Nobody (talk) 06:20, 19 November 2024 (UTC)

Prevent insertion of lyrics from Thick of It

• Task: Add certain lyrics to filter 614 (such as /From the screen to the ring/)
• Reason: To prevent new users from inserting lyrics from the song (usually vandalism), which avoids edits from being revdelled
• Diffs: Special:Diff/1258652804, Special:Diff/1253354917; these had lyrics from the song, but were revdelled.

--Leonidlednev (T, C, L) 22:16, 20 November 2024 (UTC)

Special:Diff/1258868399 the Thick of It copy-paste struck again. ABG (Talk/Report any mistakes here) 02:08, 22 November 2024 (UTC)

Special:Diff/1259041737 – 2804:F1...86:EF41 (::/32) (talk) 01:38, 23 November 2024 (UTC)

Prevent insertion of "smartschoolboy9"

• Task: Add words to 614 (like /smartschoolboy9/, with code for spaces, capitalization, etc)
• Reason: There have been numerous vandalous edits, especially among United Kingdom-related articles like Doncaster, centered around an English Instagram user who goes under the username "smartschoolboy9". His account received widespread attention during the summer of this year.
• Diffs: Special:Diff/1245680182, Special:Diff/1245111232, Special:Diff/1246041092, Special:Diff/1258635711

OpalYosutebito (talk) 03:38, 22 November 2024 (UTC)

I think we could just add the simple regex smartschoolboy9 to the filter. That should fix the problem. – PharyngealImplosive7 (talk) 01:41, 23 November 2024 (UTC)

That sounds a lot easier. Thanks for the help! - OpalYosutebito (talk) 01:44, 23 November 2024 (UTC)

Prevent Zalgo text

• Task: Disallow Zalgo text for new users, and warn older or extended confirmed users.
• Reason: It can disrupt the readability of an article. Additionally, quoting Zalgo text's Wikipedia article, "[as] Zalgo text has been used maliciously to crash or overwhelm messaging apps", an excess amount of Zalgofied characters (e.g. a whole Wikipedia article where every character has 100 or more combining diacritics) could crash web browsers.
• Diffs: While I have seen no instances of vandals adding Zalgo text so far, I believe it should be preemptively filtered out.

Doctor Zoath (talk) 04:47, 24 November 2024 (UTC)