Jump to content

Wikipedia:Edit filter/Requested

From Wikipedia, the free encyclopedia
< Wikipedia:Edit filter

This is an old revision of this page, as edited by 67.21.154.193 (talk) at 14:20, 9 June 2022 (→Filter 1168: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

    Requested edit filters
    Shortcuts

    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-editfilters@lists.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



    Racist labeling of political leaders and historical figures

    Here are the two most recent examples:

    This has been happening for several months, perhaps back to last year. I've seen various combinations of the wording "white supremacist" and "racist " edited into political articles, both currently serving individuals and historical figures. These would be edits made after the article was already created. Not limited by geographical area, time period, living or deceased office holders. Can we create a bot that blocks these? And once created, can we update it if a new similar term begins happening? — Maile (talk) 22:40, 30 September 2021 (UTC)[reply]

    I just blocked Special:Contributions/2600:1700:12E1:A090:0:0:0:0/64 for a year as it appears every edit from there has been junk for a long time. That covers several examples of what you describe although I don't know if there are more from other IPs. Johnuniq (talk) 23:21, 30 September 2021 (UTC)[reply]
    Well, that's helpful. Thanks. I don't know if it's been this one IP or not. But I can date this phenomenon to beginning after the BLM events of the last year or two. For whatever reason, one or more editors have been motivated to label BLP and deceased individuals, or geographical areas as, racist, by one term or another. — Maile (talk) 23:59, 30 September 2021 (UTC)[reply]
    @Maile66: Started testing at 1014 (hist · log). Just checking for "racist" or "supremacist" for now. I'll add a check for biographies later. Any other words?
    FYI, I doubt this could ever be refined to the point where it's possible to disallow. Yes, all filters have false positives, but I'm worried about what message we'll be perceived as sending if we stop "X was the target of racist taunts on the field", etc. Suffusion of Yellow (talk) 22:38, 11 October 2021 (UTC)[reply]
    @Suffusion of Yellow: no other words come to mind. I keep hoping this type of editing will fade on its own, but I doubt so in my lifetime, because a lot of it is fed by national-international media reports. Not necessarily limited to the United States, or any other country. — Maile (talk) 22:44, 11 October 2021 (UTC)[reply]
    @Maile66: I added both words to 189 (hist · log) (tag-only). This is actually really common; see the log of 1014 (hist · log). I still might try to work out a disallowing filter if possible. I just don't feel comfortable with stopping Senator McSenatorface resigned after admitting to sending hundreds of racist texts...<ref><ref><ref>. It looks like we're whitewashing. So maybe I'll just disallow very small edits without refs, e.g. Special:Diff/1053952115 and leave 189 to tag the rest. Suffusion of Yellow (talk) 23:43, 7 November 2021 (UTC)[reply]
    @Suffusion of Yellow: Understood. My request here is more about the concern the past year or two of a pattern of adding blatant labeling to existing articles, usually in the opening sentences of a lead, and begin more or less, " ...(name) is a racist and white supremacist ... " without any sourcing indicating it as factual. I've never seen, "" ...(name) is a racist and black supremacist ... " Or pick any color inbetween. — Maile (talk) 23:55, 7 November 2021 (UTC)[reply]
    Well, here's one. But of course it's not as common. Suffusion of Yellow (talk) 18:55, 11 November 2021 (UTC)[reply]

    Changing height tag needs fixing

    This is from the edit history of 95.70.214.241 (talk · contribs), who appears to be a certain LTA. The height of eight athlete BLPs was changed by one or two cm. Only three of the edits had "‎(Tags: ... changing height and/or weight). Would it be possible to have all such changes tagged? It could help with wp:RCP. Thank you! Adakiko (talk) 07:31, 20 April 2022 (UTC)[reply]

    All these FNs are caused by ! ( page_title in added_lines ) in filter 391 (hist · log). Maxim, I realize I'm asking you about something from 11 years ago, but any idea what that's doing? I can't figure it out. It effectively prevents the filter from tagging any time there's already a reference on the same line with article's subject in the title. But people change referenced figures all the time. Suffusion of Yellow (talk) 21:08, 10 May 2022 (UTC)[reply]
    Hi Suffusion of Yellow. It's interesting that this question arises now, as I've been thinking about the fact that I still have the edit filter manager flag even though it feels like I last made edits to the filters roughly when I did this one, that is, 11 years ago.
    At the risk of being pedantic, the original filter didn't have ! ( page_title in added_lines ) but instead ! article_text in added_lines, which was changed by Zzuuzz in 2019 here. But, article_text and page_title have the same meaning per documentation, but the former is deprecated. I don't recall why that line was in there—it could be something as banal as thinking that article_text was something that it is not. I am fairly sure that I used a different filter as a starting point for this one; it's possible that this line was germane to the other filter, but I really don't remember what the other filter could have been, nor why the line is here now.
    I've just tested the filter with and without offending line (line 3), and that seems to pick up the untagged edits (which were not caught because the lines in question had a reference which contain the title of the article). I think the offending line can just be deleted, but I'm interested to see whether if you had any thoughts on this.
    As a final note, I find it very heartening that this filter, generally with the same rules as when it was written, is still useful after 11 years. :-) Maxim(talk) 00:03, 11 May 2022 (UTC)[reply]
    Thanks,  Done. Suffusion of Yellow (talk) 21:35, 11 May 2022 (UTC)[reply]

    pronoun changes

    • Task: changes or pronouns in articles "he" to "she", "they" to "he", etc
    • Reason: often a MoS violation when transgender BLP subjects are involved. Saw a request in the archives of the pages but with no response
    • Diffs: one example

    67.21.154.193 (talk) 15:29, 20 April 2022 (UTC)[reply]

    Previous comment: Wikipedia:Edit_filter/Requested/Archive_18#Changes_of_pronoun started by User:Valereee. No one responded 67.21.154.193 (talk) 13:52, 27 April 2022 (UTC).[reply]
    Probably something with similar logic to Special:AbuseFilter/1154 would work. Will work on this. Galobtter (pingó mió) 20:32, 2 May 2022 (UTC)[reply]
    Tamzin and Firefly already started on this, see private filter 1200 (hist · log). Suffusion of Yellow (talk) 20:35, 2 May 2022 (UTC)[reply]
    @Suffusion of Yellow Thanks for letting me know. Galobtter (pingó mió) 21:40, 2 May 2022 (UTC)[reply]
    seems to be public now and getting a good amount of hits. thx! 67.21.154.193 (talk) 13:44, 30 May 2022 (UTC)[reply]
    @Tamzin: I think there are edits in India Willoughby that have not been hit by the filter but weren't. Maybe someone should fix that? 67.21.154.193 (talk) 13:27, 6 June 2022 (UTC)[reply]

    Claiming the death of an article subject

    • Task: section titled "death". claims in general that the subject is dead
    • Reason: This filter is needed for the same reason Special:AbuseFilter/712 in needed

    67.21.154.193 (talk) 15:40, 20 April 2022 (UTC)[reply]

    Might I add that it should trip to tag if there is a ref provided, but trips to warn or something if no reference is provided. Generally this would be a filter, active on BLP articles, that trips at the addition of "foo died" or "foo [wildcard, to allow for adjectives] passed away" or similar strings. I've seen a bit of this on RC patrol. Mako001 (C)  (T)  🇺🇦 14:34, 26 April 2022 (UTC)[reply]
    The main reason I want this is to help prevent death hoaxes from appearing. If it gets overlooked early, it could end up being a while before someone notices. 67.21.154.193 (talk) 13:49, 27 April 2022 (UTC)[reply]
    so.... is there gonna be any discussion? any action? 67.21.154.193 (talk) 15:22, 2 May 2022 (UTC)[reply]
    Should I ping someone to this discussion? 67.21.154.193 (talk) 12:06, 31 May 2022 (UTC)[reply]
    I decided that I am going to ping @Ohnoitsjamie: to this page because he's quite active, and numerous sections have not had any response from EF mamagers. 67.21.154.193 (talk) 14:37, 1 June 2022 (UTC)[reply]
    I don't have time at the moment to work on that; I have written that kind of filter before; I'd want to do a lot of testing on it first as it's more complex than average. OhNoitsJamie Talk 13:57, 2 June 2022 (UTC)[reply]

    Came across deleted filter 40, but it seems like it would require significant rework if we were to revive it. 67.21.154.193 (talk) 12:44, 8 June 2022 (UTC)[reply]

    IP user rapidly reverting edits

    Would it be possible and useful to extend 249 (non-autoconfirmed user rapidly reverting edits) to IPs with this sort of editing pattern? I'd expect some newly registered accounts to do it ten times to win a prize (allow four days for delivery), but even from an IP it disruptively clogs the page histories. Certes (talk) 20:21, 21 April 2022 (UTC)[reply]

    obligatory newbie disclaimer - if anything I say here is wrong, the trout is available for extensive usage.
    The current filter is based off of edit summaries, which manual reverts aren't going to be covered by in all cases. And I'm pretty sure we can't take the tag. That's done after the filters are all done IIRC. It's not really possible to check what's happened in previous edits either, or if it is, it would be quite slow. So possible is likely a no.
    Useful? That's more debatable... how often even IS this sort of thing?
    I don't even think it's possible to check for repeated, quick edits to the same page.. or if it is, it would require a filter that trips on literally every edit by a user without the confirmed group, which sounds to me like a bad idea inherently. The "bad idea" factor is compounded by how that category of "repeated, quick edits", depending on how you define it, could easily include good faith stuff.
    I could be wrong on literally all of this, though. casualdejekyll 21:09, 21 April 2022 (UTC)[reply]
    I think (not sure, someone else might know for sure) that this filter was a reaction to a sort of vandalism where a new user or IP just "derps" all recent changes, probably using a huggle based script that also drops a ridiculous level 4im warning onto everyone's talkpage after reverting, I've seen one do something like 150 edits in under two minutes before being blocked. It already works on IPs, as IPs are not autoconfirmed. I used to get it when I did RC patrol as an IP. It's *[bleep]* annoying (and actually got me blocked once, though I never realised at the time as the IP was reallocated before I tried to edit again a few days later). The way to deal with the sort of thing you describe above though is deliver them an editing tests warning, as they shouldn't be doing tests in mainspace. Start with uw-sandbox and then test2, test3, vand4, and then AIV for a bit of time out (if they still don't get the message).
    Also, it shouldn't be too difficult to have a filter that trips for repeated, quick edits to the same page, but as you pointed out, the issue would be that it would have a massive number of false positives, or it would only catch the very fastest of bots. Mako001 (C)  (T)  🇺🇦 14:52, 26 April 2022 (UTC)[reply]
    @Certes, Casualdejekyll, and Mako001: Worth a try. It's not like it's going to take hours of fussing over a tricky regex. See 1199 (hist · log). Anyway, casualdejekyll, mostly correct. The first can't "see" tags, so there's no way to trip on exactly what that IP was doing. So I'm just logging, as you said, all non-confirmed edits that exceed a rate limit (over 8 edits in 300 seconds). If it's too spammy, it might be worthwhile to limit this to new accounts, and exclude IPs, because anyone editing at that rate is almost certainly not "new". Or, it might be worth only tagging editors who hit N different pages in M seconds. I realize that's exactly what the example IP wasn't doing, but again it's far more suspicious. Sometimes people don't use preview, and take a dozen attempts to fix their own mistakes. Suffusion of Yellow (talk) 18:45, 27 April 2022 (UTC)[reply]
    Thanks. "Of the last 1,525 actions, this filter has matched 335 (21.97%)": I hope that just means 22% of edits are by the unconfirmed, rather than 22% are rapid fire! Certes (talk) 18:49, 27 April 2022 (UTC)[reply]
    That is referring to all unconfirmed edits, @Certes. The filter has only actually tripped 1 rapid fire edit so far, Special:AbuseLog/32467726 casualdejekyll 18:51, 27 April 2022 (UTC)[reply]
    Ooh, you got a hit! An IP is systematically creating Category talk: pages. Certes (talk) 18:51, 27 April 2022 (UTC)[reply]
    Just a suggestion, but maybe the private "new account suspicious activity" filter may have something in it which could be modified to assist with this? I don't know what that filter is exactly, but I have seen it pick up on stuff like EC gaming and such, but it apparently only looks for edits by registered users. Mako001 (C)  (T)  🇺🇦 10:53, 28 April 2022 (UTC)[reply]
    @Suffusion of Yellow - Can you remove it from User and User Talk namespaces (lots of The Wikipedia Adventure)? casualdejekyll 01:17, 6 May 2022 (UTC)[reply]
    @Casualdejekyll: Yeah, limited it to mainspace and templates. Suffusion of Yellow (talk) 21:15, 10 May 2022 (UTC)[reply]

    How'd the repeat filter not catch this?

    this and this seem rather obvious instances... RandomCanadian (talk / contribs) 22:17, 26 April 2022 (UTC)[reply]

    Does the filter you had in mind (1163?) only check the article namespace? Certes (talk) 22:36, 26 April 2022 (UTC)[reply]
    @Certes: Looks like it does. Is there any reason not to extend it to talk pages, beyond the obvious "well, they get less traffic". That kind of edit is still the kind of stuff that's so universally useless that there's no point to allow it or pollute even talk page histories with it. RandomCanadian (talk / contribs) 02:33, 27 April 2022 (UTC)[reply]
    I'd say extend to everything but sandboxes, also see this for one too. If active in talk pages (at least) it would stop a good deal of nonsense. Mako001 (C)  (T)  🇺🇦 03:48, 27 April 2022 (UTC)[reply]
    I set 1163 to mainspace only because the filter catches a lot of hits, and because I haven't managed to narrow down FPs to make disallow or DatBot appropriate, it needs to be manually checked to be useful. If it gets tons of hits (due to other namespaces) I figure it will just turn into those log-only filters that never get checked. ProcrastinatingReader (talk) 11:37, 30 April 2022 (UTC)[reply]
    @ProcrastinatingReader: This probably has a really obvious answer, but would it reduce the FPs enough to disallow and/or Auto-report if another filter existed that only triggered when it repeated more than, say, six times? Mako001 (C)  (T)  🇺🇦 14:12, 14 May 2022 (UTC)[reply]

    Repeated emojis

    I'm surprised ClueBot didn't catch this edit, but seems it didn't. Could we make an edit filter for additions of repeated strings like it? {{u|Sdkb}} talk 02:51, 28 April 2022 (UTC)[reply]

    Ha, related to my report above... Are emojis also not covered by Special:AbuseFilter/1163? Two improvements for the price of one, I say... RandomCanadian (talk / contribs) 03:24, 28 April 2022 (UTC)[reply]
    It does, but that's template namespace. It would've caught that edit in mainspace. ProcrastinatingReader (talk) 11:38, 30 April 2022 (UTC)[reply]
    If it's not too expensive, most mainspace-only filters might benefit from covering templates too. Apart from oddities like Template/Did you know nominations/..., they can do more damage. Certes (talk) 12:01, 30 April 2022 (UTC)[reply]

    should we revive Special:AbuseFilter/402 with a warning message similar to MediaWiki:abusefilter-warning-AfC-unsourced-submissions?

    The filter here (for unreferenced articles) was deleted back in 2013 [1] because it apparently had no purpose. Now, a warn+tag filter exists are submitting completely unsourced afc submissions see here. I think reintrodicing filter 402 (with warn) would help against non-notable or spam creations, as well as make new users add more reliable sources.

    Also, are the above "pronoun change" and "adding death" filters going to be implemented?

    67.21.154.193 (talk) 15:34, 2 May 2022 (UTC)[reply]

    Perhaps #964 should be extended to mainspace? casualdejekyll 01:11, 6 May 2022 (UTC)[reply]

    Pinging @Tamzin: since she's an edit filter manager, and no EF manager has responded to any section below this one yet. 67.21.154.193 (talk) 13:41, 30 May 2022 (UTC)[reply]

    Expand the "poop" filter to include "poo poo"

    • Task: Stop edits adding this string, by adding it to a "disallow" filter (such as the existing "poop" filter)
    • Reason: Because the poop vandalism filter doesn't catch it, and this is quite common.
    • Diffs: [2]

    Can this string ("poo poo") be added to the ones prevented by the "poop" filter? I see virtually no legitimate use for this string in mainspace. 💩 Mako001 (C)  (T)  🇺🇦 12:20, 12 May 2022 (UTC)[reply]

    just another example. Mako001 (C)  (T)  🇺🇦 10:44, 18 May 2022 (UTC)[reply]

    Filter 1168

    should characters in the 33xx range and circled letters and numbers be included in the filter?

    67.21.154.193 (talk) 15:25, 24 May 2022 (UTC)[reply]

    see Enclosed Alphanumerics, Enclosed Alphanumeric Supplement and Enclosed CJK Letters and Months unicode blocks. Edit: also CJK Compatibility 67.21.154.193 (talk) 17:01, 24 May 2022 (UTC)[reply]
    Also some at Dingbats. 67.21.154.193 (talk) 13:18, 2 June 2022 (UTC)[reply]


    Vaguely related: are "funny" Greek letters being normalised to, er, normal Greek letters? This looks like an FP: Special:AbuseLog/32463333 (06:00, 27 April 2022: Ωχγ triggered filter 1,168). Certes (talk) 16:03, 24 May 2022 (UTC)[reply]

    It seems like the ohm symbol is now removed bc of this. This is the same filter 67.21.154.193 (talk) 17:00, 24 May 2022 (UTC)[reply]
    Yes. The Angstrom symbol, Kelvin symbol and ohm symbol all normalised to regular characters, so I had to remove them to avoid false positives. — The Anome (talk) 15:15, 8 June 2022 (UTC)[reply]

    Also:
    Change:ℬ and ℭ should have a pipe | between them. This is on the line that starts with “(accountname rlike "℀|℁|ℂ|℃|℄|℅|℆|ℇ|℈|℉…”
    Add (test for false positives by unicode normalization first): ªº (ordinal indicators), ₐₑₒₓₔₕₖₗₘₙ₊₋₌₍₎ₚₛₜⱼ (subscript), ꬲꬽꬾ (blackletter), ⁱⁿ⁺⁻⁼⁽⁾ (superscript), ⱻꜰɢʛʜɪʟɴɶʀꝶꜱʏꭥꞮꟸᶦᶧᶫᶰʶᶸ(small caps/modifier) ᶛᶜᶝᶞᶟᶠᶡᶢᶣᶤᶥᶨˡᶩᶪᵚᶬᶭᶮᶯᶱᶲᶳᶴᶵᶶᶷᶹᶺᶻᶼᶽᶾᶿꟹꭟʰʱʲʳʴʵʷˣʸꭜꭝꭞ (modifiers) ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩⅪⅫⅬⅭⅮⅯⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹⅺⅻⅼⅽⅾⅿↀↁↂↃↅↆↇↈ (roman numerals)
    (more small caps and modifiers --->) ꟲ (unicode A7F2) ꟳ (unicode A7F3) ꟴ (unicode A7F4) 𝼂 (unicode 1DF02) 𝼄 (unicode 1DF04) 𝼐 (unicode 1DF10)
    Latin Extended-F unicode block (10780-107BF; bunch of modifier letters) 67.21.154.193 (talk) 12:14, 2 June 2022 (UTC)[reply]

    Thank you. These strings are a nightmare to edit, because they break text renderering in the online editor. I'll take a look through your list and see what I can incorporate. I suspect some of these might already be caught by higher-level filters at the Mediawiki or global config level, see MediaWiki:Titleblacklist and [3], which are useful, but not comprehensive enough, as hits on Filter 1168 keeps on demonstrating. — The Anome (talk) 15:19, 8 June 2022 (UTC)[reply]
    Yeah, I think this would be better in the global blacklist, but the problem is if there are false positives, by unicode normalization, how would we know. It would also be more difficult to pinpoint which charactor exactly is causing the false positives. BTW, there are a bunch of likely problematic characters in the 2000-2bff and 1f000-1ffff range. 67.21.154.193 (talk) 14:20, 9 June 2022 (UTC)[reply]

    False GA/FA tags

    • Task: Warn when articles are created with Good Article or Featured Article tags already attached.
    • Reason: To prevent editors who don't understand GA/FA procedure from misusing the tags, and to stop malicious use of the same.
    • Diffs: Most recent one I could find (I removed the tag later): Special:Diff/1090058919

    Sumanuil. 05:48, 27 May 2022 (UTC)[reply]

    Is this a common issue? I can't imagine it happens particularly often and these kinds of non-urgent problems are likely to be picked up as part of new page patrol. Sam Walton (talk) 21:25, 30 May 2022 (UTC)[reply]
    Not sure how common, but it shouldn't be happening at all. Sumanuil. 03:10, 31 May 2022 (UTC)[reply]
    There is Special:AbuseFilter/716, but it only catches non-autoconfirmed accounts. 67.21.154.193 (talk) 12:16, 2 June 2022 (UTC)[reply]
    • Task: Use a custom warning message to notify a newer user or IP when they attempt to remove a url or ref with an edit summary including "dead url/ref/link" "404 error/message" "doesn't work" or any other string which would indicate that they are removing it because it is a wp:dead link. The message would be more friendly in tone, and would include links to guidelines about dealing with dead links, and a brief summary of those guidelines, something along the lines of "Instead of removing dead links, tag them with {{dead link}}..., try to find an archive yourself at one of these sites (add links to useful archive sites here) or, if you have an account, try using (IABot console link here)."
    • Reason: Many inexperienced users will (in good faith) remove broken links, thinking that they are of no use anymore, and not actually realise that it is a problem. Whilst "references removed" is helpful, this would be a narrower filter than that one, and is designed to offer advice and guidance to users who may not realise that their edits are possibly problematic. If alerted to the appropriate way of dealing with such links, I believe that most of these users would do so, as the responses I have got to uw-dead1 warnings whilst on RC patrol seem to be quite positive along the lines of "oh, thanks, I didn't realise I could fix that, I'll do that now".

    Mako001 (C)  (T)  🇺🇦 05:50, 28 May 2022 (UTC)[reply]

    @Mako001: That could also catch a certain spammer who replaces dead links by links to irrelevant content on a website they promote. Certes (talk) 10:55, 28 May 2022 (UTC)[reply]
    I think I've seen that one before too, though it would probably need to be more complex than the idea that I had of just "lines removed contains <ref> or </ref>" and "edit summary contains dead link/ref/page/site or 404 or link broken/doesn't work/dead". Mako001 (C)  (T)  🇺🇦 11:05, 28 May 2022 (UTC)[reply]
    @Mako001: No, the spammer uses an edit summary along the lines of "dead link". They believe (or want us to believe) that a link to their website is an improvement on a dead link. Certes (talk) 11:28, 28 May 2022 (UTC)[reply]
    @Certes: Do they ever remove the ref tags? If not then it would probably need to be a more complex filter, but the issue you are referring to would be better handled by the spam blacklist anyway (as I understand). Did you want to propose an addition there? Mako001 (C)  (T)  🇺🇦 11:51, 28 May 2022 (UTC)[reply]
    @Mako001: No, they leave everything unchanged except the URL. It's low volume and we have checks for the text they add, but if it grows then they can go on the blacklist. Certes (talk) 11:53, 28 May 2022 (UTC)[reply]
    Hmm, if that was a filter, it would have to be a separate filter then, and an LTA one too, so it'd be best to not discuss it here. My idea is to just check if the lines removed contains ref tags or http(s):\\ and has an edit summary suggesting a dead link was removed, so it wouldn't catch their sort of edits. Mako001 (C)  (T)  🇺🇦 12:03, 28 May 2022 (UTC)[reply]

    Turkey / Türkiye

    • Task: Log only: when a user changes "Turkey" to "T[u|ü]rkiye". Article namespace only.
    • Reason: Turkey has (officially) changed its name to Türkiye, however per Talk:Turkey#Requested_move_3_June_2022, the overwhelming consensus is that COMMONNAME should apply and our article remain at Turkey. There have already been a number of attempts to change the name of the country (and even to move a page) based on the new name, so it would be useful to log such changes when the RFC closes. Log only, as a minority may be valid (i.e. when the actual name of an organization includes the Turkish name). Black Kite (talk) 11:46, 4 June 2022 (UTC)[reply]
    @Black Kite: Simple initial attempt at this logging at Special:AbuseFilter/1207. Sam Walton (talk) 08:52, 6 June 2022 (UTC)[reply]
    Thanks! Black Kite (talk) 13:12, 6 June 2022 (UTC)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter/Requested&oldid=1092311972"