Jump to content

Wikipedia:Edit filter noticeboard

From Wikipedia, the free encyclopedia
"WP:EFN" redirects here. For information on the {{efn}} template, see WP:EXPLNOTE.
    Welcome to the edit filter noticeboard
    Shortcuts
    Filter 614 — Pattern modified
    Last changed at 01:05, 3 February 2026 (UTC)

    Filter 1283 — Actions: throttle

    Last changed at 23:24, 31 January 2026 (UTC)

    Filter 887 — Pattern modified

    Last changed at 03:31, 30 January 2026 (UTC)

    Filter 890 — Pattern modified

    Last changed at 03:31, 30 January 2026 (UTC)

    Filter 1147 — Pattern modified

    Last changed at 03:32, 30 January 2026 (UTC)

    Filter 54 — Pattern modified

    Last changed at 21:59, 29 January 2026 (UTC)

    This is the edit filter noticeboard, for coordination and discussion of edit filter use and management.

    If you wish to request an edit filter or changes to existing filters, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives.

    Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters.

    There are currently 367 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1030, out of a maximum of 2000. (Purge).

    Click here to start a new discussion


    Emoji vandalism missed by emoji filter

    [edit]

    Special:Diff/1325372991 at Issam Nabahin (now RD3'd) used colored block emojis, which are not in the Special:AbuseFilter/680, to make a Pepe the Frog ASCII art. These are U+2B1B–2B1C (⬛⬜) and U+1F7E5–1F7EB (🟥🟦🟧🟨🟩🟪🟫). A use of the emoji version of U+26A0 ⚠️ WARNING SIGN was also missed. –LaundryPizza03 (dc̄) 21:27, 3 December 2025 (UTC)[reply]

    Also (in order of Unicode point): ▪️▫️◻️◼️◽️◾️⚪️⚫️❤️💙💚💛💜🔴🔵🔶🔷🔸🔹🔺🔻🟠🟡🟢🟣🟤🤍🤎🧡🩵🩶🩷, and possibly 🔲🔳. –LaundryPizza03 (dc̄) 21:38, 3 December 2025 (UTC)[reply]
    No, wait, probably the filter did catch the ⚠️, but not the colored blocks. –LaundryPizza03 (dc̄) 06:59, 5 December 2025 (UTC)[reply]

    I've edited the filter to add the two ranges U+2B1B–2B1C and U+1F7E5–1F7EB. We should probably think about widening these ranges; for example, the latter range belongs to the block Geometric Shapes Extended, which consists entirely of wingdings-like characters. — The Anome (talk) 13:55, 15 December 2025 (UTC)[reply]

    Perhaps we could start with readjusting the current blocks for Emoji; if done correctly, there should be no outliers (e.g. U+1F6FA 🛺 AUTO RICKSHAW is not in the current filter). There could also be a rule for U+FE0E and U+FE0F (e.g. ⏳ → ⏳︎ and ⚠ → ⚠️), which are both useless for anything but emoji and avoids unnecessary hassle from trying to deal with emoji variants of actually useful characters such as © (→ ©️). –LaundryPizza03 (dc̄) 17:26, 15 December 2025 (UTC)[reply]
    I'm working on this at User:LaundryPizza03/filter 680. –LaundryPizza03 (dc̄) 18:57, 15 December 2025 (UTC)[reply]
    Hey there. I just reverted [1], which is the second time I've reverted an emoji this week (I don't know when the first time was). Just thought I would let you guys know. win8x (talk) 23:08, 17 December 2025 (UTC)[reply]

    Edit distance/fuzzy matching

    [edit]

    We have an LTA that is trying to get round filters by just changing a few letters of their chosen identity. Specifically, getting around Special:AbuseFilter/1395. Do we have some sort of edit distance-based metric or fuzzy matching algorithm we can use here? Ccnorm is not sufficient. — The Anome (talk) 22:47, 14 December 2025 (UTC)[reply]

    Unfortunately, not yet; see phab:T274062. Suffusion of Yellow (talk) 23:42, 14 December 2025 (UTC)[reply]
    That's annoying. The trigram version of that would be very effective in this case. I guess I can code up a program to produce a huge brute-force set of regexes that might approximate this somehow, but that's not a good use of anyone's resources. — The Anome (talk) 14:05, 15 December 2025 (UTC)[reply]

    Set 1389 (hist · log) to tag or warn

    [edit]

    1389, the filter that logs edits where someone removes a declined block request, has been working well for over a month now. I would like to get everyone's opinions before setting to tag or warn (if we warn, we would have to also create a custom warning message of course). Courtesy ping to @Pppery: for initially requesting this filter at EFR. – PharyngealImplosive7 (talk) 14:49, 18 December 2025 (UTC)[reply]

    How is the false negative rate? I would actually be in favor of settings this to tag-only then doing away with the WP:KEEPDECLINEDUNBLOCK rule entirely, or at least softening it to something like "you must restore any declined unblock requests before requesting again." It would then be the responsibility of the reviewing admin to check for any tagged edits. The unblock template could even include a convenience link to the tagged edits, wrapped in sysop-show.
    WP:KEEPDECLINEDUNBLOCK is frankly a punitive rule and even if we keep it, we should not be creating more technical measures to enforce it. Accept your fate? Great, blank your talk page per WP:NOTWALLOFSHAME and move on. But dare to question the block? Now there's a page, possibly titled after your real name (or a name easily traceable to you), that's up here forever. Where someone calls you "incompetent". For something you did ten years ago, when you were twelve. At least a human might recognize this, and not revert per IAR. But a filter cannot. Suffusion of Yellow (talk) 19:18, 21 December 2025 (UTC)[reply]
    I'm not sure about the exact false negative rate (because I haven't checked recent changes to monitor for any missed edits). Regardless, the false negative rate still shouldn't be too high because of how the filter logic is structured (unless I'm missing something). As for the policy, I understand the concern, which I guess might be why tagging is preferable to a stronger action? – PharyngealImplosive7 (talk) 01:05, 22 December 2025 (UTC)[reply]
    Yes, no objection to tagging. Suffusion of Yellow (talk) 19:06, 26 December 2025 (UTC)[reply]
    I largely concur with SFR, agree with tag but adding more and more technical measures to enforce punitive rules is somewhat a waste of resources. EggRoll97 (talk) 22:52, 31 December 2025 (UTC)[reply]
    I have no objection to allow the filter to tag such removals of declined unblock requests. Codename Noreste (chat) 00:37, 2 January 2026 (UTC)[reply]
    As it seems that the consensus is for tagging, I've set 1389 to tag. – PharyngealImplosive7 (talk) 06:00, 4 January 2026 (UTC)[reply]

    New option for oversight-level filters introduced to some, if not most wikis

    [edit]

    Per T290324 and per mw:Extension:AbuseFilter/Access flags, there is a new option to suppress filters (and their logs) so that they can only be seen by oversighters and those in global user groups with the viewsuppressed user right. Please note that suppressing filters will require the suppressrevision user right.

    On January 8 (UTC-6), the feature will (soon) be introduced to Group 2 wikis, including the English Wikipedia. Codename Noreste (chat) 05:59, 8 January 2026 (UTC)[reply]

    Just to note, it's now there. Codename Noreste (chat) 21:06, 8 January 2026 (UTC)[reply]
    Thank you for the updates. Do we plan to test/implement this new tool on any filters? - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 14:20, 9 January 2026 (UTC)[reply]
    For now, I'm not sure. Codename Noreste (chat) 19:03, 9 January 2026 (UTC)[reply]
    There are a number of filters that will likely be "upgraded" to use this option; we have an OS candidate right now who will likely lead that charge, but as soon as I get time to remember which are the "naughty" filters I'll probably help out as well. Primefac (talk) 23:42, 9 January 2026 (UTC)[reply]
    It would be a good idea to do some testing with an experimental filter before migrating any existing filters. We may also need to figure out how to handle reporting since DatBot won't have access to oversight-level filters unless there's already an oversighter solution. Daniel Quinlan (talk) 08:35, 10 January 2026 (UTC)[reply]
    Unless ArbCom is willing to make an oversight bot, I doubt any reporting could really be done. And really, would anyone even want reporting to be done on filters that should likely have less attention called to them than more? EggRoll97 (talk) 02:22, 13 January 2026 (UTC)[reply]
    Yes, it would require an oversight bot and a reporting destination specific to oversighters. Daniel Quinlan (talk) 02:31, 13 January 2026 (UTC)[reply]
    Ok, some questions that should be answered before anyone creates any oversight-level filters:
    • Is setting a filter as OS-restricted a reversible action?
      • If so, what happens to any hits that were manually oversighted in the past? Do they become visible again?
      • If not, is there a very clear "Are you sure?" prompt?
    • What information from oversight-level filters is public? The title? The hit count? Do non-detailed hits appear at Special:AbuseLog or other less obvious places?
      • If hits don't show up anywhere public, how will we handle false positive reports? There will be no easy way for non-oversighters to distinguish nonsense reports from legitimate ones, if the filter log is just empty
      • If they do show up somewhere public, should OS filters bet set to anything other than disallow? The filter hit might draw attention to the corresponding "live" edit.
    Suffusion of Yellow (talk) 20:27, 14 January 2026 (UTC)[reply]
    Your first question should definitely be answered before we restrict any filters, especially existing filters. I've applied for the suppress permission group on test.wikipedia.org to do some preliminary testing. Daniel Quinlan (talk) 21:15, 14 January 2026 (UTC)[reply]
    I ended up starting my testing on a different instance because CU/OS rights are difficult if not impossible to obtain on test.wikipedia.org. Here are some preliminary answers to your questions.
    General:
    • Setting a filter as suppressed is reversible. (There's no extra prompting.)
    • The available actions are exactly the same as other filters.
    • Suppression of a filter and its logs is all or none.
      • If the suppression box is checked, the filter and every past log is suppressed (including hits that happened when the filter was not suppressed).
      • If the suppression box is unchecked, the filter and every past log are not suppressed and are visible.
    • Suppressed filters are displayed in Special:AbuseFilter filter list and all information is displayed except for the number of hits.
    More on AbuseLog and edits:
    • Suppressed filter hits do not show up in Special:AbuseLog at all except for oversighters.
    • If a non-oversighter tries to view a specific log entry that's suppressed, they get a "You do not have permission to see details of this entry." message. This differs from the "An entry with the provided ID does not exist." message received for log IDs that don't exist yet.
    • There is no indication in recent changes or the page history when a suppressed filter triggers.
    More on filter history:
    • Changes to suppressed filters do show up in Special:Log.
    • The history of suppressed filters is not viewable by non-oversighters.
    • If a previously suppressed filter is unsuppressed then only the versions of the filter that were unsuppressed can be viewed by non-oversighters. Viewing a diff between filter versions requires that the user has permission to view both versions being compared.
    Daniel Quinlan (talk) 23:37, 14 January 2026 (UTC)[reply]
    As for your second question, mediawikiwiki:Extension:AbuseFilter/Access flags says all abuse log entries associated with the filter are effectively automatically suppressed and do not require intervention from a human suppressor, so I believe the answer to that would be that no log entry would even appear to non-oversighters. This seems...not ideal. Though I'm aware of the reasoning behind it just not appearing at all, it seems less obvious to those handling false positive reports than, say, an oversighted revision would be on a page history, where it still shows that a revision exists, just not any details about it. EggRoll97 (talk) 23:24, 14 January 2026 (UTC)[reply]

    New account type variable and accountname to be deprecated

    [edit]

    I am announcing this per phab:T414049 and on behalf of Dragoniez.

    There will be a new filter variable, account_type, which will be used to determine the account type being created in the autocreateaccount and createaccount actions. In addition, accountname will be renamed to account_name, and the former (accountname) will be deprecated soon. Any filters that use accountname will need to be updated soon to use the new variable. Thanks. Codename Noreste (talk • contribs) 15:08, 20 January 2026 (UTC)[reply]

    The change will be deployed to production on Thursday, January 29. I'm going to update mw:Extension:AbuseFilter/Rules format around this time, but the available values for account_type will be named, temp, or unknown. Note that migrating to account_name isn't urgent, although accountname will be highlighted in orange to indicate deprecation in the filter editor. Dragoniez (talk) 17:08, 20 January 2026 (UTC)[reply]
    EggRoll97 and PharyngealImplosive7, accountname is now deprecated and should be replaced accordingly. Suffusion of Yellow, you might want to update FilterDebugger because account_name is the new variable and you also want to add account_type (the type of account being created with either using named, unknown, or temp). Codename Noreste (talk • contribs) 23:53, 29 January 2026 (UTC)[reply]
    @Codename Noreste: accountname in all filters should be replaced with account_name – PharyngealImplosive7 (talk) 03:36, 30 January 2026 (UTC)[reply]
    Seen, Codename Noreste, though it appears PI7 beat me to the punch here. I'll work through the other wikis to replace the deprecated variable when I have some time. EggRoll97 (talk) 07:51, 30 January 2026 (UTC)[reply]
    @Codename Noreste: Already done. Suffusion of Yellow (talk) 18:57, 30 January 2026 (UTC)[reply]

    Edit not picked up by filter 1112

    [edit]

    Anyone know why this edit wasn't picked up by 1112? Aydoh8[what have I done now?] 13:05, 31 January 2026 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=1335832840"