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

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: [1], [2], [3], [4], [5], [6], [7], [8]). 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)

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)

References

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: [9], [10], [11]

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)

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)

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)

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)

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): [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

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)

Block "Billy Flowers" edits

• Task: For the last few days I've found various IPs adding material about a Billy Flowers(see [28]) 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 [[29]]. Unfortunately I didn't keep samples from other IP addresses. ALso found [30].

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)

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)