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

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: [1] [2] [3]

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)

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)

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)

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)

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)

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)

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)