Wikipedia:Edit filter/Requested

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Requested edit filters

This page is for people without the abusefilter-modify permission or people without sufficient knowledge about the coding involved to make requests to enact edit filters.

Private filters should not be discussed in detail. Please use the mailing list if you have specific concerns or questions about the content of hidden filters.

Please add a new section at the bottom using the following format:

==Filter name==
*'''Task''': What is the filter supposed to do? To what pages and editors does it apply?
*'''Reason''': Why is the filter needed? ~~~~

Bear the following in mind:

  • Filters are applied to all edits. Therefore, problematic changes that apply to a single page are likely not suitable for an edit filter.
  • Each filter takes time to run, making editing (and to some extent other things) slightly slower. The time is only a few milliseconds per filter, but with enough filters that adds up. When the system is near its limit, adding a new filter may require removing another filter in order to keep the system within its limits.
  • There is a limit to what filters can check for. More complex, non-essential tasks, such as those that need to perform a more in-depth check of the page or fetch information that the filter system does not have access to, are better served by separate software, run by an individual user on their own machine or dedicated server such as Tool Labs, rather than those used to actually host Wikipedia.
  • It used to be called the abuse filter for a reason. Contributors are not expected to have read all 200+ policies, guidelines and style pages. 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 – quite apart from performance concerns, if it doesn't harm the project, it is best not to hassle new contributors because of it.
  • To prevent the creation of pages with certain names, MediaWiki:Titleblacklist 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.



Non-autoconfirmed user rapidly reverting edits[edit]

Just a note: it probably would be more useful if this filter, once triggered, would block further instances around the same time the bot reports to AIV for triggering the filter 5+ times instead of simply logging while allowing further disruption. It can take 20 minutes and over before derp revert vandals get blocked while a small army of patrollers must remain active to revert each edit, which appears suboptimal (i.e. see the still-ongoing 114.17.235.146). Thanks, —PaleoNeonate – 02:52, 1 October 2017 (UTC)

So disruption persisted for 34 minutes for this IP address alone. —PaleoNeonate – 02:58, 1 October 2017 (UTC)
29 minutes before 46.150.88.31 was stopped/blocked. —PaleoNeonate – 04:04, 1 October 2017 (UTC)
  • I'd support this for a trial period. Checking the last 500 times this filter fired, just a handful of the Ips that triggered it are not blocked as of now. CrowCaw 19:16, 1 October 2017 (UTC)

Refspammer[edit]

  • Task: Prevent additions of text referencing Maximiliano Korstanje, (including, e.g., Korstanje, M. E.), or thana\s?(tourism|capitalism) (case insensitive, obv).
  • Reason: Years of self-promotion and refspamming by the subject (who also created an article on himself, now deleted and salted). Recent example: [1]. I'm pretty sure this would fit into some existing filter, but my RegEx-fu is not strong enough. Guy (Help!) 22:58, 25 February 2019 (UTC)

Preventing blank speedy contesting[edit]

  • Task: Disallow edits that consist of creating a talk page with the default This page should not be speedily deleted because... (your reason here) --~~~~ text generated by the "contest this speedy deletion" button of every {{db-xxx}} template
  • Reason: New users frequently believe that just clicking the button is sufficient to contest a speedy deletion, just creating the default text without further information. The filter could prevent this by requiring the default text to be modified before saving (or by requiring that "(your reason here)" is not on the page). Regards SoWhy 08:15, 27 February 2019 (UTC)
    @SoWhy: Perhaps an edit intro might be worth trying first? Something along the lines of Template:Falsepositive/Editintro or Template:BLPN notice, but perhaps larger and more eye-catching. If you want to get really fancy, it could even be customized for each speedy category, unlike the filter warning. Suffusion of Yellow (talk) 02:10, 28 February 2019 (UTC)
    Good idea (which someone already had in 2011 but was never implemented). That said, I see no problem with having both an edit intro and a filter preventing empty contentions. Regards SoWhy 08:55, 28 February 2019 (UTC)
    @SoWhy:  Done as 968 (hist · log) (log-only for now). My initial reaction was that a filter would be BITEy (WP:HNST etc.), but on second reflection deleting the page when they think they've contested it is even BITEier. Even if we don't implement the warning, the filter can be used to gather data on the effectiveness of the editintro, so can you hold off on implementing it until the filter has been confirmed as working, for a few days? The filter needs to account for all the Special:Prefixindex/Template:Hangon variations, and all the, um "creative" places the user might put their request, so may need more work. Suffusion of Yellow (talk) 01:47, 1 March 2019 (UTC)
    @Suffusion of Yellow: Thanks! Seems to work for this edit. I proposed the change to {{db-meta}} at Template talk:db-meta and I'm waiting for feedback anyway before editing a template that affects thousands of pages. Regards SoWhy 08:10, 1 March 2019 (UTC)
    @SoWhy: Looks like it was missing Template:Hangon preload A7. I've also temporarily set 1 (hist · log) to log all edits with a summary containing "Contested deletion", to see what others 968 (hist · log) might be missing. Suffusion of Yellow (talk) 19:26, 1 March 2019 (UTC)
    Still only one hit. Filter 1 now just looking for "your reason here" instead, because there seems to something buggy with the summary check. Suffusion of Yellow (talk) 16:51, 3 March 2019 (UTC)

───────────────────────── @SoWhy: I've disabled the filter until we decide what to do. It's probably skipped over a few because of the edit summary bug, but that should be most of them. Looking through the hits, do you see anything that's not completely hopeless on the (deleted) pages? That is, would there be any point to a warning, other than to encourage the user to write a message that will be ignored anyway? I'm curious. Suffusion of Yellow (talk) 01:43, 6 April 2019 (UTC)

Common Vandal Summaries filter[edit]

Task: Log edit summaries according to I? ?(([Tt]ypo)? ?[Ff]ix(ed)? ?[Aa]? ?([Ss]ome)? ?([Tt]ypo(es)?s?|[Gg]rammar)?|[Aa]dded [Aa]? ?([Ss]ome)? ?([Ll]inks?|[Cc]ontent))

Reason:Building on the request above, maybe it's a good idea to have a log-only(do nothing), or possibly tag filter for common edit summaries used by vandals. People could patrol that as a further refinement on the existing maybe bad edit recentchanges filter. [Username Needed] 19:42, 28 February 2019 (UTC)

@Username Needed: I like the idea of a log-only or tagging filter for generic vandal summaries; I'm kind of surprised we don't have one already. I'd also add "made it better" and some of the milder ones that were taken out of Filter 384 ("lol", "blah", "crap", "was here", etc.). But I'm hesitant to name it "Common Vandal Summaries" for something as innocent as "Fixed a typo". Can you think of a better name, that won't offend people when it shows up in their filter log after they fix an actual typo with the summary "fixed a typo", but still hints to patrollers why it was logged? Suffusion of Yellow (talk) 17:19, 3 March 2019 (UTC)
  • Maybe just "Common Summaries" or "Common edit summaries"? [Username Needed] 19:34, 3 March 2019 (UTC)
  • Actually "Stock summaries" may be a good name. [Username Needed] 20:19, 3 March 2019 (UTC)
  • @Username Needed:  Done, as 970 (hist · log), with your suggestions. I suspect there will be way to many FPs for this to be useful, but it's worth a try. It also might be possible to refine based on edit_delta, e.g. only log "added content" when the size decreases, etc. Suffusion of Yellow (talk) 23:08, 3 March 2019 (UTC)
    Suffusion of Yellow, FYI, there's some overlap here with Filter 633 and the "canned edit summaries" tag. Gaelan 💬✏️ 05:06, 4 March 2019 (UTC)
  • @Gaelan: It should exclude anything that already hit 633. I'm not seeing anything here that hit both. Suffusion of Yellow (talk) 07:23, 4 March 2019 (UTC)
    Suffusion of Yellow, There's no need to check user_mobile == 1 is there? Since 633 now only checks user_app == 1 Galobtter (pingó mió) 09:58, 4 March 2019 (UTC)
    @Galobtter: Thanks, removed the check. The mobile web interface does suggest "Example: Fixed typo, added content", but the user still needs to manually type them in. Suffusion of Yellow (talk) 17:28, 4 March 2019 (UTC)
  • I took a sample of the most recent 20 edits and got a 35% FP rate (or 25% if you count non-disruptive edits with misleading summaries). [Username Needed] 12:38, 4 March 2019 (UTC)
  • Most FPs (all bar 1) had an edit delta of <10. Maybe that could reduce the amount of FPs? [Username Needed] 12:42, 4 March 2019 (UTC)
  • I've looked through some of the "Added content" section of the data dump and it might be useful to exclude anything that adds a <ref> tag. That should also reduce the FP rate considerably. (Although it depends on whether you think that adding unsourced information should be excluded or not, otherwise it removes a much smaller amount) [Username Needed] 09:02, 5 March 2019 (UTC)
  • Since we seem to be using this to monitor, I've put a noarchive on this in case any of us go on a wikibreak. [Username Needed] 09:08, 5 March 2019 (UTC)

───────────────────────── @Username Needed: So. I think I see what's going on here. That vast majority of hits are for exactly (up to capitalization) the phrases "added content" and "fixed typo". So it's not so much a case of sneakiness, but laziness. The mobile web site suggests Example: Fixed typo, added content so that's what people are typing when they think they have to type something there. Either that or I have much narrower definition of "typo" than most people. Anyway, I've disabled the filter for now while I think about this. 3700 hits is enough data. I'm wondering if instead MediaWiki:Mobile-frontend-editor-summary-placeholder could use some refinement. Suffusion of Yellow (talk) 20:29, 10 March 2019 (UTC)

@Username Needed: I've re-enabled it for now, with some edit_delta checks. We have other filters that check for unreferenced content, so I'm only logging "Added content" when the edit_delta <= 0. For "Fixed typo", I've gone with your suggestion of only checking edit_delta > 10 | edit_delta < -10. I've also created 981, named, in fact, "Common vandal summaries". Right now it's just checking for the word list from 384. See Wikipedia:Edit_filter/False_positives/Archive_96#149.135.11.157 for why it was removed from that filter.
@Galobtter: In that thread you mentioned some stuff from other filters. Since the 981 is not disallowing yet, now would be a good time add anything you had in mind. Suffusion of Yellow (talk) 01:31, 6 April 2019 (UTC)
Hmm, I don't remember what those filters were; as a sidenote, you need !summary rlike ("\[\[Special:Contributions.*(" + match + ".*)") from 225, otherwise all reversion of users with bad names will be blocked. Galobtter (pingó mió) 15:21, 7 April 2019 (UTC)

Log edits to other's editnotices[edit]

  • Task:
  1. Namespace is User or User talk
  2. Page creations or edits
  3. base user/usertalkpagesPages ending in Emailnotice or Editnotice (user SUBpages editnotices are already in the titleBL)
  4. Edit not made by username==basepagename , admins, bots, templateeditors (I don't really think we need pagemovers here - their titleblacklist access is primarily for a different reason)
  • Reason: See discussion. Will need tweaking, set to log only. May be able to model on parts of 803. — xaosflux Talk 01:05, 1 May 2019 (UTC)
  • We could either make it as restrictive as possible, account owner and iAdmins only, or just make it the usual, not-!confirmed. I do not see a basis for the grey area of TE/bots/admins, but if it's log only, anything goes (and I am better with the second criterion). --qedk (t c) 07:48, 1 May 2019 (UTC)
  •  Comment: There are also email notices, and group editnotices. --qedk (t c) 07:49, 1 May 2019 (UTC)
    Group edit notices are only done through the normal edit notice system, right? (And email notices are already included in the task description) --DannyS712 (talk) 16:08, 3 May 2019 (UTC)
    The pages we're talking about would be User:Example/Editnotice, User talk:Exaqmple/Editnotice, and User:Example/Emailnotice. עוד מישהו Od Mishehu 11:59, 6 May 2019 (UTC)
Done, see Special:AbuseFilter/989. Galobtter (pingó mió) 14:03, 6 May 2019 (UTC)
Good work, it even caught this edit. Galob (talk) 19:38, 7 May 2019 (UTC)
First instance of actual vandalism caught now, Special:AbuseLog/24014455. Galobtter (pingó mió) 09:05, 19 May 2019 (UTC)
@Galobtter: More instances found, though in this case it was vandalism and then self reversion: https://en.wikipedia.org/w/index.php?title=User_talk:Materialscientist/Editnotice&action=history DannyS712 (talk) 00:13, 8 June 2019 (UTC)
Also pinging Materialscientist so that they are aware --DannyS712 (talk) 00:14, 8 June 2019 (UTC)
Materialscientist has disabled pings :) I saw the instance of vandalism above; need some more discussion to set this to disallow. Galobtter (pingó mió) 08:51, 8 June 2019 (UTC)

Prevent unregistered editors from creating GA-review pages[edit]

  • Task: Prevent IP editors from creating /GA[0-9] subpages of pages in the Talk: namespace
  • Reason: Per WP:GAREVIEW, only registered users are allowed to review good article nominations. However, since the process involves creating a /GA[0-9] subpage of the talk page of the article in question, IP editors can create review pages. This confuses the bot that maintains WP:GAN and the GA process (e.g. [2]) and requires admins to manually delete these pages and revert the bot's edits. So an edit filter that simply blocks such creations could save some work and is unlikely to cause problems since there is no conceivable reason why an IP editor should create such a subpage. Regards SoWhy 10:59, 27 May 2019 (UTC)
Something along the lines of user_age === 0 && page_id === 0 && page_namespace === 1 && page_title contains '/GA' might do the trick. Can someone with access to the test interface take a look? --DannyS712 (talk) 15:59, 7 June 2019 (UTC)
  • I'd like to see a custom message created prior to blocking anyone, as the default will just say "your edit was unconstructive". I'll set up log-only to see how big of a problem this is. Remember that EF runs against every edit, so having a good ROI is desirable. Is fixing the bot so it looks at the page creator an option? CrowCaw 19:22, 7 June 2019 (UTC)
    @Crow: that still wouldn't fix the fact that the page was created. I agree that this shouldn't block for now, but even log only would be helpful. Also, what is ROI? DannyS712 (talk) 20:01, 7 June 2019 (UTC)
  • If it rises to that level. So far zero hits on the watch filter. As for the bot, it should be possible for a bot to check the creator and either outright delete the page (if approved) or simply add a CSD-G6 to it. Yes an admin would still have to delete it of course. CrowCaw 15:26, 9 June 2019 (UTC)

Base64 image data[edit]

  • Task: Catch people adding base64-encoded images to pages (instead of just uploading the image). Off the top of my head, should apply to mainspace and userspace (and their talk pages), but should specifically exclude User:(username)/*.css and User:(username)/*.js, since as far as I can tell those are legitimate uses for themes. To get an idea of the content it would catch, search userspace for "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD"
  • Reason: Other than the above-mentioned exception, I can't see many legitimate uses for people uploading base64-encoded images (or any sort of file, for that matter) to Wikipedia - this isn't the place for file storage, it goes around the standard file upload method, and there's no way to verify the files conform to Wikipedia's licensing requirements. Also, it's not easily readable without plugging the data into a decoder. I don't think this would necessarily be a high-traffic filter, but I do think it would be useful as a warning or a tag.

If this does seem like a useful filter, I'm happy to throw together a prototype -- I just wanted to check whether it seemed useful to other people before starting on it. creffett (talk) 02:21, 1 June 2019 (UTC)

Creffett, I added "data:image" to filter 220. Galobtter (pingó mió) 13:24, 7 June 2019 (UTC)
@Galobtter: That works. Thank you! creffett (talk) 13:25, 7 June 2019 (UTC)

Russian filter on 1 page[edit]

Abote2 (talk) 10:57, 7 June 2019 (UTC)

 Done, added to 906. Galobtter (pingó mió) 12:29, 7 June 2019 (UTC)

Isn't there a filter for this already?[edit]

Filter name[edit]

  • Task: Block all edits with the Citation bot [1.1.0] tag (OAuth CID: 1365). This should be a high-priority task.
  • Reason: There is more information at User_talk:Citation_bot#Need_to_use_user_OAuth, but the jist of it is that recent changes to the bot's code were made (in good faith) but misinterpreted the community desired. The bot can be run in fully automated mode under various user accounts, against WP:BOTPOL#MULTIOP. These edits needs to be blocked while the code is being updated. Headbomb {t · c · p · b} 02:52, 18 June 2019 (UTC)
    Honestly, this seems like something where you'd want to request the Stewards (at m:Stewards requests/Miscellaneous) to revoke the OAuth consumer. Although I can't find any documentation of when consumer keys are revoked, egregiously violating WP:BOTPOL does seem like something for which that should be done.. Galobtter (pingó mió) 20:04, 18 June 2019 (UTC)
Maybe so, but in the meantime could this be implemented? Especially if stewards don't get to this before the issue is fixed (after which OAuth will need to be re-instated). Headbomb {t · c · p · b} 20:42, 18 June 2019 (UTC)
Seems resolved now. No idea why, but the EF is no longuer needed. Headbomb {t · c · p · b} 22:17, 18 June 2019 (UTC)