Wikipedia:Edit filter noticeboard

Welcome to the edit filter noticeboard
Filter 828 — Pattern modified
Last changed at 17:02, 23 January 2020 (UTC)

Filter 847 — Actions: disallow

Last changed at 19:45, 21 January 2020 (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, 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.

Click here to start a new discussion thread

Better message for LTA filters[edit]

This came out of an email conversation with Newslinger. Basically, MediaWiki:Abusefilter-disallowed may a good fit for generic vandalism filters, but it's not the right message for LTA filters. The user either (A) knows exactly what they're doing, and expects to be blocked sooner or later, or (B) has no clue why their edit was disallowed. In case (A) the threatening tone of the default message isn't going to make any difference, and in case (B) it could easily drive away a good-faith editor.

So perhaps we should have a "generic LTA" warning that completely assumes good faith? First, the default message, for comparison:

And here's a possible "generic LTA" message:

I'm not very satisfied with the wording; any suggestions or alternatives are welcome. Suffusion of Yellow (talk) 23:40, 11 January 2020 (UTC)

An LTA filter that is in any way likely to trigger a false positive should never be set to disallow. Reaper Eternal (talk) 05:38, 12 January 2020 (UTC)
@Reaper Eternal: For what value of "likely"? Should a filter that trips on literally one in a million good-faith edits be set to disallow? If yes, that's about one false positive per week, just for that one filter! In practice, most LTA filters produce the occasional FP. And we want as many of those FPs reported, or the filter won't get fixed.
I'm not, to be clear, suggesting that we use a better warning as an excuse to be sloppy. Suffusion of Yellow (talk) 06:10, 12 January 2020 (UTC)
I'm also not a great fan of the wording, but I do know of a couple of LTA filters which have caused false positives (or at least totally confusing positives) and probably will again. But I'm in two minds - doesn't the same principle apply to all filters? Don't we need to forget about LTAs and just genericise or friendly-ify the current disallow message? -- zzuuzz (talk) 07:18, 12 January 2020 (UTC)

Thanks for drafting the new message, Suffusion of Yellow. I think your proposed message is a massive improvement over the current message, since it is less aggressive toward productive users who submit edits that are caught as false positives. As you mentioned, the warning message that LTA filters (set to disallow) show to LTA users makes absolutely no difference to Wikipedia, because edit filters are not going to transform an LTA user into a productive user. At best, these filters can mitigate the damage from LTA users, and we should optimize the warning message to minimize collateral damage caused by false positives.

Zzuuzz, the expected outcomes are different for filters that target disruptive edits from non-LTA users. Assuming that non-LTA users who intentionally submit disruptive edits can be coaxed into becoming productive users (or, at the very least, less disruptive users), the current message might be more effective. When we're not exclusively targeting LTA users, I think it would be best if we reserve the current message for filters that only disallow intentional, highly disruptive edits with a very low rate of false positives. However, I don't have any data on how editors are impacted by these messages, and if we had to choose one message across the board, I would prefer the proposed version. — Newslinger talk 10:51, 12 January 2020 (UTC)

I agree with the logic behind this proposal, but my impression has always been that it's not the wording of the warning that matters, rather the visibility. People just don't read these things... so in that sense the MediaWiki:Abusefilter-disallowed might actually be better since the pink background stands out more. For instance the large font of MediaWiki:Abusefilter-unexplained-removal seemed more effective than older compact version, if I remember correctly. I did this by comparing how many times edit summaries were used on the successful save (after they saw the warning). MusikAnimal talk 04:04, 14 January 2020 (UTC)

Here are some mockups that couple the proposed wording with a red background and/or a larger font:

How are these? The heading can also be used for the templates with smaller font sizes. — Newslinger talk 14:30, 14 January 2020 (UTC)

I prefer the last one, which aligns with the pink=disallow convention. MusikAnimal talk 17:24, 14 January 2020 (UTC)
Would the last template be acceptable to you, Suffusion of Yellow and Zzuuzz? — Newslinger talk 01:53, 16 January 2020 (UTC)
Newslinger, last one is much better than the other ones. ~~ CAPTAIN MEDUSAtalk 02:21, 16 January 2020 (UTC)
Since I was asked for feedback, I'll supply it. I'm not going to stand in anyone's way here, though I'm probably still not fully on board. Visibly, the last message seems an improvement. I have some concern about saying that someone will make the changes on the user's behalf. This might be true, but it's not guaranteed, and I think a talk page message (or something else) might also be an option. As a use-case, I can't help but think about filter 847, which it's possible to trip as a false positive. The original default message mentions 'constructive', which might be useful, but I guess that goes back to my original comment in this thread. -- zzuuzz (talk) 11:18, 16 January 2020 (UTC)
@Zzuuzz: Alright, what about replacing "An experienced editor will review your changes, and make the edit on your behalf." with "An experienced editor will review your changes, and provide assistance."? Suffusion of Yellow (talk) 20:50, 17 January 2020 (UTC)
Much better, thanks. I'll leave my comments there. -- zzuuzz (talk) 20:55, 17 January 2020 (UTC)

Bumping thread. I'm away for a bit, but when I get back I have an idea for how to test this. Basically, temporarily split out one of the "busy" filters into two:

(timestamp % 2 == 0) & ( /* Original conditions here */ ) 


(timestamp % 2 == 1) & ( /* Original conditions here */ ) 

with the default warning for the first filter, and the new warning on the second. Then we can measure the results, e.g. how many users who trip each filter report to EF/FP? How many stop after the first warning? Suffusion of Yellow (talk) 19:44, 29 January 2020 (UTC)

"we" vs "you" in Abusefilter-unexplained-removal[edit]


I feel like the "we" in MediaWiki:Abusefilter-unexplained-removal comes off as a bit like talking down to the editor (reminds me of how people ask children "how are we feeling today") and might be better as "you." I'd recommend changing the first sentence to "When you remove sourced content you should provide an edit summary with a brief explanation on why you think the content should be removed." I'd also be open to wordsmithing the first part since the "you" could come off as accusatory, maybe "When you remove" -> "When removing"? Bringing it here for discussion before requesting an edit in case anyone feels differently. creffpublic a creffett franchise (talk to the boss) 18:17, 14 January 2020 (UTC)

Oops, I've been using "we" like this when giving advice to newer editors, but the pronoun is intended to refer to the Wikipedia community as a whole – which includes both me and the editor I'm talking to. Not sure what the best approach is, but "we" implies that the person who wrote the message is also subject to the same expectations. — Newslinger talk 01:02, 15 January 2020 (UTC)
Newslinger, yeah, I get that as the original intent. Looking at it a second time, I think my biggest issue is coming from "we should" - again, I get that that refers to the community, but it's reading to me like a command wrapped up in the talking-down "we." Also, the second sentence then says "you," so we should probably harmonize the two (or maybe make the second sentence impersonal - "don't interpret those removals as vandalism," perhaps). I'll spend some more time staring at it and see if I can come up with something better. creffett (talk) 02:08, 15 January 2020 (UTC)
It's possible to avoid pronouns altogether, e.g. "When removing sourced content, please provide an edit summary that briefly explains why the content should be removed. This helps ensure that other editors don't misinterpret the removals as vandalism." — Newslinger talk 07:30, 15 January 2020 (UTC)
I like that one! Will wait a little longer in case anyone else wants to comment, then will open an edit request. creffpublic a creffett franchise (talk to the boss) 14:32, 15 January 2020 (UTC)
WP:BOLDly made this section an interface-level edit request, put this section in <onlyinclude> tags, and transcluded to MediaWiki talk:Abusefilter-unexplained-removal. The edit request template is in includeonly tags, so it won't show up here. InvalidOS (talk) 15:08, 15 January 2020 (UTC)
I've reverted the transclusion, since it will simply break when this page archives. Reaper Eternal (talk) 15:12, 15 January 2020 (UTC)
Also,  Done. Reaper Eternal (talk) 15:15, 15 January 2020 (UTC)

Maintenance of MediaWiki:Abusefilter messages[edit]


while strolling across the MediaWiki namespace I've come across a number of messages that are supposedly used by edit filters, but appear to belong either to inactive filters or have been replaced or lack information about which filter applies them. In detail:

I am thinking that some of these could be deleted as no longer in use, and others might warrant having filters added. Jo-Jo Eumerus (talk) 17:44, 16 January 2020 (UTC)

Well, something's strange here - I just checked, 636 says it uses abusefilter-unexplained-removal. creffpublic a creffett franchise (talk to the boss) 17:59, 16 January 2020 (UTC)
In which case it's just a missing parameter. I'll get that updated. -- zzuuzz (talk) 18:01, 16 January 2020 (UTC)
And hey, messages should really follow the pattern MediaWiki:Abusefilter-warning- or MediaWiki:Abusefilter-disallowed- because the abuse filter interface messages also begin with MediaWiki:Abusefilter-, plus they won't get listed in the dropdowns if they don't follow this pattern. -- zzuuzz (talk) 18:08, 16 January 2020 (UTC)
Ah, okay, didn't realize that it's a manual process to update the "filters using" list. Thanks!
Separately: abusefilter-warning-local-link is indeed supposed to be used by 1016 but doesn't look like the filter was set to warn. Anyone mind adding that? Or is further discussion needed? creffpublic a creffett franchise (talk to the boss) 18:25, 16 January 2020 (UTC)
Facepalm Facepalm. @Creffett: Meant to do that a while ago, but forgot. Thanks for the ping, and  Done. Suffusion of Yellow (talk) 21:03, 17 January 2020 (UTC)
Speaking about ones I know most about, Abusefilter-disallowed-BLP is used by 1008, which I've now marked. I have found several uses for Abusefilter-warning-spambot-allowed over the years. I don't believe it's in use at this moment, but I think it was in the last year. Likewise, Abusefilter-warning-throttled (not listed) is potentially re-usable. I think I've used them both in about 3 or 4 different filters. Abusefilter-warning-malformed is no longer useful. -- zzuuzz (talk) 18:01, 16 January 2020 (UTC)
Regarding the filters of the messages that don't meet naming conventions, it seems like each associated filter has been inactive for many years. I think that deletion would be appropriate. In fact, I think most of them should be deleted save for:
Jo-Jo Eumerus (talk) 19:45, 16 January 2020 (UTC)
@Jo-Jo Eumerus: MediaWiki:Abusefilter-warning-local-link is now in use. Suffusion of Yellow (talk) 21:03, 17 January 2020 (UTC)

Anyone disagree with deleting the obsolete ones? Jo-Jo Eumerus (talk) 10:29, 19 January 2020 (UTC)

Nothing immediately jumps out, but I find this format confusing. Would it be an idea to list the messages to be deleted, or strike the messages which aren't going to be deleted? -- zzuuzz (talk) 11:39, 19 January 2020 (UTC)
Sorry, these messages: MediaWiki:Abusefilter-anon-warning, MediaWiki:Abusefilter-chartnews, MediaWiki:Abusefilter-malbot, MediaWiki:Abusefilter-vevo, MediaWiki:Abusefilter-warning-AFC, MediaWiki:Abusefilter-warning-archiveis, MediaWiki:Abusefilter-warning-dailymail, MediaWiki:Abusefilter-ANIbugnotice, MediaWiki:Abusefilter-MariaJaydHicky, MediaWiki:Abusefilter-references, MediaWiki:Abusefilter-warning-nowiki, MediaWiki:Abusefilter-warning-repeated, MediaWiki:Abusefilter-warning-short-new-article, MediaWiki:Abusefilter-warning-userpage-blanking and MediaWiki:Abusefilter-youtubefilter-warning. Jo-Jo Eumerus (talk) 14:49, 19 January 2020 (UTC)
Thanks, I've had a closer look. Again nothing immediately jumps out and I've no personal knowledge of any potential problems. However, I'd be tempted to wait for more opinions, to consider consulting with relevant editors, to double-check by scanning the filter list, and to exercise your own good judgment (and some of those filters might want a review at some point). -- zzuuzz (talk) 22:20, 21 January 2020 (UTC)
Probably best to wait, indeed. Most of the messages/filters are years old. Jo-Jo Eumerus (talk) 10:14, 22 January 2020 (UTC)

Filter disallowing usernames that end with a semicolon[edit]

There is a bug in MediaWiki (or possibly something with WMF infrastructure) that breaks path-style links to pages/users ending a semicolon. For instance, I was not able to block a vandal because all the links to Special:Block/Printf("Herro World");, Special:Contribs/Printf("Herro World");, etc. don't work. Only the query string URLs work, which is not what most links point to. This seems pretty bad... so I was bold and created Special:AbuseFilter/1023 and set it to disallow. It is showing MediaWiki:Abusefilter-disallowed-semicolon. My question is, should we expand this to do the same for page creations? Conceivably there are encyclopedic use-cases for pages ending in a semi-colon, and I don't want to prevent that. I just felt the issue with usernames was more pressing, since it's an easy exploit for vandals. MusikAnimal talk 22:41, 21 January 2020 (UTC)

What if the account was created elsewhere? –xenotalk 22:53, 21 January 2020 (UTC)
A local edit filter wouldn't stop that making m:Title blacklist the proper place to fix this. ‑‑Trialpears (talk) 23:03, 21 January 2020 (UTC)
We could check for "autocreateaccount" to prevent local accounts that were created on other wikis, but indeed the Meta title blacklist appears to be the best way to fix this. I didn't know the title backlist worked on account creations! I'll coordinate with others to get this added. MusikAnimal talk 23:24, 21 January 2020 (UTC)
FWIW, it appears we can still block these accounts via API calls and their userid - at least according to my response:
 "error": { "code": "alreadyblocked", "info": "\"Printf(\"Herro World\");\" is already blocked.", 
xaosflux Talk 23:55, 21 January 2020 (UTC)
Replied to your email; but to say it publicly, you can still block by typing the username in manually at Special:Block, or by using query parameters instead of path parameters [1] which is what I did. MusikAnimal talk 00:03, 22 January 2020 (UTC)

Filter 828[edit]

Sorry, just came across Special:AbuseFilter/828 and it was bugging me a bit. The stringy variable is declared, but then rather than using it, the content (#redirect[[) is used twice. Can an EFM either use the variable or remove it? Thanks, --DannyS712 (talk) 08:29, 23 January 2020 (UTC)

Done MusikAnimal talk 17:02, 23 January 2020 (UTC)

Change 987 to disallow?[edit]

From a discussion with Beeblebrox at Wikipedia_talk:Template_messages/User_talk_namespace#blank_edit_requests: 987 (hist · log) warns on empty edit requests, but looking at the filter's logs, we still have about one case a day where the editor ignores the warning and publishes a blank request anyway. A non-statistically-significant random sample (i.e. me examining a dozen logged actions) didn't show any false positives. Thus, I suggest we up 987 to disallow, since I can't think of any cases where a new user would actually need to post a blank edit request. creffpublic a creffett franchise (talk to the boss) 15:22, 23 January 2020 (UTC)

Hrm. If memory serves, there have been philosophical objections towards using disallowing filters for simple errors. If we do this, we obviously cannot use the MediaWiki:Abusefilter-disallowed warning. Jo-Jo Eumerus (talk) 15:29, 23 January 2020 (UTC)
I'm not personally familiar with those objections, but I get the sentiment - but at the same time, if that error doesn't serve a constructive purpose, then why allow it? As for the second concern, the filter has custom text at MediaWiki:abusefilter-warning-empty-edit-request, that could be tweaked slightly for a disallowed version. creffpublic a creffett franchise (talk to the boss) 15:43, 23 January 2020 (UTC)
@Creffett: I'm not sure disallowing the good-faith edits is a good idea. What about, if the edit was the last one to the page, removing the edit request automatically by bot? Less BITEy to the user posting it than disallowing. Just an idea DannyS712 (talk) 17:11, 23 January 2020 (UTC)
DannyS712, I like that idea, agreed that it's less bitey. creffpublic a creffett franchise (talk to the boss) 17:20, 23 January 2020 (UTC)
Interesting, I had no idea there was filter for this. If I had to guess I would theorize that people doing this have a fundamental misunderstanding of what an edit request is, they think they are asking for permission to edit the page through the protection or something like that. They obviously aren't reading and understanding the protection policy or the procedure for requesting an edit. But they probably are acting in good faith, just uninformed good faith. I like the idea of removing it, in particular if it creates a notification that the user will see telling them why it was removed. Beeblebrox (talk) 19:14, 23 January 2020 (UTC)
@Beeblebrox: To simplify the bot coding, I propose:
  1. Add a tag to edits made
  2. Query pages where the most recent revision has the tag
  3. Grant the bot rollback (don't need to figure out "undo" actions)
  4. Use a custom summary for the rollback (i.e. the notification will link to the edit, which will have an explanation)
  5. Specify a user for the rollback, to avoid potential edit conflicts
Thoughts? DannyS712 (talk) 19:19, 23 January 2020 (UTC)
So how about this for a bot:
  • every $interval, bot pulls all pages with open edit requests
  • for each page in pages_with_edit_requests:
    • if edit_request is empty and edit_request is most recent edit:
      • delete empty edit request
      • post friendly note to user's talkpage
I can code that up pretty quickly if you all like it and put in a BRFA for a new creffbot task.
Actually, what would be really helpful for that is if we could tag the edit as well as warn, then the bot can just look for new edits with the tag since it last ran. creffpublic a creffett franchise (talk to the boss) 19:21, 23 January 2020 (UTC)
Ha, I see DannyS712 had the same idea. If you want to write it, task is all yours. creffpublic a creffett franchise (talk to the boss) 19:22, 23 January 2020 (UTC)