Wikipedia:Edit filter/Requested/Archive 16

Changing {{good article}} to {{bad article}}

Edit filter for removal of AfC templates on draft pages

A malicious tactic or sometimes an innocent mistake new editors make on AfC submissions is removing the "decline" message or comments on the draft from reviewers. This can prevent future reviewers from seeing how many times the article has been declined or notes that past reviewers have left on, e.g. sourcing, an important factor in reviewing an article unless the reviewer takes the time to look through the page history. An edit filter should be created to prevent removal of the the template AFC submission|d (having only the decline parameter is important: new editors are welcome to remove the "submitted" template that appears without the decline parameter) or {{AFC comment}} by non extended-confirmed users in the draft space. At first, feel free to just set it to log so the logs can be reviewed for any potential false positives. My request stems from discussion at Wikipedia_talk:WikiProject_Articles_for_creation#new(?)_spam_tactic. Sam-2727 (talk) 05:25, 21 August 2020 (UTC)

Extended confirmed because the minimum requirement for AfC reviewing is 500 mainspace edits, so you really shouldn't be removing these unless you are extended confirmed. Sam-2727 (talk) 05:26, 21 August 2020 (UTC)
  • Just a thought from a reviewer who's not as active in that area as I once was: unless the reviewer takes the time to look through the page history... that is part and parcel with what reviewing the submission entails, no? CrowCaw 13:24, 21 August 2020 (UTC)
    Crow, I personally only look through the page history if it's an old submission. If it's the first time the article has been submitted I don't see a good reason to go through the page history, unless I suspect the problem of the decline template being removed. This is particularly so for obvious decline submissions. I will decline more or less immediately without looking through the page history because it is clear that the article is inadequate in its current form. For older submissions, I will look through the page history to see what improvements have been made. Sam-2727 (talk) 17:41, 21 August 2020 (UTC)
  • Note that no one is required to use AfC. If the "submited" template is removed (as it is mentioned above is perfectly acceptable), it is not only permitted but desired for all "declined" templates to also be removed. Therefore any such filter should not fire if the submitted template is not present, or is being removed in the same edit. DES (talk)DESiegel Contribs 15:18, 22 August 2020 (UTC)
  • Honestly seems a bit WP:BITEy to me. A reviewer should at least look in the history and notice names that may indicate possible reviewers having added a comment. It takes a few seconds. Technically speaking, this could be done by looking for modifications to {{AFC comment}} and not {{AFC submission in the new page text (to allow for removal of everything). But I still think it's BITEy, and nothing a reviewer shouldn't spot themselves with a glance of history. An editor could also alter the submission template removing past decline completely, plenty of ways to "abuse" the AfC process, if that's what you consider this (I personally don't), thus I don't think this change covers all bases anyway. ProcrastinatingReader (talk) 16:10, 10 September 2020 (UTC)

Filter 1068

Seems that Filter 1068 should be updated to also filter this recently reverted variation of the same name.—Bagumba (talk) 05:36, 3 September 2020 (UTC)

Cutler vandal, take 3

  • Task: Tweak existing filter to match current edits from Cutler LTA
  • Reason: In March 2018, filter 909 was created to help deal with a LTA I call the Cutler vandal. He's got some really way out there conspiracy theories and has been pushing them on Wikipedia for years. The filter was tweaked in December 2018 and Cutler has been reasonably quiet until the past few months. He's starting to post more frequently and with some serious allegation about living people and of course, not a source in sight. See [1] and [2] for some examples. He's usually active on Special:Contributions/107.77.192.0/20 or Special:Contributions/172.58.200.0/21. At least half a dozen articles have been semi'd in the past month to slow him down and he's just moving to other articles. There look to be more good edits than bad in both ranges, so blocking doesn't appear to be a good option. I'm hoping the existing filter can be tweaked to slow this guy down some. Pinging Prolog as they've been involved with this LTA for years for possible other thoughts. Ravensfire (talk) 00:12, 6 September 2020 (UTC)

Bosnian swearing

  • Task: Modify filters 102 and/or 579 to prevent new users from registering with usernames containing the Bosnian phrase "Jebem Majku".
  • Reason: If google translate is to be believed, the phrase translates to "mother fucker". Sockpuppeteer User:HankMoodyTZ has used accounts with this phrase in their names on at least two occasions. Sir Sputnik (talk) 21:02, 7 September 2020 (UTC)
    I don't see such examples on their SPI casepage, but this is one of those things that should be sent into the EF mailing list privately, rather than requested at this board, imo. Same for most things involving socks or LTAs. EFMs: maybe a note to this effect should be added at the top of the page? ProcrastinatingReader (talk) 16:12, 10 September 2020 (UTC)

Controversial claims about a BLP

So in response to this mess I wonder if it's a good idea to have an editfilter to log controversial claims being added to a BLP, to create a central log people can look over. As in, that they shot/murdered/killed/raped etc. I note we have 189 but this mostly catches silly vandalism. In this case, the article also got past NPP somehow, and whilst that suggests an issue on the part of NPP, I think it's a decent idea to be logging controversial BLP claims anyway. It also looks like currently we don't even have an EF to catch these kinds of claims for low-edit users. Though, note:

  1. In the particular case, the editor had 4k+ edits. Most such EFs are generally low editcount (generally flag up silly vandalism). This filter should catch results regardless of edit count, but ideally not excluding those which were blocked by other filters, if possible, to filter out blatant vandalism.
  2. re. concern the log may be spammed: is really that common for people to add these controversial remarks to BLPs (that aren't blatant vandalism)? I think it'd be interesting to trial this EF and see how often it flags.
  3. Issue with this particular page was that it wasn't added to Category:Living people for a few edits. I don't think it's an issue for most pages, but we could also probably do a regex on the new_wikitext and see if it reads like a BLP (bold names, DOBs, person infobox, etc)

Thinking this EF may help with some BLP libel issues, certainly with people checking over them. ProcrastinatingReader (talk) 17:53, 13 September 2020 (UTC)

P. A Noushad

Edit filters targeted at sockpuppeters or LTA cases should be discussed at the edit filter mailing list. Goose(Talk!) 23:53, 4 October 2020 (UTC)

The N-word in edit summaries

In a very few cases, almost all relating to historical usage, the N-word in edit summaries may sometimes be justifiable. In almost all cases, however, it will be an unacceptable racial slur which only a troll would use. See Wikipedia:Administrators' noticeboard/Incidents#Racial epithet and persistent (10+ years) vandalism; and if you can, and have a mind to, the WP:REVDELled WP:ESs on this linked page.

Would it be possible to write a filter which drew use of the N-word in ESs to the attention of interested editors for review? Specifically, editors with large teeth, short tempers, and admin powers. I found some ESs dating back to March 2019 which should never have lasted five minutes, and which were revdelled within minutes of my posting them at WP:ANI.

I would be very reluctant to see a filter with any broader scope without full discussion and WP:CONSENSUS. We are not WP:CENSORed, and should not engage in pearl-clutching. However, I submit that the N-word is in a class of its own. Narky Blert (talk) 20:49, 19 September 2020 (UTC)

You'd obviously have to whitelist a few pages, like Controversies about the word niggardly or Run, Nigger, Run, and there might be instances where it could be legitimately used (think of someone adding a section on a person getting caught up in a Donald Sterling-type controversy), but I agree that in the overwhelming majority of cases it'd be used for vandalism or some other unhelpful edit. Maybe set it to warn editors before allowing them to save. The Blade of the Northern Lights (話して下さい) 20:58, 19 September 2020 (UTC)
Filter 981 (hist · log) (split out of 384 (hist · log)), already looks for nigg(?:er|ah*). But it's log-only, because there's some other stuff in there that's prone to false positives ("lol", "crap", etc.). I've been meaning to split 981 into a log-only and disallow part for a really really long time now. It's a matter of sifting through the logs of 981 and seeing which words strongly correlate with vandalism. Controversies about the word niggardly or Run, Nigger, Run wouldn't be a problem, because the word is already in the old_wikitext. Suffusion of Yellow (talk) 02:59, 20 September 2020 (UTC)
Other legitimate uses include The Nigger of the 'Narcissus' and Guy Gibson's dog. Mention of articles like those in an edit summary strikes me as unlikely, though. Narky Blert (talk) 13:48, 20 September 2020 (UTC)
@Narky Blert: The filter won't trip in any 1629 articles (!) that already contain "nigger". There's no need to compile a list. Also, remember we're only checking non-autoconfirmed users here. It's best not to think in terms of "how offensive is this word" but "how likely is it that this user up to no good". Suffusion of Yellow (talk) 20:24, 20 September 2020 (UTC)
Ab-so-lutely. Narky Blert (talk) 21:20, 20 September 2020 (UTC)
@Narky Blert: See 1086 (hist · log). It's not set to disallow yet, because I'm still slowly moving words from 981 (hist · log), but once I'm done I'll start a thread at WP:EFN. Suffusion of Yellow (talk) 22:06, 21 September 2020 (UTC)

Peepee poopoo and variants

  • Task: Block edits adding "Peepee poopoo" and variants. This almost certainly has a sky-high vandalism:good-faith ratio, though there is a page PooPoo PeePee Tour, so there may well be false positives. This looks like a good fit for adding to Special:AbuseFilter/260.
  • Reason: See Special:Diff/984525672 for an example of this getting through (and not getting immediately reverted by ClueBot). Note that there's an extra "e" in "peepee", so looking for repeating letters would probably be necessary. Vahurzpu (talk) 20:01, 20 October 2020 (UTC)

Warn when adding non-existent files

  • Task: The filter already has a "missing file added" tag. That seems to do very little good. Could it instead warn them, as with the "Self-published (blog / web host)" filter?
  • Reason: It likely would only deter the laziest of vandals, but it might stop well-meaning editors from adding to the articles with missing files category. I have more than 20000 edits to my credit, roughly half are from fixing such errors. - Sumanuil (talk) 20:10, 5 October 2020 (UTC)
@Sumanuil:, the edit filter that tags edits with missing files is already set to "Warn user", so no action is needed. Goose(Talk!) 23:02, 5 October 2020 (UTC)

I mean, as in asking them to confirm and hit "submit" again. Does it do that? - Sumanuil (talk) 05:47, 6 October 2020 (UTC)

@Sumanuil yes, 971 should be doing that. Warn edit filters will show that warning message and require a submit again for the edit to go live. ProcrastinatingReader (talk) 16:00, 29 October 2020 (UTC)
@ProcrastinatingReader It doesn't seem to be doing so, though. Can someone double check? - Sumanuil (talk) 21:14, 29 October 2020 (UTC)
It will only apply to users with less than 100 edits, so it won't apply to your account. Further, it will only work in articlespace (not draftspace or any other namespace). ProcrastinatingReader (talk) 21:21, 29 October 2020 (UTC)
@ProcrastinatingReader Perhaps it shouldn't just apply to them. I see plenty of users with more than 100 edits who could benefit from the warning. - Sumanuil (talk) 22:12, 29 October 2020 (UTC)

Draft links

See Wikipedia:Edit filter noticeboard#Filter to prevent links to Draft articles being added in mainspace. There are detailed discussions and diffs in that thread. Such links violate MOS:DRAFTNOLINK. I recently created the tempalte {{uw-draft-link}} to notify people who insert such links not to do so again.

  • Task: This should trigger on edits that add links to the draft namespace in articles. It should block such edits by non-autoconfirmed or perhaps non-EC editors, and warn anyone else. It should not fire when a redirect is being created by a move from mainspace to draft, if that is possible.
  • Reason: Such links seem to be introduces to article space at a rate of about 2-4 pages per day. Possibly more if others are reverting them, that is what I have been finding on daily AWB runs. see difs at the above EFN thread, and I can supply more if wanted, or they can be found via my contributions, search for Draft and AWB. DES (talk)DESiegel Contribs 20:51, 19 August 2020 (UTC)
I raised this on the talk page because many/most of these links are to draft articles that have been rejected, and some are to hoaxes, so we really do not want them linked in our articles - Arjayay (talk) 13:59, 20 August 2020 (UTC)
Quite aside from that, any Draft is by definition not ready for article space, and should not be linked as perMOS:DRAFTNOLINK. Editors are linking to drafts that have been recently moved to draft space, and to drafts that they have created in any stage of the process. Many do not really understand the difference and why drafts should not be linked from articles, IMO. Most do not seem malicious. It is better to stop such edits and/or warn the editors than to clean up later, in my view. Hence this request. DES (talk)DESiegel Contribs 16:45, 20 August 2020 (UTC)
  • I support this request, though I don't have time to act on it right now. GeneralNotability (talk) 18:23, 31 August 2020 (UTC)
    Wouldn't a bot be more appropriate for this task? It would be able to remove such uses, deliver a talk page message, and it wouldn't contribute to the EF limit. WP:BOTREQ may be able to help, if so. ProcrastinatingReader (talk) 15:59, 10 September 2020 (UTC)
    Testing at 1090 (hist · log). GeneralNotability (talk) 20:49, 5 October 2020 (UTC)
    Hi GeneralNotability - any progress on this? There is a new discussion at User talk:Basilicofresco#Links to draft articles about how it might interfere with Frescobot's changes of external links to draft articles, to wikilinks to draft articles. - Arjayay (talk) 09:24, 4 November 2020 (UTC)
    Arjayay, the filter has been running in log-only mode for a while and seems to be working okay, if you (or someone else) want to draft a warning message I can flip it to warn. GeneralNotability (talk) 13:38, 4 November 2020 (UTC)

Prevent red links

  • Task: Warn non-confirmed users when adding any red links to articles. Then tag these edits with something like "Missing link added"
  • Reason: Reduces the work of editors cleaning up links being added to non-existent articles Eyebeller (talk) 13:16, 7 November 2020 (UTC)
@Eyebeller: I don't think this is a good idea. Per Wikipedia:Red link, red links aren't a problem, and warning users who try to add them might cause users to believe that they're discouraged or forbidden. ―(not an edit filter manager) Vahurzpu (talk) 17:13, 7 November 2020 (UTC)
A properly worded warning of the sort of "please make sure you spelled the title correctly", combined with excluding certain pages (such as WP:AFC/R), may be helpful. An attempt to use this to exclude links to non-viable article titles would probably be more a hindrance than a help. 147.161.8.182 (talk) 08:57, 8 November 2020 (UTC)
Although it might be too much work to filter, adding several links which are mostly red can be unhelpful. (My garage band consists of followed by a mixture of redlinks and mislinks to unrelated notables with similar names). Certes (talk) 11:00, 8 November 2020 (UTC)
I don't think we should be warning users for this. It's normal in some subject areas. This genus of beetles consists of: <lots of redlinked species pages> is perfectly acceptable. Suffusion of Yellow (talk) 20:18, 10 November 2020 (UTC)

Long repeating string of characters filter

  • Task: Something along the lines of .{4,} or a similar, but less potentially faulty match (specialize it for different character classes maybe, so for example give more room with digits and less with letters). Identify and disallow/warn long strings of characters, like AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (you get the idea)
  • Reason: It's a decently common form of vandalism in my experience, and would make sense to match on it for IPs/new users. Possible this already exists(?) and is disabled(?), but I have no way to tell, as I clearly still see this editing pattern. —moonythedwarf (Braden N.) 04:03, 11 November 2020 (UTC)
135 and 231 do some of this, and there may be others. .{4,} matches any four characters such as "test" but even four identical characters would rule out bold italics or the ]]]] terminating a wikilink at the end of an image caption. Ideally we'd also capture repetition of a few characters such as nenfuenufneunnfuen (real example from today) without trapping false positives such as assesses. Certes (talk) 14:11, 11 November 2020 (UTC)
Certes, Doublechecked myself, seems (.)\1{4,} is closer to what I wanted. —moonythedwarf (Braden N.) 14:14, 11 November 2020 (UTC)
  • This exists in several places. If you can list some that slipped through the filter we can look at tightening up the conditions. CrowCaw 15:12, 14 November 2020 (UTC)
    Crow, Much of it is user-space and draft-space, which I don't think existing filters are set to match on. —moonythedwarf (Braden N.) 14:20, 19 November 2020 (UTC)

User page vandalism filter

  • Task: Prevent new editors from creating/editing subpages of other user's user/user talk, and also forbid new users from editing other user's pages entirely.
!("confirmed" in user_groups) &
page_namespace / 2 == 1 &
(lcase(page_title) rlike "[^\/]+(\/.+)+" | (page_namespace == 2 && page_age == 0)) &
substr(lcase(page_title), 0, strpos(lcase(page_title), "/")) != lcase(user_name)

(not tested, but this should work)

  • Reason: This seems to be a form of attack by the occasional troll, and the number of legitimate reasons for a new user to edit someone else's subpage (or any user really) is very small. Two filters may be appropriate, with one instead auto-blocking for using page names with words like "dicks" in user page creation; although that could also just be kept as a moderation task. —moonythedwarf (Braden N.) 15:16, 12 November 2020 (UTC)
    A new editor leaving a message to a new editor? i.e. communication? We can't just prohibit collaboration. ProcrastinatingReader (talk) 22:44, 12 November 2020 (UTC)
    ProcrastinatingReader, Specifically subpages. It may make more sense to only prohibit creation, though. —moonythedwarf (Braden N.) 22:47, 12 November 2020 (UTC)
    Eh. This is effectively semi-protection of all subpages in 2 namespaces. I think such a proposal would have to go to the community via RfC. ProcrastinatingReader (talk) 22:50, 12 November 2020 (UTC)
    ProcrastinatingReader, Good point. I'll spend some time refining it and then bring it up. —moonythedwarf (Braden N.) 22:52, 12 November 2020 (UTC)
    End of the day, it seems in good sense to me to at least do a trial run of this specifically for page creation, and see what gets caught in the net. I don't think I've ever seen new editors collaboratively use their sandbox(es) though, which is food for thought. —moonythedwarf (Braden N.) 22:51, 12 November 2020 (UTC)
  • We'd need a tighter pattern than "IP edit user sub-pages". The filter is for enforcing policy, not making it, which is what this would do, as Proc.Reader said above. CrowCaw 15:11, 14 November 2020 (UTC)
  • We already have filter 733 (hist · log) for page creations. Some trolling/attack pages, yes, but lots of good-faith edits also. Suffusion of Yellow (talk) 19:02, 14 November 2020 (UTC)

Request an edit filter on "God said to me"

I don't know how to request one; this is my first time here. So we have this IP-hopper that vandalized many many articles on tropical cyclone and putting big letters of "God said to me..." This has gained Wikipedia cyclone articles attention off-wiki from non-editors. [3] [4]. The same IP has vandalized talk pages too, including mine: [5]. This is getting really annoying and out of hand, and ToBeFree has suggested an edit filter. Can someone please help me, TornadoLGS, ChessEric, Meteorologist200, and others? Thanks. ~ Destroyeraa🌀 22:09, 16 November 2020 (UTC)

That does sound like a classical filter case to me ~ ToBeFree (talk) 22:14, 16 November 2020 (UTC)
For reference to those unfamiliar with it, edits identical to this have been made to Hurricane Iota and several other storms this year. But these cases are not the only similar instances of "God" vandalism I've seen on Wikipedia. TornadoLGS (talk) 22:23, 16 November 2020 (UTC)
I'm for this as well. This has been a LONG hurricane season and with another storm possible later this week and a hurricane season next year that I'm willing to bet will also be above average, we need to solve this problem ASAP. This person was literally hopping around hurricane pages like Delta and Eta and saying that 'God' told them that storm would be a Cat 5 in 30 minutes. At one point on the Delta page, we had to fight them for 20 STRAIGHT MINUTES. Then after Delta dissipated, he vandalizes individual talk pages saying 'its a 5 now' and the devil was going getcha or some crap like that. Then Iota comes along and becomes at Cat 5...and they vandalized it again saying that it was going to be a 0 in 30 minutes. They were also simultaneously vandalizing individual talk pages as well, including my own. I honestly think that all religious figures, whether its 'God', 'Lord', or 'Allah', just need to be banned in the future. (Never though I'd say that in my life.)ChessEric (talk · contribs) 23:22, 16 November 2020 (UTC)
That would be problematic for any articles where religion is relevant. Perhaps something along the lines of barring non-autoconfirmed users from adding such language to articles, or at least articles not in a category pertaining to religion. TornadoLGS (talk) 23:59, 16 November 2020 (UTC)
I can look into this. TornadoLGS, Destroyeraa, ChessEric, others: can you link me some more examples? GeneralNotability (talk) 00:20, 17 November 2020 (UTC)
This is an old example, but it sticks in my memory [6]. It's different enough that perhaps the same filter wouldn't catch it, but it's similar in that the vandal(s) were rapidly reverting. As mentioned above, the same culprit who attacked Hurricane Iota also hit Hurricane Delta ([7]). I'll dig around a bit, if I can, because I seem to recall similar vandalism on some tornado articles. TornadoLGS (talk) 01:21, 17 November 2020 (UTC)
@TornadoLGS: I meant religious references on weather articles.ChessEric (talk · contribs) 02:49, 17 November 2020 (UTC)
@GeneralNotability, TornadoLGS, and ChessEric: I think all religious references (God, Lord, Allah, Buddha, Satan, Jesus, Christ, etc.) should be edit filtered on all pages relating to weather. There is absolutely no need for religious references on weather pages. ~ Destroyeraa🌀 13:31, 17 November 2020 (UTC)
  • It may be relevant when the term "Act of God" is used in a fiduciary context. CrowCaw 18:44, 17 November 2020 (UTC)
Blocking legitimate uses could be prevented, in most cases, by having the filter only apply to non-autoconfirmed users. TornadoLGS (talk) 01:38, 18 November 2020 (UTC)
@GeneralNotability: Got another one . Could a rangeblock handle this guy? TornadoLGS (talk) 18:32, 20 November 2020 (UTC)
TornadoLGS, I've applied fairly soft blocks (anon-only since they haven't yet created an account) to Special:Contributions/90.255.200.0/21 and Special:Contributions/90.253.64.0/18, which covers the IPs that have been seen in the past week. The overall range they're on is pretty wide (darned British mobile providers), so more blocks may be needed. GeneralNotability (talk) 01:54, 21 November 2020 (UTC)

Please implement a filter. Special:Contributions/90.255.186.105. ~ ToBeFree (talk) 18:34, 21 November 2020 (UTC)

Doing something about this. If anyone sees any more edits, please report here, but best to not make any more public suggestions about how the filter should work. Suffusion of Yellow (talk) 19:20, 21 November 2020 (UTC)
Since this page has been added to the growing list of targets for the LTA vandal, should it be temporarily semi-protected, at least until the edit filter is implemented? TornadoLGS (talk) 19:24, 21 November 2020 (UTC)
Thank you very much, Suffusion of Yellow.  
Regarding protection, there are enough eyes on this page to implement this if needed, and enough people who have knowingly decided not to do so yet. ~ ToBeFree (talk) 02:06, 22 November 2020 (UTC)

New diffs to report

I've started this section to organize any diffs.

Request: Page that has the same name as an admin's username be tagged as a possible attack and restricted.

A lot of admins have had attack pages created with their username. Some have been protected for being repeatedly recreated. Example: Zzuuzz, Xaosflux, Yamla, Yunshui, East718, Acalamari, and many more. NawlinWiki had 4 attack pages protected, and many more made! NawlinWiki, Nawlinwiki, Nawlin Wiki, Nawlin, Nawlin-Wiki, Nawlin wiki. There should be some sort of filter, as this looks like it has a very set pattern. 4thfile4thrank (talk) 18:50, 30 November 2020 (UTC)

  • Do you have recent examples of such? Lets just say you're not the only one to notice these...CrowCaw 14:29, 1 December 2020 (UTC)
    You could look at Bbb23 or Oshwah. Certes (talk) 16:16, 1 December 2020 (UTC)
  • We have 874 which does something similar, it could possibly be adapted. While annoying, though, it doesn't seem like this is a constant problem, with only one of the examples given being done in this year? CrowCaw 19:40, 1 December 2020 (UTC)
  • Just to point out that (a) a lot of these were down to one LTA user over ten years ago, and (b) many were created before the edit filter existed, and would be stopped by one of them now. Black Kite (talk) 16:58, 21 December 2020 (UTC)

Long-term India-related defamation

  • Task: This filter would
  • revert (and, ideally, suppress, since these edits all require suppression) edits by and
  • put a 31-hour block on
a particular IP editor engaged in an ongoing defamatory soapbox campaign in India-related articles, perhaps most frequently National Capital Region (India), but also a collection of others like Delhi Police and Ministry of Home Affairs (India). Recent assaults were from Special:Contributions/112.110.96.78, Special:Contributions/49.15.74.133, and Special:Contributions/49.15.154.94. The abusive language appears in the edit summaries as well as in the articles. Someone who can see suppressed edits should view the text (I don't think it varies) to craft the filter rule, as I don't want to reproduce the text here, but I can state that a telltale phrase is "OBC RAPISTS", all-capitals.
  • Reason: To limit damage from an IP user routinely posting defamatory messages in articles. Largoplazo (talk) 13:08, 23 November 2020 (UTC)
  • Note: 1022. -- zzuuzz (talk) 22:41, 23 November 2020 (UTC)

Here are the ranges being used. Basically any deleted edits within these ranges is this vandal:

We do have some filtering going on; on one hand we could probably do a bit more, but on the other hand it's not easy. -- zzuuzz (talk) 09:15, 23 December 2020 (UTC)

[12]. -- zzuuzz (talk) 10:44, 23 December 2020 (UTC)

"Scumbag"

I just ran into it being inserted to describe someone.[13]. I know it might be used in a quotation if the quote satisfied our polices, but is there any way an edit filter could help? Thanks. Doug Weller talk 14:13, 24 December 2020 (UTC)

While you're in there, I have similar sightings of "Shithole", though usually places rather than BLP. Certes (talk) 14:35, 24 December 2020 (UTC)

Special:AbuseFilter/891: More predatory publishers

Here are a couple more

  • Intech Open Science, {{doi|10.5772}} (intechopen.com)
    cleared, except in cases where images have been sourced, in which case a note-to-editor has been added. Used two searches, one or 'intechopen.com', the other for '10.5772'. --User:Ceyockey (talk to me) 02:08, 23 December 2019 (UTC)
  • International Institute of Social and Economic Sciences, {{doi|10.20472}} (iises.net)
    checked two searches ('iises.net' and '10.20472') and found no instances needing to be removed/revised. --User:Ceyockey (talk to me) 02:12, 23 December 2019 (UTC)
  • International Scientific Publications and Consulting Services, {{doi|10.5899}} (ispacs.com)
    checked two searches ('ispacs.com' and '10.5899') and found no instances needing to be removed/revised. --User:Ceyockey (talk to me) 02:18, 23 December 2019 (UTC)
  • Kowsar Publishing, {{doi|10.5812}}
    checked doi-based search and cleared from article space. --22:21, 23 December 2019 (UTC)
  • Mathews Open Access Journals, {{doi|10.30654}} (mathewsopenaccess.com)
    no article records found when searching with DOI base or URL base. --User:Ceyockey (talk to me) 22:21, 23 December 2019 (UTC)
  • OA Publishing London, {{doi|10.13172}} (oapublishinglondon.com)
    URL-based search turned up one Draft article; citation removed. DOI-based search turned up no ctiations. --User:Ceyockey (talk to me) 22:30, 23 December 2019 (UTC)
  • Science Alert, {{doi|10.5567}} and {{doi|10.3923}} (SciAlert.net)
    removal / replacement completed for the DOI values, except in cases of sourced images. --User:Ceyockey (talk to me) 03:53, 25 December 2019 (UTC)
    @Ceyockey: see also [14]. Headbomb {t · c · p · b} 18:47, 26 December 2019 (UTC)
  • Science Publications,{{doi|10.3844}}
  • SciPress, {{doi|10.18052}}
  • ScopeMed,{{doi|10.5455}}

Headbomb {t · c · p · b} 11:57, 18 November 2019 (UTC)

@Headbomb:   Added to the filter. --Dirk Beetstra T C 12:54, 18 November 2019 (UTC)
Headbomb, I think you should get Edit Filter Helper rights. Guy (help!) 23:38, 30 November 2019 (UTC)
How would I even get those? Headbomb {t · c · p · b} 09:11, 1 December 2019 (UTC)
@Headbomb: Random pagewatcher butting in Request at WP:EFN. See WP:Edit filter helper#Process for requesting. AddWittyNameHere 10:13, 1 December 2019 (UTC)
@Headbomb: any admin can give them to you ... --Dirk Beetstra T C 10:45, 1 December 2019 (UTC)
@AddWittyNameHere: See Wikipedia:Edit_filter_noticeboard#Edit_Filter_Helper_request_(User:Headbomb). Thanks. Headbomb {t · c · p · b} 11:07, 1 December 2019 (UTC)
You're welcome. :) Not going to comment there because I'm not all that active regarding filters nor do I have any advanced permissions in the area (I just make the occasional request once in a blue moon and happen to have it on my watchlist as result) Means my opinion is neither particularly valued nor relevant when it comes to granting advanced permissions here, I'd assume. AddWittyNameHere 11:16, 1 December 2019 (UTC)

Preventing blank speedy contesting

  • 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. 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)

Facebook warn edit filter

  Moved from WP:EFN
 – ProcrastinatingReader (talk) 21:10, 9 July 2020 (UTC)

Providing notification of an RfC which has shown consensus for adding a warn edit filter when new editors use any Facebook URL as a source. A new edit filter will be required; this cannot be added to 869 as warnings should only be given to new editors. "New editor" is defined in the RfC as unregistered and new users under 7 days old, though I believe not-(auto)confirmed or some other near definition of "new editor" should be equally satisfactory, should there be technical concerns. ProcrastinatingReader (talk) 16:37, 8 July 2020 (UTC)

@ProcrastinatingReader: see WP:EF/R to request a filter. — xaosflux Talk 17:21, 8 July 2020 (UTC)
  • Easy enough, though step 1 is to create the warning message the users will be given. MediaWiki:Abusefilter-warning-facebook-used-as-source or something similarly named. CrowCaw 13:25, 10 July 2020 (UTC)
    • EFMs: can we get this done please; 2 months since RfC. Do we need an IA to create that page? Here's a quick filter if it helps & might speed things up. It covers external links etc too, which seems pretty standard for such filters, but I guess could be limited to within ref tags only if preferred (might take longer to exec though)
!("confirmed" in user_groups) &
equals_to_any(page_namespace, 0, 118) &
(
    fbregex := "\b(facebook\.com)|(fb\.(me|com))";
    added_lines irlike fbregex &
    !(removed_lines irlike fbregex) &
    !(summary irlike "^(?:revert|rv|undid)|AFCH|WP:TW|reFill") &
    !(added_lines irlike "\{\{(db[\-\|]|delete\||sd\||speedy deletion|(subst:)?copyvio|copypaste)")
)

ProcrastinatingReader (talk) 14:51, 13 September 2020 (UTC)

Wikileaks filter (#1034) is misleading

  • The Wikileaks filter (#1034) adds a tag 'deprecated/unreliable source' when a link to wikileaks is added. In fact Wikileaks is not deprecated (see WP:RSP#Wikileaks), so it's misleading and should be corrected. I raised it already here about a month ago but no changes have been made and no explanation of why it shouldn't be corrected has been provided. Alaexis¿question? 09:53, 23 January 2021 (UTC)
This is no longer relevant. Alaexis¿question? 11:41, 26 January 2021 (UTC)

db-u1 userpages

  • Reason: WP:VANISH suggests that "you may wish to blank or delete your user page and any subpages in your userspace. To request deletion, add the {{db-user}} tag to the top of each page" so clueless users, whose only objective is to get off the wiki, create pages with deletion requests.   Facepalm
    Other templates exist which redirect to u1 & g7 but the list above seem to be the best documented which innocent users may come across.
  • Bonus points: Directing the users explicitly to a list of pages that need deleting would be so useful, a mashup of Special:PrefixIndex/ and Special:MyPage - which unfortunately won't mashup in Wiki syntax. Mega bonus points for a tool which will allow the vanishing user to tag all their userspace pages as {{db-u1}}, and generate a random string for their "Renamed user nnnnnnnnnn" username, and file the request at Special:GlobalRenameRequest (Reason for request= request to vanish). All suggestions on how to achieve this will be gratefully received. Cabayi (talk) 15:09, 29 January 2021 (UTC)
  • How frequent is such a problem? Doing this would tag the pages into the deletion category anyway so it’s not like they go unnoticed. If it only happens rarely, say a few times a week even, it’s not worth a filter imo. ProcrastinatingReader (talk) 15:28, 29 January 2021 (UTC)
  • Agreed, this doesn't seem to rise to the level where an edit filter is warranted, and it's a self-solving problem anyway, as such tagged pages would be deleted. CrowCaw 16:30, 3 February 2021 (UTC)

Prevents users from adding mirror links

  • Task: Do not allow users to add mirror links.
  • Reason: Recently, I saw @AnYiLin remove the external link at the link to wikimirror.org . As far as I know, wikimirror.org is a mirror fork, so I propose to set up a filter to prevent users from adding links to mirror sites.--Alcremie (talk) 09:06, 3 February 2021 (UTC)
  Not done Not an edit filter issue, already implemented via the blacklist. @IN: Try following the instructions there. RandomCanadian (talk / contribs) 14:36, 3 February 2021 (UTC)

Unfamiliar language detector

  • Task: This edit filter should seek out sections/pages in other languages other than English and tag/disallow the edits.
  • Reason: I have seen quite a bit of people add sections in other languages other than English. This is the English Wikipedia, which means other languages should not be allowed to be processed, especially considering there are other Wikipediaes like this one that do other languages. This may not be used as often as other filters, but still it is an issue that so far has been unresolved. Phantasm99 (talk) 19:11, 1 February 2021 (UTC)
This would probably be too hard to implement via edit filter. It's maybe alternatively possible for the filter to check for non-latin (I'd think that already exists?) or non-english (é, è, ô, ü, ö, ä [although these have plenty of valid legitimate uses]), but I think that even if it was restricted to only non-ACs (and IPs) we'd still have way too many false-positives for this to be worth it. RandomCanadian (talk / contribs) 23:43, 2 February 2021 (UTC)
346 (hist · log) "Large non-English contributions" already warns and tags, but indeed it's really just looking for non-latin characters. Suffusion of Yellow (talk) 23:52, 2 February 2021 (UTC)
Looking at the log for that filter reveals some obvious vandals (which somehow didn't get blocked - I might see about that). And some edits which didn't get tagged, ex. [15]. A change to disallow might be warranted. RandomCanadian (talk / contribs) 00:11, 3 February 2021 (UTC)

Tag Redlinks

{{resolved}}

  • Task: Tag the addition of redlinks to DAB pages and lists by non-autoconfirmed users
  • Reason: Reduce the addition of non-notable subjects, such as [16]

I don't think such a filter currently exists, when patrolling Special:Abuselog I haven't seen any examples. Pahunkat (talk) 15:50, 30 December 2020 (UTC)

We might exempt dab entries where the red link is followed by a blue link. Editors adding them generally know what they're doing. Example: * Abra, Lebanon, a municipality of Lebanon. Certes (talk) 17:08, 30 December 2020 (UTC)
How does one identify a page is a dab/list page? Your example, Naveen, I don't see anything on this page a filter could use to identify the type of page that it is. ProcrastinatingReader (talk) 18:07, 31 December 2020 (UTC)
Most dabs end in {{disambiguation}} (or {{disambiguation|something}}) but there are many aliases such as {{dab}} and variants such as {{station disambiguation}}. There are similar but more complex clues for lists. If someone is happy to review tagged edits on a long-term basis then this could be useful for dabs, but perhaps less useful for lists or SIAs where valid entries such as HMS Nonsuch (1686) are common. Certes (talk) 19:13, 31 December 2020 (UTC)
  • Name articles, where it is somewhat common for people to add themselves, don't appear to be typically categorized as DABs. This specific case had a username adding text close to their username. There's an autobio filter that flags that pattern for article titles, perhaps it could be adapted. CrowCaw 19:35, 31 December 2020 (UTC)
Pahunkat, Regardless of whether this is a good idea, I'm not sure whether it's technically possible. If you look at mw:Extension:AbuseFilter/Rules format, there doesn't appear to be any function that checks whether a link target exists. Vahurzpu (talk) 22:22, 31 December 2020 (UTC)
Ah, that would be a problem. In that case, the best option is to stick to monitoring the current filters then. Pahunkat (talk) 12:29, 10 January 2021 (UTC)
Pahunkat, I'm not sure whether you're still interested in this, but I just came across Special:AbuseFilter/1111, which detects redlinks using a clever HTML trick I hadn't considered. The problem of determining what exactly a disambiguation page is remains, but you could probably do that in many, but not all cases, by looking for common templates. Vahurzpu (talk) 07:58, 23 January 2021 (UTC)

Flagging additions to external link sections

Task: Flag new additions to 'external link' sections

Reason: Wikipedia articles are still being targeted by linkspam, from SEO companies that don't seem to understand we use nofollow tags and website owners desperate for more traffic. The result of this is that "external link" sections can be cluttered with spam, unhelpful links. If a filter was created to log or tag these additions, it may be able to reduce the amount of spam links that remain on articles since projects like WP:WPSPAM would monitor such filters. Though some work can be done to prevent this at the blacklist, it doesn't help against hit-and-run additions.

N.B. As of now I'm unaware of such a filter (there's the "possibly spam" one, but it's private so I can't see what it does. Pahunkat (talk) 20:15, 8 February 2021 (UTC)

Excerpt/transclusion removal

  • Task: Tag edits that remove instances of {{Excerpt}} or a labeled section transclusion.
  • Reason: One thing I've noticed as excerpts have started to be applied more widely is that it's often hard to detect when someone has inappropriately removed an excerpt on a high-traffic page, because the excerpt wikicode itself isn't that long. At pages like COVID-19 pandemic, we've seen a few instances where someone will convert a section to an excerpt, and then either the excerpt will break or someone will just decide they are confused by/don't like it, and it'll get removed and sometimes replaced with a stubby section. This has a big impact on the page but doesn't show up easily in watchlists because the edit size isn't large in bytes. Trying to get those editors to use better summaries isn't likely to work as they're already jumping fences so they're not really the cautious type, so I was thinking it'd be good to have a "transclusion removed" or "excerpt removed" tag automatically applied to such edits. This would ensure that such edits have sufficient visibility to be scrutinized to the extent they ought to be given their impact. Thoughts? {{u|Sdkb}}talk 12:04, 10 January 2021 (UTC)
Anyone? I'm not sure how to interpret the silence here. Let me know if I need to clarify the request in any way. {{u|Sdkb}}talk 17:34, 5 February 2021 (UTC)
@Sdkb: I ignored it because I was hoping this guy would look at it. :-) You can speed the process by providing a few diffs, but it looks straightforward enough, and I'll try to get it soon. Suffusion of Yellow (talk) 23:13, 8 February 2021 (UTC)
Suffusion of Yellow, haha that's a good read! Here's a diff of excerpt removal and diff of transclusion removal. Note how both have a positive bytes difference, making it appear as though they're adding material when actually they're removing it. {{u|Sdkb}}talk 03:14, 9 February 2021 (UTC)
@Sdkb: Thanks. I meant diffs of "in the wild" examples, but that works too. See 1119 (hist · log). Checking all users for now, because this "feels" like a VisualEditor bug. If it turns out to be just user error or vandalism, I'll probably just check non-extendedconfirmed editors or non-confirmed. Suffusion of Yellow (talk) 18:36, 10 February 2021 (UTC)

Filter to catch russian casino userpage spambots

  • Task: To catch russian userpage spambots.
  • Reason: I come across examples of russian casino userpage spambots regularly, the most recent example being Reta878818408. However, I've noticed they follow quite a specific pattern which could be used to create a filter, which in turn may be able to be set to disallow:

They all end with the same string: "visit my webpage/page/homepage", "visit my website" or "visit my blog", followed by external link

All consist of a paragraph followed by the ending line, with two or three external links in total

All are written in Russian (usually not the ending line), and when translated will mostly contain the strings "online casino", "no deposit", "gambling".

Thoughts on this would be appreciated. Thanks, Pahunkat (talk) 12:36, 10 January 2021 (UTC)

"Visit my webpage" and synonyms sound like the sort of thing we should (and almost certainly do) disallow or at least tag when added by newcomers, even if they're not a specific unwelcome visitor. Certes (talk) 15:53, 10 January 2021 (UTC)
There's also the variant of "Feel free to surf to my webpage." The Russian version is relatively recent, a year ago most of the landing pages were Dutch. Usename constructions remain broadly consistent, two European names camelcased together, and a number. Note that there is already a filter that flags potential spam and spambots, but it's broader in scope. Acroterion (talk) 15:59, 10 January 2021 (UTC)

And more: MadonnaMonette, CharliPeltier, Annetta5902, ElvisGuerard. It also appears many of the userpages have links ending in .ru domains. I'm keeping an eye out for ones to add to the blacklist: This one has 'forum. igromania .[ru]' and 'www. 47251 .copi .[ru]' I'll update as I go along. Pahunkat (talk) 14:19, 11 January 2021 (UTC)

Edit: New variant of userpage spambots are in English but follow the same pattern: CristineSandes, CandidaBallou5. From now on I'm logging all spambots I find here. Pahunkat (talk) 10:35, 16 January 2021 (UTC)
@Pahunkat: This looks like a variant of meta:NTSAMR. I think Beetstra has more experience with those. 935 (hist · log) logs ntsamr bots, but it has way too many FPs to set to disallow. I can't see meta:Special:AbuseFilter/72, but would a variant of that that work here? Also ping Billinghurst and GeneralNotability who have update the meta filter recently. Suffusion of Yellow (talk) 18:48, 10 February 2021 (UTC)
@Suffusion of Yellow I've emailed you the meta filter 72 DannyS712 (talk) 18:52, 10 February 2021 (UTC)
@DannyS712: Thanks, I'll check it against the 935 log for FPs later. Suffusion of Yellow (talk) 19:03, 10 February 2021 (UTC)
Yup, the couple of deleted userpages I checked are textbook NTSAMR. GeneralNotability (talk) 01:10, 11 February 2021 (UTC)

  Comment: There are a number of global spam filters in place, some user ns, some broader. m:special:abusefilter/72 is targeted at user ns spam, and it is pretty effective and has a low false positive rate, and when it does, it is low impact. There is also m:special:abusefilter/169 which is aimed at non-native language casino spam outside of the native languages of the wikis. It could be brought here easily as anything non-English text relating to casinos in whatever namespace is going to be pretty irrelevant.

Another thing that is worth considering is whether forum-based based urls are relevant to user ns forums/index.php?showtopic= and similar components of urls, especially if it is a new user, or a user with less than 5 edits, or page creations.

Most of our global filters at Meta are targeting the spambots, with others generally classified as LTAs, IP main ns article dumpbots, and ego spam. Managing content at wikis is not really our bailiwick. Happy to bring over anything that you need, as none of it is that secret. Just noting that it is set up for global wikis, mostly non-English, and not overly finessed for enWP or other big wikis. — billinghurst sDrewth 20:59, 10 February 2021 (UTC)

We here also have 354 (hist · log) and 627 (hist · log) to find promotional edits in userspace / draftspace. Those are soft forms of the NTSAMR filters on meta. I think that we could easily have a stronger version of that (as in 935 (hist · log)) so that it can be blocked. Ping @MER-C:, thoughts?--Dirk Beetstra T C 08:01, 11 February 2021 (UTC)

935 has way too many FPs to disallow. I tried running meta filter 72 against the last 100 hits of 935, and unfortunately it matches almost all of them. And meta filter 169 matches almost none. Suffusion of Yellow (talk) 20:15, 11 February 2021 (UTC)
I don't know if you can see deleted pages Suffusion of Yellow (are you an admin?), but the new versions of NTSAMR have been really repetitive - more so than the ones I encountered when I first opened this. Pahunkat (talk) 12:07, 14 February 2021 (UTC)

Page-blanking filter for bots

As far as I'm aware, the only circumstances where page blanking might be appropriate are WP:G7 cases and people blanking attack pages. Occasionally a bot will misunderstand something and blank a page, e.g. https://en.wikipedia.org/w/index.php?diff=1000987634, and obviously this isn't supposed to happen, since bots won't request deletion for their own pages and can't recognise attack pages. Would it be possible and appropriate to configure the "Page blanking" filter so that it prevents bot-flagged accounts from blanking pages, and so that there's absolutely no way for the account to override the filter? I'll leave a note at WP:BON to get bot-owner attention here. Nyttend (talk) 12:50, 17 February 2021 (UTC)

PS, I'm exclusively referring to blanking mainspace pages. I can understand that there's sometimes good reason for a bot to blank other kinds of pages. Nyttend (talk) 15:33, 17 February 2021 (UTC)

If a vandal turns a legitimate blank page into an attack, Cluebot may revert by blanking, but such cases may be rare enough to ignore. Certes (talk) 16:48, 17 February 2021 (UTC)
Or implementing a whitelist for the few anti-vandal bots :) RandomCanadian (talk / contribs) 16:53, 17 February 2021 (UTC)
Cluebot uses rollback, which can't (yet) be filtered anyway. Suffusion of Yellow (talk) 16:57, 17 February 2021 (UTC)
In my view, bot bugs should be fixed by the bot operators, not using the AF or some other technical mechanism to try to second guess what the bot is doing. There are so many ways a bot could screw up it doesn't really make sense to try to account for a few cases. This isn't really a regular occurrence either, and is almost always down to bot malfunction. When identified, one can just rollback all. ProcrastinatingReader (talk) 20:04, 17 February 2021 (UTC)
It's highly probably that this is an obscure API bug, rather than a series of bot bugs. I've seen code (though I can't remember where) that checks for non-blank pages before a save, yet still resulted in very occasional page blanking. Of course checking the page after the save and self reverting if an error had occurred would be nice too. All the best: Rich Farmbrough 23:26, 22 February 2021 (UTC).

Disruptive editing: Kiev -> Kyiv

  • Task: Disallow changes from one variant to the other.
  • Reason: Disruptive editing such as this? I don't know if this is a long-term pattern, but it clearly is something easy to implement via filter. RandomCanadian (talk / contribs) 01:23, 14 February 2021 (UTC)
  • There are plenty of instances of Kiev which (according to WP:KYIV) should read Kyiv, and possibly vice versa. We should allow them to be corrected, but I think only a human can distinguish such good-faith edits from vandalism. Tag? Certes (talk) 01:36, 14 February 2021 (UTC)
I had no clue the article had been moved to Kyiv (I've only ever heard Kiev, though arguably I'm more familiar with French usage). Tagging would be an option, yes; and this could apply to other "controversial" names (the only one that comes to mind is Danzig, but there are surely others, Eastern Europe being what it is)... RandomCanadian (talk / contribs) 03:16, 14 February 2021 (UTC)
In my opinion disallow would be inappropriate (as there are many valid changes and this is a content issue). I suspect we've already survived the worst of this (which was around the time of the Kyiv RM last year). Is there really persistent disruption caused by these changes (any more than a normal content dispute)? ProcrastinatingReader (talk) 15:41, 27 February 2021 (UTC)
Well I think it should at least be tagged (possibly including other historical names, such as Danzig; ...) so that it can be verified, as some of the changes are disruptive, and they might certainly still happen occasionally. Cheers, RandomCanadian (talk / contribs) 15:52, 27 February 2021 (UTC)

AfC redirect submissions

  • Task: Notify users who attempt to submit redirects through AfC that WP:AFC/R is the correct venue for doing so.
  • Reason: Redirects, for better or for worse, are supposed to be submitted through AfC/R and not AfC. Users who aren't auto confirmed regularly don't realize this (it's not very obvious that AfC/R is the place to request these), and submit drafts that are just a redirect. A warn filter that notifies users who attempt this that AfC/R is likely the place they want to be may help reduce this.

A rough draft of the filter would probably look like this: (I can't test it sadly, at least not until T242821 is closed ;))

!"confirmed" in user_groups & /* this should potentially not be limited by user groups whatsoever */
equals_to_any (page_namespace, 118, 2) &
added_lines irlike "{{subst:submit}}|{{AFC submission\|\|" &
lcase(new_wikitext) contains "#redirect" &
new_size < 400 /* size limit may need adjusting, or maybe just removed */

Additionally, this should obviously be log-only first. Once it seems to work OK, I'll bring it up on WT:AFC and make sure there's consensus that this is an appropriate warn filter to add. Perryprog (talk) 18:24, 26 February 2021 (UTC)

I'd personally prefer to see a consensus the community wants this before implementing this filter (even as log-only - the technical implementation should be relatively trivial). ProcrastinatingReader (talk) 15:38, 27 February 2021 (UTC)
ProcrastinatingReader, sounds good; I’ll make a post in a bit. Perryprog (talk) 15:40, 27 February 2021 (UTC)

climate table color vandal

  • Task: Prevent IP users from altering the color scheme inside instances of {{Weather box}}
  • Reason: See [17] for the most recent incarnation of this long-term abuser. I can't for the life of me understand why they do this, but this has been going on for at least a year, about once a week. We've played Whack-a-Mole, we've tried range blocks, they just come back on anther IP. If we protect their regular targets they simply expand their target list. The repetitive nature of it makes them very easy to detect, but reverting and blocking clearly does not discourage them. It's quite possibly the dumbest thing I've ever dealt with here, and that's saying something. I don't know if this is technically possible but if it is, it seems like the only tool we haven't tried yet to stop this extremely tedious long-term-abuser. Thanks for your attention. Beeblebrox (talk) 06:38, 5 February 2021 (UTC)
    Seems like a good use of the filter, although probably better as log-only for a while as it seems like the kinda thing that could cause FPs. ProcrastinatingReader (talk) 17:45, 5 February 2021 (UTC)
    I guess logging would make the cost-vs-benefit more clear, but I didn't suggest it as detecting them is not the problem. I don't know how specific the EF can get, but if it specifically stopped them from either adding or removing the word "green" inside of weather boxes I would think the risk would be minimal. This is basically all that they do. Beeblebrox (talk) 18:58, 5 February 2021 (UTC)
    Beeblebrox - Is it just green? Or would they likely change colours if a filter was put in place? Pahunkat (talk) 12:14, 6 February 2021 (UTC)
    In almost all cases, it is messing with the color green. Apparently they think we shouldn't use it. Beeblebrox (talk) 18:38, 6 February 2021 (UTC)
    @Beeblebrox: See private filter 1121 (hist · log) (log-only). Suffusion of Yellow (talk) 19:41, 10 February 2021 (UTC)
    Awesome. So... what's the process? Do we wait for them to strike again and then see how many false positives were also picked up? Beeblebrox (talk) 20:01, 10 February 2021 (UTC)
    @Beeblebrox: I'll keep an eye on the filter for false positives. I usually prefer to wait at least a few days; With >100,000 edits/day, it's impossible to think of everything. Just report any false negatives here. Suffusion of Yellow (talk) 20:12, 10 February 2021 (UTC)

Sounds good to me, thanks! Beeblebrox (talk) 20:28, 10 February 2021 (UTC)

I'm suspicious about Special:Contributions/192.65.213.200. Usual green colour stuff, but also some edits like Special:Diff/1008534364. Going by their other edits, I'm guessing this data is dubious. ProcrastinatingReader (talk) 18:39, 27 February 2021 (UTC)

Common vandalism: "420"

  • Task: Would it be possible to add edits which contain "420", "69", and other common joke/vandal edit material to one of the existing filters. Set to warn or tag since this might contain false positives.
  • Reason: This kind of thing is easy to spot and keeps happening... RandomCanadian (talk / contribs) 22:19, 5 February 2021 (UTC)
    @RandomCanadian: I'm nearly certain that "42069" and "69420" can be added to one of disallowing filters (614?); I've just never got around to testing it. I doubt just 69 or 420 will be even warnable, but who knows? I'll get around to testing this soon. Suffusion of Yellow (talk) 04:39, 6 February 2021 (UTC)
@Suffusion of Yellow: Well, in some cases it is: see the immediately preceeding section with an example of a vandal edit that also contains "69"... RandomCanadian (talk / contribs) 23:05, 8 February 2021 (UTC)
  • 420 and 69 are common values for "wrong number" vandalism (example), though Crow recently implemented a filter to stop many such alterations. 42 seems to be another fun number to insert. Certes (talk) 01:19, 9 February 2021 (UTC)
    I've been trying a few different variants at 1014 (hist · log) over the past few days. Too many FPs on just 69, but "6969", "42069", "420 69", etc. look promising. Next attempt will be to check for n or more additions of either 420 or 69, anywhere on the page, but that will be hard to fit into an existing filter, except maybe 380 (hist · log). Suffusion of Yellow (talk) 02:30, 9 February 2021 (UTC)
    420.69 also seems an interesting possibility. RandomCanadian (talk / contribs) 22:08, 10 February 2021 (UTC)
    I thought of using the generic naughty word filter (380), but 69 may have too many legitimate uses for that to be sensible. A + in "\D(?:69|420)+\D" should catch 42069 etc. without causing many more false positives. Certes (talk) 00:22, 11 February 2021 (UTC)
    Here's a FP in waiting. Black Kite (talk) 00:34, 11 February 2021 (UTC)
    We may expect more legitimate uses of suspect terms from the maker of models S, 3, X and Y. Certes (talk) 00:39, 11 February 2021 (UTC)
  • This is proving trickier than it looks. 69 is just a number between 68 and 70, and it crops up a lot in sports statistics, etc. At least, I think Special:Diff/1007052384 is a legit edit. Suffusion of Yellow (talk) 22:35, 16 February 2021 (UTC)
User:Suffusion of Yellow Ah well, stopping something is better than not filtering at all and having to deal with all of it. The combined numbers [or repetitions, ex. 420420 or variants] are already a start. Cheers, RandomCanadian (talk / contribs) 23:18, 16 February 2021 (UTC)
Yes, that's legitimate: anything in the ratio 23:33 can show as 69.69% (though it should really be rounded up). Certes (talk) 23:27, 16 February 2021 (UTC)
  Done Added (?<!\d)(?:69\D*420|420\D*69|(?:69\D*){3,})(?!\d) to 614 (hist · log). That's:
  • a 69, followed by zero or more non-numeric characters, followed by a 420, or
  • a 420, followed by zero or more non-numeric characters, followed by a 69, or
  • a 69, followed by zero or more non-numeric characters, followed by a 69, followed by zero or more non-numeric characters, followed by a 69
This certainly doesn't catch everything. If the last rule causes problems, it can be changed to four or more 69s. Suffusion of Yellow (talk) 20:45, 1 March 2021 (UTC)

Prevent anonymous user to edit this page

  • Task: Prevent anonymous user to edit this page (only this page): উইকিপিডিয়া:অমর একুশে নিবন্ধ প্রতিযোগিতা ২০২১/অংশগ্রহণকারী
  • Reason: We are running an article writing contest on bnwiki. We need a filter which will prevent anonymous user to edit this page (only this page): উইকিপিডিয়া:অমর একুশে নিবন্ধ প্রতিযোগিতা ২০২১/অংশগ্রহণকারী. This filter should not affect registered user to edit the page even if their accounts are 1 second old. This filter should not affect anonymous user to edit any other pages. আফতাবুজ্জামান (talk) 22:05, 2 March 2021 (UTC)
Looking at the documentation
page_namespace = 4 & page_title == "অমর একুশে নিবন্ধ প্রতিযোগিতা ২০২১/অংশগ্রহণকারী" & user_age = 0 (with action set to disallow).
@Suffusion of Yellow: Is this correct syntax (is the difference between "==" and "=" the same as for other programming languages)? @আফতাবুজ্জামান: Tell if it works. Cheers, RandomCanadian (talk / contribs) 03:28, 3 March 2021 (UTC)
@আফতাবুজ্জামান: Or this instead? I assume that it's in the Project (Wikipedia) namespace (at least that's what google gives me); if it's project talk then the number is 5 instead. Cheers, RandomCanadian (talk / contribs) 14:58, 3 March 2021 (UTC)
@আফতাবুজ্জামান: You can use page_prefixedtitle == "উইকিপিডিয়া:অমর একুশে নিবন্ধ প্রতিযোগিতা ২০২১/অংশগ্রহণকারী" & user_age == 0. This will fail if the page is moved. Or, you can use page_id == 1017037 & user_age == 0. This will fail if the page is deleted and recreated.
@RandomCanadian: Yes, that also works, see [18] for the page namespace. = and == mean the same thing in the filter language. But in most other languages, using = when you meant == is a very dangerous mistake, so it's a bad habit to get into. Suffusion of Yellow (talk) 17:09, 3 March 2021 (UTC)
@Suffusion of Yellow and RandomCanadian: It is working. Thank you both. --আফতাবুজ্জামান (talk) 17:15, 3 March 2021 (UTC)

LTA posting a personal grievance

  • Task: Block edits containing the string 'PMOPG/E/2018/0362960'.
  • Reason: For the last 12 months or so, a person using IP addresses that geolocate to India has been posting a personal grievance every other day to articles related primarily to Delhi. All of these edits are revision deleted as they contain personal information and defamatory text. Currently, this person is hopping around in the range Special:Contributions/106.67.0.0/16 but they have appeared on other ranges. Recent examples of edits are: 25 Feb, 24 Feb, 24 Feb, 21 Feb, 21 Feb, 21 Feb, 20 Feb, 20 Feb, 18 Feb, 18 Feb. Protection and a partial block on 106.67.0.0/16 brings limited relief; they simply move to another page. The text is likely copied and pasted (they are all the same); they begin with a few insults in Hindi (or English) and then segue into 'I am a DALIT.The INDIAN LAW DID NOT HELPED ME AND CONSIDERED ME WRONG. INJUSTICE That NEVER DIE.' followed by a detailed recitation of how they have been wronged. One common feature of these edits that has appeared since at least March 2020 is the string 'PMOPG/E/2018/0362960', which appears to be a unique case number. Could a filter block edits that include this string? Thanks, --Malcolmxl5 (talk) 15:07, 25 February 2021 (UTC)
    If it's just that string, it should be relatively easy to create a filter - but they may try to evade it if it is implemented. Pahunkat (talk) 17:58, 25 February 2021 (UTC)
They cite several case numbers in their narrative that could also be used but this seems to be a key one. --Malcolmxl5 (talk) 01:32, 26 February 2021 (UTC)
I'm not an admin, but it seems easier to just range-block the offending range then implement an edit filter, although an edit filter for nonsensical strings such as that might also be helpful. 4D4850 (talk) 16:13, 26 February 2021 (UTC)
This does seem like an appropriate use of filter but discussions about LTAs are probably best done on the mailing list I imagine (not sure if this particular LTA is technically sophisticated). Perhaps also attaching the contents of the various diffs you link, as well, in the email. ProcrastinatingReader (talk) 16:21, 26 February 2021 (UTC)
I think this is related to 1022? ProcrastinatingReader (talk) 14:27, 27 February 2021 (UTC)
Created 1125 with some more identifiers from one of the log entries I can see. Some notes in the log. ProcrastinatingReader (talk) 14:42, 27 February 2021 (UTC)
@ProcrastinatingReader: Yes, it's the same vandal, and I've just made a relevant change to help tighten things up. FYI I'm not on the mailing list, but I should be able to help out a bit with this; feel free to drop me an email if you have to. -- zzuuzz (talk) 15:52, 27 February 2021 (UTC)
@ProcrastinatingReader, there is a way to see the entire text and edit summary of the revision-deleted edit in question. To maintain the integrity and secrecy of the filter, I will not say how to do so in public, but since you are an edit filter manager, I can email you the link to the edit that can be used to generate a useful filter. Do you want me to email you the edit? Steve M (talk) 03:11, 6 March 2021 (UTC)
Sure, go ahead. I have a copy of one of the relevant edits, but just one (guessing the rest are similar enough but unsure). ProcrastinatingReader (talk) 12:30, 6 March 2021 (UTC)
How is this not caught by 50? Are there some cases in which they are not shouting? It would seem like this would be pretty quickly flagged by a myriad of other general filters. Catalyzzt (talk) 15:17, 1 March 2021 (UTC)

Common vandalism: Article title in lead

  • Task: Prevent (or at least warn or log) changes to the bolded title in wikitext in the lead of an article.
  • Reason: [19] [20] [21]... Probably not the only examples one can find, and I hope its not too hard to implement (sorry for posting multiple requests, but hey: anything that doesn't need to be reverted is less to worry about...). RandomCanadian (talk / contribs) 22:32, 7 March 2021 (UTC)
    Unlikely we could warn/disallow, for the same reason we can't disallow 364 (hist · log). 364 already logs the second of your edits. I guess the filter could be modified/generalised to also log changes to the bolded name/title in the lead, however I was under the assumption that ORES caught this kinda stuff (for logging)? Presumably this stuff shows up as red in RCP / goes into Huggle etc. ProcrastinatingReader (talk) 22:42, 7 March 2021 (UTC)

AttackTheMoonNow socks

  • Task: Identify ATMN socks hounding Jesswade88 (talk · contribs), and once tested, deny editing.
  • Reason: For the past week or more a new sock has been created by ATMN each day specifically to harass Jesswade88. A filter that identifies new accounts that edit new articles created by Jesswade88 should be fairly straightforward - they've targeted her new articles within a day of their creation. See Wikipedia:Sockpuppet investigations/AttackTheMoonNow. I would make it a private filter. Acroterion (talk) 21:41, 7 March 2021 (UTC)
    @Acroterion: see 1130 and filter notes. ProcrastinatingReader (talk) 22:52, 7 March 2021 (UTC)
    • Thanks. I would agree that setting it to disallow would be a temporary last resort, but given the LTA's specific targeting of one editor on the basis of her gender and prominence as an editor, it may be useful if the abuse accelerates. The creation of a new account every day for harassment makes at least tracking useful. Acroterion (talk) 00:11, 8 March 2021 (UTC)