Jump to content

Wikipedia:Edit filter noticeboard/Archive 5

Add links
From Wikipedia, the free encyclopedia
Archive 1←Archive 3Archive 4Archive 5Archive 6Archive 7→Archive 10

Edit filter helper right for Winged Blades of Godric

 Done For those commenting on the "private" aspects please keep in mind that these filters are private in that the details of what they filter on are not made public, however they do not deal with personal 'privacy' information - all of the actions that they trigger on are things disclosed publicly by editors. Filters have 0 visibility to readers, to checkuser data, or to suppressed edits. — xaosflux Talk 12:58, 1 December 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Uncontested closure has started. (refresh)

Well, I've occasionally helped out at WP:EF/FP/R for the past few months and for now, have taken an interest in helping out at WP:EF/R a bit , for which I am currently exploiting my sysop-rights at test-wiki.

Very yesterday, I was designing an EF to tag addition of DS-Notices on article-t/p by non-admins, today another one to restrict the vandalism on Donald Trump (which included some weird experimentation, to check the various variables:( ) and a few days back, another to guard-wall against a promo-sock-ring.

But, it's often very necessary to look at details of private-filters, to take ideas and further develop the language.

I do not claim any extreme competency in regex/abuse-filter framework but have a fair idea of both.

I understand the importance of account security, (esp. in light of the recent saga) and have 2FA enabled. I further understand the necessity of not discussing certain filters anywhere except private correspondence between equi-trusted folks. ∯WBGconverse 13:06, 25 November 2018 (UTC)

Incidentally, I see that it was me who closed the RFC for the creation of this group! ∯WBGconverse 13:06, 25 November 2018 (UTC)
  • I don't have anything to add about EFH, but WBG and I have an understanding about that incident and I have no doubt he's able to handle confidential information in an appropriate manner. That's all I'm able to say about it. Katietalk 11:51, 29 November 2018 (UTC)
  • LC, this's going into definite harassment territory. Following me around, after I criticized your behavior at Rschen's t/p. FWIW, I know Atsme quite well-enough and the self-redaction was minutes later; something with which she did not have any problem.
  • At any case, taking cues from Bishonen's post and the wise words of Ehrmann, I will let you have the pleasure of having the last word. Ta. ∯WBGconverse 11:22, 1 December 2018 (UTC)
  • For the record, I asked a question in the RFA at 12:18 GMT, automatically placing the RFA on my watchlist. Your first edit and subsequent inappropriate redaction took place sometime LATER. So not following you at all. Correct reading of WP:REDACT does NOT make it ok if someone involved "has no problem with it" - it is for benefit of wider community that edits are not removed, not to cover up your error of judgement. Leaky Caldron 11:32, 1 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How do I request a filter be added to a page

Reading WP:LISTPEOPLE, it seems like the article List of LGBT YouTubers should have filter {{Editnotice for lists of people}}. Where do I go to request it be added? Mathglot (talk) 07:36, 3 December 2018 (UTC)

Mathglot, that isn't a edit filter but a WP:EDITNOTICE; I've created it for you. As a page mover you should see a red linked "Page notice" in the top-right corner when editing a page; creating that page with the template will add the edit notice. Galobtter (pingó mió) 07:49, 3 December 2018 (UTC)
Galobtter, thanks on both counts! Mathglot (talk) 07:57, 3 December 2018 (UTC)

384 false positives

These obviously aren't my edits so I can't properly submit them to the false positives page, but these edits were tripping filter 384 for no obvious reason and caused an erroneous report to WP:AIV/TB2. Figured somebody more competent than me should have a look at them... Home Lander (talk) 20:27, 13 December 2018 (UTC)

Oh, this is caused by LOL in the edit summary. IMO, this should be removed from the filter. -- zzuuzz (talk) 20:33, 13 December 2018 (UTC)
(edit conflict) @Home Lander: It's the LOL in the edit summary, which is actually a very common cause of FPs. I'm beginning to wonder if 384 should be split into two filters; one for article content and one for edit summaries, so each can have its own rules. I suspect that an edit summary consisting entirely of "LOL" is a strong indication of vandalism, while a long summary containing a "LOL" somewhere in the middle may not be. But without a separate log I don't really know. Suffusion of Yellow (talk) 20:37, 13 December 2018 (UTC)
Suffusion of Yellow and Zzuuzz, didn't even think to look at the edit summary. Thanks. Home Lander (talk) 20:43, 13 December 2018 (UTC)
Pinging Cyberpower678 who added the edit summary check to 384 back in June, and MusikAnimal, who will probably have something to say about wasting conditions just for the convenience of two logs. Suffusion of Yellow (talk)

Permissions question

I would like to become more involved in edit filters. Is it possible to obtain permission to read them without permission to change them?

Here is my issue; I am an expert in assembly language programming, and can find my way around C programs and regular expressions, but of I know nothing about writing edit filters. I would like to learn by watching what others do.

I believe that I can be trusted (40,000 edits over 12 years with no blocks or other sanctions), so if we can't turn on reading without turning on changing, I could just voluntarily refrain until I feel I am ready. --Guy Macon (talk) 14:57, 19 December 2018 (UTC)

@Guy Macon: most filters conditions are public, you can just go to Special:AbuseFilter and start clicking away, the entire interface is read only unless you are in the "edit filter managers" access group. If you want to read the "private filters" you can request (here) access to the edit filter helper access group. Does this answer your question? — xaosflux Talk 15:08, 19 December 2018 (UTC)

167 ("Botched submissions to Articles for creation") should be in the Draft namespace

I noticed that 167 looks at the Wikipedia talk namespace; however, that namespace has been deprecated for use in AfC, and should probably be changed to ns #118 (Draft). Enterprisey (talk!) 05:25, 24 December 2018 (UTC)

Allow 2FA setup for all edit filter helpers

I was thinking of requesting 2FA over at meta, but it occurred to me that it might make more sense to add the oathauth-enable right to the abusefilter-helper group, so any EFH can set up two-factor authentication, if they wish. It's not a very large group there is potential for silent damage from compromised accounts. Does this seem like a good idea? Suffusion of Yellow (talk) 20:45, 19 December 2018 (UTC)

Its too small to matter, you can just ask at meta:SRGP. — xaosflux Talk 20:57, 19 December 2018 (UTC)
Suffusion of Yellow, A community wish-list proposal about implementing 2FA for all concerned users has made it to the top 10. So, this'll be likely moot in a year. ∯WBGconverse 08:25, 24 December 2018 (UTC)

EFH right for Username Needed

 Not done due to lack of consensus for access. — xaosflux Talk 18:48, 31 December 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)
Username Needed (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

I often find myself hanging around at EFN, EFR and EFFP and think I could help out, but I am not sure that I feel safe with applying for the EFM right until I know more about the process of how edit filters are made and constructed, and I feel that EFM right for me would be opposed anyway right now due to lack of experience. — Preceding unsigned comment added by Username Needed (talk • contribs) 10:14, 17 December 2018 (UTC)

It doesn't look like they're actually asking for the right, but rather just sharing their inner thoughts? Natureium (talk) 18:46, 17 December 2018 (UTC)
It looks like they're saying they are not applying for EFM but are applying for EFH? Galobtter (pingó mió) 18:47, 17 December 2018 (UTC)
re: Natureium, If you take the heading into consideration, you can see it from my perspective. Galobtter echoes how I understood the post. Nonetheless, after second reading I agree the post is equivocal, I didn't thought it that way. –Ammarpad (talk) 19:33, 17 December 2018 (UTC)
  • I think that EFH would make me able to respond to EFFP posts where there is a private filter and maybe be able to gain some experience with filters so that I can re-apply for EFM at a later date. [Username Needed] 10:03, 18 December 2018 (UTC)
  • Concerns. Since its showing 11h till "earliest close" and I'm not sure if I'll be on in time, I'm just leaving this here for now. I have concerns over the need here. By my count you've made 9 edits to the False Positives page, some of which were cleanups, DENY removals, etc. I'd say get more experience there with deconstructing FP reports on the public side, and feedback at the requests page. I see you active all over the place, which explains the edit distribution somewhat, but there's plenty to do outside of the private filters. CrowCaw 22:44, 19 December 2018 (UTC)
  • Oppose for now. I would like to see more experience, both at filter-related venues and the project as a whole, before granting access to view private filters. As it stands now I don't see a demonstrated need for it. — MusikAnimal talk 23:35, 19 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Abusefilter blocker account

Tracked in Phabricator
Task T212268
Edit filter (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

Hello all, as we are not using the abuse filter blocking action (it is not enabled here) the MediaWiki:Abusefilter-blocker defined account does not require sysop access. I am removing this access as it is causing some confusion in reports, etc. This is likely going to be changed to a new system service group in the future, see phab:T212268 and it's related tasks for follow up. — xaosflux Talk 14:32, 3 January 2019 (UTC)

I thought this was taken care of

 Done. ~Oshwah~(talk) (contribs) 13:07, 19 December 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I was told that an edit filter now prevents edits like this one:[2] Could someone please check and see whether the edit filter exists, and if so whether it is working correctly? Thanks! --Guy Macon (talk) 23:08, 18 December 2018 (UTC)

@Oshwah: think this is something you were working on in filter 51. — xaosflux Talk 23:57, 18 December 2018 (UTC)
Well crap... I took it out of my edit filter earlier today because I didn't see that this was getting any hits at all lately. I'll put it back in right now - stand by... ~Oshwah~(talk) (contribs) 23:59, 18 December 2018 (UTC)
Never mind; I was thinking of a different condition. This is already in my edit filter (51) as both an edit summary and a content hit condition. However, my filter simply flags events - it doesn't disallow them. I'll take a look at 874, 579, and a few others and see if it's on any of those... ~Oshwah~(talk) (contribs) 00:03, 19 December 2018 (UTC)
It really should be prevented, not just flagged. He has been at this for years, and there is an obvious text string which is very unlikely to come up in any other context. --Guy Macon (talk) 02:01, 19 December 2018 (UTC)
I agree. ~Oshwah~(talk) (contribs) 12:55, 19 December 2018 (UTC)
 Done. Condition has been added to Special:AbuseFilter/885 and tested as working. Edit summaries or edit content adding this LTA username will be disallowed. ~Oshwah~(talk) (contribs) 13:06, 19 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Ha! [3] (deleted in the same minute it was posted. :) --Guy Macon (talk) 20:26, 3 January 2019 (UTC)

IRC feed of all edit filter hits

Hello! I have long wanted real-time notifications of when specific filters are hit. Sometimes you want to take administrative action immediately. So, I authored an IRC bot task to relay all filter hits to #wikipedia-en-abuse-log-all connect. You can subscribe to filters so that the bot will send direct messages to you when the filter is tripped. This is especially helpful if you have a mobile IRC application (such as IRCCloud), so that you get push notifications. Documentation is at User:MusikBot/AbuseFilterIRC.

You may already be aware of #wikipedia-en-abuse-log connect which is a feed of filter activity detected by DatBot, as specified by User:DatBot/filters. This new feed is sort of a complement to that, allowing you to privately subscribe to filters. I am unsure if we should combine forces and have the two bots share the same IRC channel. Pinging DatGuy for input.

I hope others find this useful! — MusikAnimal talk 05:25, 2 January 2019 (UTC)

MusikAnimal, quite helpful, thanks! Galobtter (pingó mió) 08:23, 14 January 2019 (UTC)

EFH right for DannyS712

 Not done @DannyS712:, a consensus to support your request did not emerge - closing without account action. You are welcome to assist at WP:EF/FP, as most filters are not private. — xaosflux Talk 14:31, 17 January 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

DannyS712 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

Hi. Recently, I've taken to helping out responding to complaints about false positives, and I realized that in a not-insignificant number of cases I can't tell what the attempted edit even was because the filter was private. I'd like to be able to help out as well as better understand how specific (private) edit filters work. Accordingly, I'd like to request to become an "edit filter helper". As for the criteria:

  1. Demonstrated need for access - I want to help with false positives as well as learn more about how filters conditions can be best applied (Special:AbuseFilter/test is only available to users with the right to view private edit filters or modify filters may use this interface.)
  2. No recent blocks or relevant sanctions - I've never been sanctioned or blocked directly (I was once caught in an autoblock of a less-pro-wikipedia family member of a few weeks after joining, but that's it)
  3. At least basic understanding of account security - I believe that I meet this requirement, and if granted this right I'll look into whether I should also use 2FA
  4. At least basic understanding of regular expressions if the intent is to assist with authoring filters - for now I don't intend to be authoring filters, but access to the test interface would be helpful in developing my regex skills - I have a "basic" understanding, but not an advanced one
  5. Sufficient ability with the English language to understand notes and explanations for edit filters - English is my native language
  6. Currently-active extended confirmed editor on the English Wikipedia (i.e. the user has made edits or logged actions within the last 12 months) - checkY

Accordingly, I hope that you'll consider allowing me to help with edit filters. I'm happy to answer any questions people have --DannyS712 (talk) 09:31, 13 January 2019 (UTC)

  • Support ―Abelmoschus Esculentus (talk • contribs) 03:54, 15 January 2019 (UTC)
  • Oppose Not a demonstrated need, not been here enough, unsustainable rate of edits, too soon. --QEDK (後 ☕ 桜) 11:46, 16 January 2019 (UTC)
    @QEDK: Can you explain what you mean by "unsustainable rate of edits"? --DannyS712 (talk) 16:12, 16 January 2019 (UTC)
  • Hi Danny, you're doing good work – keep it up! I would suggest giving it a few months and coming back here if you're still interested in EFH. This isn't a formal "oppose", but I'd also personally be more comfortable with a bit more experience. Also, do you by chance have a CS background or any related training or experience? If so, I'd recommend you mention it in your next EFH application. Best, Kevin (aka L235 · t · c) 18:16, 16 January 2019 (UTC)
    @L235: I do have a CS background - I've been coding for years, and here on wikipedia I've been working on user scripts. A list of the scripts I've made is available at User:DannyS712/Scripts. Specifically, I've been increasingly working on learning regexes, as seen in my as-of-yet unpublished beta User:DannyS712 test/chance.js. Also, for your note about experience, if you want more information about my specific CS activities in the past I'd be happy to email you. Thanks, --DannyS712 (talk) 19:46, 16 January 2019 (UTC)
  • Oppose per QEDK. Nihlus 19:48, 16 January 2019 (UTC)
  • General Comments Looking back at the EFH proposal, the bar for Demonstrated Need was intended to be set quite high; I believe it was said that only a handful of editor would ever get this, so it's not like other permissions where having it allows one to help out in various areas. While your help at EF/FP is greatly welcomed, the "I want to help with FPs" comes in below that bar in my opinion. Not only that, but (and if I'm misunderstanding, I apologize in advance) it sounds like one of the reasons you want this is for access to the test interface as a learning tool. I realize it is a bit of a Catch-22 but that seems analogous to running for RFA in order to learn how to use the admin toolset. I'm not sure what to suggest for moving forward, other than to keep doing what you're doing, and at some point if the lack of this access becomes a net negative, then there's likely that Demonstrated Need. CrowCaw 22:47, 16 January 2019 (UTC)
    @Crow: The "I want to help with FPs" is just a part of it. I first realized the benefits of this right after this discussion, where I realized that, given my cs background, I might be able to modify the relevant filter to not tag edits where the external link was included as part of a template. Then, while I was helping at EF/FP, I realized that frequently I just can't see what the attempted edit even was, so clear cases of false positives, or clear intended vandalism, would have to wait for longer than when the filter was public. I'd be willing to request this on a temporary basis, and only ask to keep it if I can clearly help? Would that be an option? --DannyS712 (talk) 22:56, 16 January 2019 (UTC)
    I would oppose that as well as the pleading for the right is not a good look. There is no race to correct false positives unless they are pouring in from a faulty filter or someone messed something up pretty badly. Even then, you wouldn't be able to fix it and would be in the same position as other EFHs. Nihlus 06:00, 17 January 2019 (UTC)
  • Not outright opposed but, like L235, I'd prefer to see a little more experience first. Please do continue helping out at WP:EF/FP/R, and consider doing a bit more "digging" where you can. That is, figure out which string matched, do a regex search at Special:Search and see if it's common, decide if the filter is even fixable and if so, how it should be fixed, and finally dig through the history of the filter and find someone to ping. Basically, treat each FP as a puzzle to be solved. If this is something you are good at and enjoy doing, you'll probably be back here in a few months and be given the right readily. If you find the process frustrating or boring, then there's no need to increase the attack surface by handing out a right you'll almost never use. With all that said, if you are given this right today, I won't be losing any sleep. Suffusion of Yellow (talk) 06:37, 17 January 2019 (UTC)
    @Suffusion of Yellow: Thanks for the advice. I'll plan on looking into each FP in more detail, like you suggest. Also, on a different note, I added a phab task for effp-helper to be added to xtools. See https://phabricator.wikimedia.org/T214005. --DannyS712 (talk) 06:50, 17 January 2019 (UTC)
    @DannyS712: So now my edits from my own script count will be discounted as "automated". Not fair! Suffusion of Yellow (talk) 07:11, 17 January 2019 (UTC)
    @Suffusion of Yellow: I'm sorry if I over stepped. --DannyS712 (talk) 07:14, 17 January 2019 (UTC)
    @DannyS712: No, I was just kidding around. If I understand that tool correctly, it'll be possible to track when other people are using the script. Which is, of course, a good thing. Suffusion of Yellow (talk) 07:23, 17 January 2019 (UTC)
    @Suffusion of Yellow: Yeah. Sorry, I'm not very good at picking up written sarcasm --DannyS712 (talk) 07:24, 17 January 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Setting filter 3 to warn and disallow?

Every edit of Filter 3 that goes through appears to be vandalism, having checked most of the last 100-150 edits. There really aren't much legitimate reasons to blank a page, with the only one really being blanking a problematic BLP; we can add a note to MediaWiki:Abusefilter-warning-blanking about going to WP:BLPN if a BLP is problematic. Posting here in case there are good reasons this filter is set to only warn and tag; if there are no objections I'll make the changes. Galobtter (pingó mió) 07:48, 14 January 2019 (UTC)

@Galobtter: It's not necessary anymore to set a filter to warn and disallow anymore unless you really want to show the user two different messages; in the past that was done because custom disallow messages weren't possible, so if you wanted to send any message at all other than the standard BITEy MediaWiki:Abusefilter-disallowed, you needed a custom warning. As to whether this filter should be set to plain disallow (with a custom message), I think this is probably fine, but here's a list of recent hits to BLPs, if anyone wants to check:
Of the last 1000 hits, these contained the string "Category:Living people" in the old_wikitext
Suffusion of Yellow (talk) 01:15, 15 January 2019 (UTC)
Thanks for that list! I'll go through them. Regarding warning and disallow, I know, but my thinking was to show MediaWiki:Abusefilter-warning-blanking first the MediaWiki:Abusefilter-disallowed, but a custom disallow is better, which I've created at [4]. Galobtter (pingó mió) 05:23, 15 January 2019 (UTC)
Gone through, no false positives or legitimate BLP blanks. Galobtter (pingó mió) 07:05, 15 January 2019 (UTC)
 Done I've set it to disallow with the message MediaWiki:Abusefilter-warning-blanking. Galobtter (pingó mió) 07:56, 18 January 2019 (UTC)
Ha, I just found Wikipedia talk:Edit filter/Archive 2#Adding Disallow on Filter 3, proposed nearly 10 years ago.. I suppose things take time on Wikipedia, Dragons flight :) Galobtter (pingó mió) 09:21, 18 January 2019 (UTC)

Making the edit filter warnings more friendly?

I've tweaked mainly the images in the sandbox of Template:Edit filter warning so that the messages are overall more friendly: the new version can be seen in Template:Edit filter warning/testcases and the old at Template:Edit filter warning/doc. For the disallow messages, I've used stop hand images to clearly delineate that the edit has been stopped without being overly harsh. In the current version, even the so-called "friendly" versions of warnings and disallow are almost comically overly strong compared to equivalent talk page messages. For example, Filter 614 uses the default disallow message, MediaWiki:Abusefilter-disallowed, but the equivalent talk page message for someone adding "yolo swag 420" would be {{uw-vandalism2}} which is much less strong message. The new version:

is closer in strength to:

Information icon Please refrain from making unconstructive edits to Wikipedia. Your edits appear to constitute vandalism and have been reverted. If you would like to experiment, please use the sandbox. Repeated vandalism may result in the loss of editing privileges. Thank you.

than the old version. Similarly we don't need such a strong warning, MediaWiki:Abusefilter-warning-scribunto-contentmodel, for someone just moving module pages out of module space, while the equivalent in the new version,

is pretty appropriate. Ping @MusikAnimal, Xaosflux, Cyp, and Crow: as (some of the) active EFMs, and I'll post a note on Wikipedia talk:Template messages/User talk namespace. Galobtter (pingó mió) 09:07, 19 January 2019 (UTC)

Looks great to me! No opposition. — MusikAnimal talk 22:11, 19 January 2019 (UTC)
 Done Galobtter (pingó mió) 06:52, 21 January 2019 (UTC)

Does filter 380 need to be private?

  • Filter 380 (hist · log) ("Multiple obscenities")

Username Needed suggested at WP:EF/FP/R that this filter should be made public, and I'm inclined to agree. It's similar in purpose to 384 , and I don't see anything LTA-related in the regex. I can see an argument for keeping the condition on line 2 private, but really, anyone going through the trouble of gaming that will also know how to keep their vandalism subtler than "fuck fuck fuck". Is there something I'm missing? Suffusion of Yellow (talk) 20:59, 30 January 2019 (UTC)

 Already done by Galobtter as I was typing this. Suffusion of Yellow (talk) 21:04, 30 January 2019 (UTC)

"Repeated attempts to vandalise" breaks filter privacy

Any hit on the "Repeated attempts to vandalise" filter allows the otherwise hidden filter hit to be moved into the public filter log. Should we make the filter private? [Username Needed] 10:23, 1 February 2019 (UTC)

@Username Needed: can you provide a couple of examples? — xaosflux Talk 13:13, 1 February 2019 (UTC)

[5] and [6]. I wasn't stating them to avoid WP:BEANS. [Username Needed] 13:44, 1 February 2019 (UTC)

Thanks for pointing that out, I've made it private. Galobtter (pingó mió) 17:10, 1 February 2019 (UTC)

Setting filter 957 to disallow?

I noticed there was a lot of vandalism that involved just removing the article lead, so I created Special:Abusefilter/957. There was one false positive which I solved by tightening the filter, and since then I haven't seen any edits caught that aren't clearly vandalism (/test edit), with a few hundred hits since then. I'll be monitoring for a few more days but it looks good for setting to disallow to me. Galobtter (pingó mió) 06:52, 16 January 2019 (UTC)

I've created MediaWiki:Abusefilter-disallowed-testedit for this, which can be used as a disallow when there's a reasonable chance of an edit being a test. Galobtter (pingó mió) 08:06, 16 January 2019 (UTC)
@Galobtter: Good filter. I'm seeing nothing but garbage in the log. My only (hypothetical) concern would be redirects and attack pages. In theory, that should be covered by new_size > 500, but perhaps out of an abundance of caution !(lcase(added_lines) rlike "#redirect|{{((db-(attack|g10))|wi)}}" from 3 should be in this one as well. Suffusion of Yellow (talk) 07:00, 17 January 2019 (UTC)
I was thinking of adding that but I actually did see a couple of hits where someone used a redirect to vandalize, but since there don't appear to be any more, and as the last condition it should cost very little, I've added that. Galobtter (pingó mió) 07:15, 17 January 2019 (UTC)
@Galobtter: I thought we had a filter that tagged new users creating redirects from existing pages. But it seems 28 has been disabled since 2010 (!) for Terrible run time + not catching much useful + filter is overwrought now. Perhaps it could be revived, in more efficient form. Suffusion of Yellow (talk) 07:32, 17 January 2019 (UTC)
Mediawiki automatically tags all edits that convert an page to a redirect with "mw-new-redirect". Galobtter (pingó mió) 07:43, 17 January 2019 (UTC)
That would explain why I thought there was a filter. Easy enough to narrow down to IPs, etc. from Special:RecentChanges if desired, in any case. Suffusion of Yellow (talk) 07:57, 17 January 2019 (UTC)
 Done with the custom message MediaWiki:Abusefilter-disallowed-article-lead-removed. Galobtter (pingó mió) 07:15, 20 January 2019 (UTC)
Back to log only per Special:AbuseLog/23036967, Special:AbuseLog/23039986, Special:AbuseLog/23040599 (granted, two of the three are copyright violations, but that really isn't what this was meant to be for); I've made the filter more focused on blankings of the lead, by limiting the added_lines length - this'll catch most of the vandalism that I originally created the filter for, such as pure blanking of the lead. The vandalism that won't be caught now already is or should be caught by other filters, or is probably very difficult to catch for an automated system. Galobtter (pingó mió) 06:46, 21 January 2019 (UTC)
Filter tuned to reduce FPs, and set to disallow again. Galobtter (pingó mió) 13:39, 23 January 2019 (UTC)
@Galobtter: Any chance this filter could be refined to catch edits like Special:Diff/881907474? Before you made the change on January 23, similar edits to Today's Featured Article were being disallowed, which was great because that was the only thing that Special:AbuseFilter/951 was doing (the other thing 951 was supposed to do is now handled by 944). If there are just too many FPs, no worries. — MusikAnimal talk 21:33, 5 February 2019 (UTC)
MusikAnimal, No version of this filter could've caught that specific edit because the filter also checks if bolded text is removed (i.e the lead '''William Dowling Bostock'''), which is because there are legitimate reasons to remove an infobox by itself. I suppose there aren't many reasons to remove the Use English, Use DMY dates, or the short description template, which does give me an idea for probably a related new filter though Galobtter (pingó mió) 05:31, 6 February 2019 (UTC)

Phone number tag for edits

Moved from Village pump (proposals)

Recently I report to oversight a piece of vandalism that had a phone number in it. I wonder, could we make a tag for edits like "possible phone number"? Could the system recognize something that looks like a phone number? As far I can figure there is no reason to put a phone number in any article or for that matter any page. Richard-of-Earth (talk) 05:35, 6 February 2019 (UTC)

@Richard-of-Earth: To avoid WP:BEANS, I suggest bringing this up at WP:EFN instead --DannyS712 (talk) 05:51, 6 February 2019 (UTC)
Counterexamples include many of the articles in Category:Telephone numbers in the United States. Anomie⚔ 12:44, 6 February 2019 (UTC)
I don't think publicly tagging the edits would be a good idea (drawing attention to potentially non-public information), but a private filter might be a good idea. There would likely be many false positives and false negatives, so log-only is probably the best implementation. --AntiCompositeNumber (talk) 13:28, 6 February 2019 (UTC)
@Richard-of-Earth, Anomie, and AntiCompositeNumber: I created private filter Special:AbuseFilter/962 to get a feel for how much this may hit on and determine if it is useful. Its having to run a regex on each edit, so we may want to scale it back to just certain namespaces if it gets costly. — xaosflux Talk 15:59, 6 February 2019 (UTC)
Ain't archiving going to consume a lot of the false positives.....? ∯WBGconverse 17:25, 6 February 2019 (UTC)
@Winged Blades of Godric: if so, we can easily exempt page titles containing "/" outside of article space. — xaosflux Talk 17:58, 6 February 2019 (UTC)
Not that (how's that even possible?!), I was talking about adding wayback-machine links to stale sites. See their date-time format.∯WBGconverse 18:03, 6 February 2019 (UTC)
@Winged Blades of Godric: the WBC 14 digit numbers shouldn't collide with this, if you see FP's let me know though. — xaosflux Talk 18:09, 6 February 2019 (UTC)
Eh bad glance-over; currencies are valued:-( ∯WBGconverse 18:29, 6 February 2019 (UTC)
Wow, great that you guys who clearly know more about this then I do are jumping on it. @Xaosflux:How do I get access to this filter? Richard-of-Earth (talk) 20:07, 6 February 2019 (UTC)
@Richard-of-Earth: we always need more people via.....WP:RFA...... - alternatively special access to private filters can be gained by Wikipedia:Edit filter helper

access. — xaosflux Talk 20:13, 6 February 2019 (UTC)

Note, I've disabled this - need to make a better regex for it, just don't have time today. — xaosflux Talk 20:40, 6 February 2019 (UTC)
@Richard-of-Earth: for your specific concern, are the numbers usually in a specific format? (examples: (212)555-1212; +12125551212; 212-555-1212; 44 20 7499 9000;) — xaosflux Talk 14:29, 7 February 2019 (UTC)
In this case there were no dashes or spaces, just a big number. In this case it was something like "call XXXXXXXXXX for a good time" type message. There is software that detects such things. Whenever I get texts, the software highlights phone numbers. Perhaps there is a white paper or some kind of article somewhere about what criteria is used to detect them.

I think the tag should be "Possible Phone Number" as you cannot really be sure if a given number is an actual phone number. The idea I had was not to detect vandalism per se, but to detect vandalism that needs Oversight RevisionDelete. So perhaps it could be narrowed to edits that get removed as vandalism. I was thinking it would be used by the anti-vandalism editors, but now that I think about it, the editors with the oversight bit could just use it directly and quickly RevisionDelete then. That would make it useful even if the filter cannot be public.

Perhaps other filters could be created for other personal information like emails and addresses. Perhaps we should ask the Oversight people what they would find useful. Richard-of-Earth (talk) 19:43, 7 February 2019 (UTC)

It runs in my mind that email addresses are already disallowed, or at least tagged. Nyttend (talk) 00:31, 8 February 2019 (UTC)
This doesn't seem like a good idea. After all, there are many different formats of phone numbers; NANP XXX-XXX-XXXX is only a small part of the world, and XX-XX-XXXX-XXXX cited by Xaosflux is only one other type. For example, according to Telephone numbers in India, some phone numbers are just five digits long (e.g. 58888), without any - or   dividers, and that's in a country with one of the world's largest number of anglophones, not some small state where almost nobody speaks English. I don't see how one could possibly tag for something like this without a significant number of false positives or without missing a large percentage of potential phone numbers. Nyttend (talk) 00:14, 8 February 2019 (UTC)

New User Script

Those involved with edit filters may b interested in User:Suffusion of Yellow/filter-highlighter, just released by @Suffusion of Yellow. --DannyS712 (talk) 00:51, 13 February 2019 (UTC)

Edit filter helper for StraussInTheHouse

WITHDRAWN
Request was withdrawn. --DannyS712 (talk) 00:43, 21 February 2019 (UTC) (non-admin closure)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

I am proficient at regex and have proposed filters before. I am an active AfC reviewer and per this discussion I've decided to start creating some edit filters to track trends at AfC and what, if anything, can be done to assist reviewers through automation. I will be finishing a few of them this coming week and they will be tested on testwiki per testwiki:Wikipedia:Requests/Permissions/StraussInTheHouse. The filters include:
  • Tracking drafts re-submitted with minimal change.
  • Tracking drafts submitted when there is an active MfD.
  • Tracking drafts with specific words in them which are likely to make them be declined.

These filters would obviously not use warn or disallow, it is for monitoring only. EFH would help me with regards to the above activities because, in order for a sound analysis to be produced, the knowledge of which words will trip an NPOV filter and what exact heuristic is used should not be viewable by those who submit AfC drafts, because the smart ones would avoid using certain techniques, even if unintentional. Many thanks, SITH (talk) 23:52, 18 February 2019 (UTC)

  • Oppose per lack of demonstrated need. No FP help and your reasoning is for something that may or may not be happening in the future. Also, there is no reason those filters would need to be hidden as it is not a WP:BEANS issue. Nihlus 00:58, 19 February 2019 (UTC)
    Nihlus, if the community really is satisfied with having the aforementioned filters public, I'll go ahead anyway, it's just better that those submitting drafts don't know which words to avoid that are under assessment. I genuinely disagree with the lack of demonstrated need assertion, considering I've spent a paragraph demonstrating why I think I need it. Also, it's worth noting, I'm not requesting this as a permanent flag, just for the three months to run concurrently with testwiki. SITH (talk) 01:40, 19 February 2019 (UTC)
    You're more than welcome to disagree, but I stand by what I said. Nihlus 01:47, 19 February 2019 (UTC)
  • Note-In meh zone; but the filters can be public and you can test them over testwiki.∯WBGconverse 07:11, 19 February 2019 (UTC)
  • Leaning oppose Mostly per Nihlus, I do not think EFH will be misused by SITH, but again, this is on a need-to-have basis right. --QEDK (後 ☕ 桜) 16:01, 20 February 2019 (UTC)
 Request withdrawn: as this is unlikely to pass and after discussing with several AfC reviewers the likelihood of AfC submitters knowing how the AbuseFilter works (or lack thereof), I've come to the conclusion that it is acceptable to have these filters run publicly. I will email a 'crat on testwiki with regards to importing. Many thanks, SITH (talk) 23:29, 20 February 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit Filter Helper for EggRoll97

 Not done This request is closed as not done. You are still welcome to help with false positives for public filters. — xaosflux Talk 14:57, 23 February 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

Hello again! I'd like to re-request edit filter helper after half a year (more or less) since my last request. I believe I have gained lots of experience in false positives since then. I simply want the right to be able to expand on the number of false positive requests I can deal with, as some of the filters are private.

As per the requesting process, here are the notifications for the participants (and closing sysop) of the last request: (Apologies for pings)

@JudeccaXIII: @Xaosflux:

[Previous request]

Thank you for taking the time to consider my request, EggRoll97 (talk) 08:26, 20 February 2019 (UTC)

Of course. I had some issues in the real world around the time of my inactivity period of editing, though I still tried to maintain my activity on rollback (perhaps to only slight avail) and attempted to review the false positives page when I could. These were generally times when I had family occasions piling up, and therefore my activity had to severely decline. I understand this likely isn't acceptable, but that's my reasoning. (Also should be noted that many times on the false positives page, people beat me to the approval/decline, therefore the contributions wouldn't be reflecting how much I'm reviewing the page, simply how many requests I had the opportunity to act on) EggRoll97 (talk) 14:09, 20 February 2019 (UTC)
You'v only had pending changes a couple of days, and yet don't seem to have take on board the responsibility that comes with the right. I'm nt sure this is the time to be requesting a tool bearing an even heavier responsibility. ——SerialNumber54129 14:53, 20 February 2019 (UTC)
  • Oppose per Serial and the lack of experience in many wiki areas. Knowing what is in the filters is half the battle, and I am not sure you have the experience needed to handle the rest. Nihlus 17:43, 22 February 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter manager right for Suffusion of Yellow

 Done following unanimous support — MusikAnimal talk 23:57, 25 February 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

Hello all. Galobtter and MusikAnimal have both suggested that I request this right, so here I am. I've been making quite a few requests for filter improvements over at WP:EF/FP/R over the last few months, and I suppose the time has come for me to start making the changes myself instead of pestering others, at least in simpler cases. I'd also like to help more at WP:EF/R, but I've discovered since being assigned the EFH bit that Special:AbuseFilter/test isn't really "good enough" for this (except as a basic sanity check) with its 100 edit limit. The better way is to create a log-only testing filter and let it run for at least a few days, while fussing over the details and discovering all the things you didn't think of.

I, of course, understand that this is a dangerous user right and will always use extreme caution when modifying filters. Feel free to ask any questions! Suffusion of Yellow (talk) 23:24, 18 February 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Regex check

Hi, having a brain fart here - can someone take a look at Special:AbuseFilter/960 for what my error is? — xaosflux Talk 21:48, 16 February 2019 (UTC)

@Xaosflux: I think it's actually the missing parenthesis around 'User:'+user_name+'/' that's the problem. Though I suppose changing the regex to \.(js|css)$ would prevent the occasional FP. Suffusion of Yellow (talk) 22:02, 16 February 2019 (UTC)
There's also the variables new_content_model and old_content_model, which would avoid flagging edits like Special:Diff/883058281 but I'm not sure they're ever filled in unless the model is being changed. Don't seem to contain anything at Special:Abusefilter/examine, at least. Suffusion of Yellow (talk) 22:17, 16 February 2019 (UTC)
Actually, just tried with a "real" filter and seems that they are filled in for all edits. But old_content_model will be empty for page creations. Suffusion of Yellow (talk) 22:23, 16 February 2019 (UTC)
@Suffusion of Yellow: thanks, I haven't had time to get back to this, but feel free to take a stab now that you can :D — xaosflux Talk 00:29, 26 February 2019 (UTC)
@Xaosflux:  Done I left out the content model check as it seems there are only five sanitized CSS pages in all userspace. But if you don't want unprivileged users to ever trip the filter a check could be added. Suffusion of Yellow (talk) 05:14, 26 February 2019 (UTC)

Abuse filter 220

Namespace

Hi. Currently, Special:AbuseFilter/220's first line is

article_namespace == 0 &

however, mw:Extension:AbuseFilter/Rules format#Variables from AbuseFilter reports that article_namespace has been depreciated in favor of page_namespace

can I suggest that the first line be changed to page_namespace == 0 &?

Thanks, --DannyS712 (talk) 23:21, 27 February 2019 (UTC)

@DannyS712:  Done, thanks. It looks there are over 50 occurences of article_namescape in the just the enabled filters, so it might be best just to wait for bored EFMs to fix these as they find them. Suffusion of Yellow (talk) 00:55, 28 February 2019 (UTC)
@DannyS712 and Suffusion of Yellow: yup, there are other similar old variables - while these are deprecated, they are aliased - so please don't file a bunch of edit requests - someone will get to them. — xaosflux Talk 01:10, 28 February 2019 (UTC)
@Xaosflux: Okay, won't file a bunch of requests. But, if anyone cares, of the public non-deleted non-disabled filters, 41 use depreciated variables (listed below) --DannyS712 (talk) 01:17, 28 February 2019 (UTC)
Public enabled filters using depreciated variables, 01:17, 28 February 2019 (UTC)
  1. Special:AbuseFilter/61
  2. Special:AbuseFilter/79
  3. Special:AbuseFilter/117
  4. Special:AbuseFilter/132
  5. Special:AbuseFilter/148
  6. Special:AbuseFilter/149
  7. Special:AbuseFilter/164
  8. Special:AbuseFilter/167
  9. Special:AbuseFilter/172
  10. Special:AbuseFilter/174
  11. Special:AbuseFilter/180
  12. Special:AbuseFilter/323
  13. Special:AbuseFilter/339
  14. Special:AbuseFilter/346
  15. Special:AbuseFilter/351
  16. Special:AbuseFilter/391
  17. Special:AbuseFilter/432
  18. Special:AbuseFilter/491
  19. Special:AbuseFilter/550
  20. Special:AbuseFilter/602
  21. Special:AbuseFilter/627
  22. Special:AbuseFilter/631
  23. Special:AbuseFilter/650
  24. Special:AbuseFilter/655
  25. Special:AbuseFilter/657
  26. Special:AbuseFilter/686
  27. Special:AbuseFilter/716
  28. Special:AbuseFilter/733
  29. Special:AbuseFilter/735
  30. Special:AbuseFilter/753
  31. Special:AbuseFilter/777
  32. Special:AbuseFilter/783
  33. Special:AbuseFilter/784
  34. Special:AbuseFilter/788
  35. Special:AbuseFilter/833
  36. Special:AbuseFilter/862
  37. Special:AbuseFilter/869
  38. Special:AbuseFilter/878
  39. Special:AbuseFilter/891
  40. Special:AbuseFilter/899
  41. Special:AbuseFilter/921

Split between "href" and image addition

Per https://github.com/azatoth/twinkle/issues/489, can we split filter 220 in two filters, one for links and one for images? If not possible, can we at least verify that image addition happens way more often than non-image "href" addition, and that the first bullet point on MediaWiki:Abusefilter-warning-external-images should be about images?

Furthermore, I propose to replace the icon by a red warning sign, and to change the message color to red. ~ ToBeFree (talk) 00:58, 28 February 2019 (UTC)

Setting Filter 231 to disallow?

Filter 231 currently only warns and tags, because there are ostensible reasons for typing 50+ characters in a row without spaces, but having checked I think 200+ diffs/abuselog entries of mostly saved changes, the closest to a false positive I've found is a bit of spam (and most .onion urls are blacklisted too..), so I think its reasonable to set this to disallow. Galobtter (pingó mió) 08:56, 12 February 2019 (UTC)

If it's 99% all vandalism (or spam), then I support disallowing. I suggest keeping the custom message, though it does need to be reworded to state the edit was disallowed. Thanks for doing the tedious work of checking for false positives! — MusikAnimal talk 17:50, 12 February 2019 (UTC)
Maybe that's okay in 99.999999999999999999999999999999999999999999999999999999999999% of cases, but I can imagine someone occasionally writing out a big number, e.g. 10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 is a working redirect to an article that contains that precise string. If we're disallowing flagged edits, we should consider not flagging if the string is exclusively digits, or at least if it's exclusively a combination of digits and commas or periods. Nyttend (talk) 00:00, 13 February 2019 (UTC)
The filter won't catch that string. Nihlus 00:17, 13 February 2019 (UTC)
Okay, good then. I saw that I wasn't warned, but I thought maybe it was because I'm an admin. Nyttend (talk) 00:29, 13 February 2019 (UTC)
No filter (or even human) can be 100% accurate, so the goal of filters is to have a very low FP rate, not zero; but anyhow, as Nihlus says, the filter wouldn't flag that as it only counts long strings of alphabetical or numerical characters (i.e, the filter is actually more like "Long string of characters containing no spaces or punctuation"). Galobtter (pingó mió) 08:17, 13 February 2019 (UTC)
See, if I'd known that "no spaces or punctuation" were the situation, I wouldn't have objected; I don't envision someone writing 99.999999999999999999999999999999999999999999999999999999999999% except to make a point (otherwise you could write 99.9999999999999999999999999999999999999999999999999%, just 49 uninterrupted characters instead of 60, and it equals 100% anyway), but the interrupted-by-punctuation is definitely necessary. Thank you for helping me understand better. Nyttend (talk) 01:36, 14 February 2019 (UTC)
Nein nein nein nein nein nein nein nein nein...? I'm sooo tempted to Godwin this thread. Suffusion of Yellow (talk) 01:56, 14 February 2019 (UTC)
@Suffusion of Yellow: ? --DannyS712 (talk) 01:59, 14 February 2019 (UTC)
@DannyS712: Godwin's law: As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 0.999... Suffusion of Yellow (talk) 02:10, 14 February 2019 (UTC)
@Suffusion of Yellow: I know what godwin's law is, I just didn't understand how it was relevant (now I get it................) --DannyS712 (talk) 02:11, 14 February 2019 (UTC)
MusikAnimal, regarding the custom message, I've been thinking about it and (while I don't think it matters too much) I think the default disallow message works fine here; the edits are basically all (bad-faith) vandalism and so the message doesn't need to be any softer than usual, and I don't know if we should be explaining to vandals why their edit was blocked and thus how to get around the filter (and the should-be-rare good faith editor should report the issue rather than removing the the offending bit of their edit). Galobtter (pingó mió) 20:16, 14 February 2019 (UTC)
@Galobtter: Yeah you're right. Let's just go with the standard disallow message, then. Thanks again! — MusikAnimal talk 01:16, 15 February 2019 (UTC)
 Done Galobtter (pingó mió) 13:22, 1 March 2019 (UTC)

Edit filter helper for User:Leaderboard

There is a rough consensus to grant EFH. After considering various factors, I consider it appropriate to provisionally grant the right for one year, which can be extended if necessary by a simple request to any admin. -- zzuuzz (talk) 21:43, 3 March 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

It was suggested at meta:Meta:Requests for adminship/Leaderboard that I apply for this right at en.wiki since I could potentially use its filters to benefit other projects. I am an admin at en.wikibooks and MediaWiki, and have experience in using filters to combat spam and other nonsense. Thanks in advance. Leaderboard (talk) 17:29, 24 February 2019 (UTC)

Depending on how the filters are be implemented, I can export it to other projects to more effectively stop nonsense. One quick example would be the abusefilter that reads ("Promotional text added by user to own user(-talk) page") - that is certainly one that I would look to exporting - especially if it avoids the false-positives caused by the link catcher method. (sorry not sure what "non-beansy" means) Leaderboard (talk) 20:42, 26 February 2019 (UTC)
@Leaderboard: non-beansy refers to the essays WP:BEANS --DannyS712 (talk) 21:10, 26 February 2019 (UTC)
  • Thanks for the reply. Is this a continuous sort of thing? I know in past other EFMs on other projects have emailed the mailing list here for details on specific filters they needed. Just wondering if that is an option? I'm not arguing against you, I just believe in the Principle of least privilege, so want to make sure you are actually hindered by not having this access if other means will accomplish the same thing. CrowCaw 21:15, 26 February 2019 (UTC)
I think that would be a hinderance as I would have to email the mailing list for every filter that I want to see, and I might just not do anything in the end. Leaderboard (talk) 14:04, 27 February 2019 (UTC)
@Xaosflux: Leaderboard (talk) 20:08, 3 March 2019 (UTC)
@Leaderboard: I participated above, so you will need to wait for another admin to close this. — xaosflux Talk 21:16, 3 March 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter for adding nonfree file

Just curious: can edit filter be made to detect adding of nonfree file? (by matching the file's category or license information) --Horus (talk) 04:06, 2 March 2019 (UTC)

@Horus: I suggest bringing this up at Wikipedia:Edit filter/Requested, where it is more likely it will get actioned --DannyS712 (talk) 22:24, 3 March 2019 (UTC)
Unfortunately the only information which can be got about the file is the information which is included on the edited page, namely the file's name and whether it's a redlink. Things like file size, image categories, and any information from the description page are not available. -- zzuuzz (talk) 22:59, 3 March 2019 (UTC)

Filter 965

Noting I've created filter 965, which is targeting Hindustani and other Indo-Aryan language profanity, that has picked up since the 2019 Pulwama attack. I'll need to monitor it of course for another week or two or so, but it looks good for disallowing. Galobtter (pingó mió) 13:20, 26 February 2019 (UTC)

@Galobtter: Out of curiosity, is aunty? particularly offensive? It sounds—well, you know! ——SerialNumber54129 14:46, 26 February 2019 (UTC)
Serial Number 54129 Only matches when followed by "ch[ou]+[dt]". (?:ben|bhen|behn|b[eah]{3,}n|bha(?:i|e+)n?|maa|m[tdhauer]{3,}|bh?abh?i|bac?k|bakri|boka|biya|aunty?|beti) is almost all a list of various transliterations for names for female family members (+animals), which when combined with "ch[ou]+[dt]" gives variants on basically motherfucker and goatfucker. Galobtter (pingó mió) 14:54, 26 February 2019 (UTC)
 Done Set to disallow. Working well. Galobtter (pingó mió) 13:24, 4 March 2019 (UTC)

Make filter table sortable

Special:AbuseFilter has a really big table. It would be nice to have it sortable. Headbomb {t · c · p · b} 05:34, 5 March 2019 (UTC)

@Headbomb: click on the column headings. Also, phab:T217520 --DannyS712 (talk) 05:36, 5 March 2019 (UTC)
Headbomb, It is, also see phab:T217520. Galobtter (pingó mió) 05:37, 5 March 2019 (UTC)
Hah, typed almost the same thing as Danny. Reply-link should really have edit-conflicts. Galobtter (pingó mió) 05:38, 5 March 2019 (UTC)
That is ... really, really counter intuitive. When you load the page, only "▼ Filter" indicates that it could be sorted. Every other column lack the normal sorting icon which looks kinda like 🞁
🞃, but more closely spaced. Also clicking on a wikilink is completely unintuitive, given you expect to be taken to a different page. And two of the columns aren't sortable. Headbomb {t · c · p · b} 05:45, 5 March 2019 (UTC)
The ticket is about getting the other two columns sortable and also talks about the unintuitiveness. Galobtter (pingó mió) 05:53, 5 March 2019 (UTC)

Edit filter helper for User:Cabayi

Granted by checkuser. Galobtter (pingó mió) 14:23, 10 March 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I'm starting out as an SPI clerk. The comment on one case that socks have triggered filter 927 kind of leaves me at a dead end (though there's sufficient alternative evidence in this case to justify a CU request). EFH would be a great help in making sense of some of these cases. Thamks, Cabayi (talk) 16:59, 7 March 2019 (UTC)

  • Support per criteria #1 - A Checkuser may, at their discretion, grant this right to a Wikipedia:Sockpuppet investigations (WP:SPI) clerk or trainee clerk who: Meets the criteria in the "Requirements for granting" section [and] Has not had an edit filter-related right removed previously for any reason other than inactivity. --DannyS712 (talk) 17:44, 7 March 2019 (UTC)
  • Support. Clear need for the access. –Ammarpad (talk) 15:08, 8 March 2019 (UTC)
  • Questions: 1. Do you understand regex? 2. Can you give an example (without giving away any confidential details) of you using a public filter's log to assist in clerking? (@Cabayi: Pinging for notice.) CrowCaw 16:34, 9 March 2019 (UTC)
  • Crow - 1. Yes. 2. There's an example in the request (if I had the permission to see it). Sorry, I misread that. Of a public filter - no. I'm only 3 weeks into the clerk training. Filters haven't played a significant part in any of the cases I've tackled yet. Cabayi (talk) 17:50, 9 March 2019 (UTC)
  • The filters most useful (or even the only useful filters) for a (trainee) clerk are going to be filters for LTA/specific sockmasters, which are of course invariably private. Galobtter (pingó mió) 17:55, 9 March 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Oooh! So that's what's in 927! Thanks KrakatoaKatie, get well soon. Cabayi (talk) 14:25, 10 March 2019 (UTC)

Filter 694 is too strict

I can think of a few legitimate reasons to move a page to or from module namespace.

  1. So that modules can have documentation subpages that don't have awkward titles like Module:Convert/documentation/conversion data introduction/doc and Module:Convert/documentation/conversion data/doc.
  2. So that modules can have testcases implemented in Wikitext rather than Lua (RexxS likes to create these, somewhat awkwardly, in module talk namespace)
  3. To work around various other bugs (ex: Module:Citation/CS1/styles.css, obviously the correct name for that page, could only be created because Trappist the monk was an admin who has access to Special:ChangeContentModel ) -- this bug has since been fixed by the developers.


I would propose that this be split into two filters.

  1. A disallow filter that blocks all moves of scribunto-contentmodel pages out of module namespace (I can't think of any legitimate reason to do this)
  2. A warn (and maybe also tag) filter that warns on moves of non-scribunto-contentmodel pages into module namespace, with an exception for moving sanitized-css-contentmodel pages into titles ending with ".css", as the latter is a valid move of a TemplateStyles page.

{{3x|p}}ery (talk) 23:07, 26 February 2019 (UTC)

I'd support this proposal. As Pppery says, at present, when creating test cases for Lua modules, I either have to write a collection of Lua calls in Module:Example/testcases (which actually produces its results in Module talk:Example/testcases) or I have to put a set of #invokes into something like Module talk:WikidataIB/testing. Talk pages should, in theory, be for discussion, but I don't have another usable place to put test cases. --RexxS (talk) 23:34, 26 February 2019 (UTC)
@Pppery: I just tried to move a module out of Module-space on testwiki, and the software wouldn't even let me. So the first filter shouldn't even be needed anymore. Suffusion of Yellow (talk) 23:37, 26 February 2019 (UTC)
Yeah I tried it on the beta cluster, and same result --DannyS712 (talk) 23:47, 26 February 2019 (UTC)
@Suffusion of Yellow: I can confirm that modules can't be moved to any namespace other than module namespace. The move returns the error:
"Scribunto" content is not allowed on page ____ in slot "main" for any ____ page name
--DannyS712 (talk) 23:51, 26 February 2019 (UTC)
However, non-module pages can be moved into the module namespace - see [7] - with this filter currently prevents on enwiki --DannyS712 (talk) 23:53, 26 February 2019 (UTC)
@Pppery and RexxS: I'm not too familiar with modules, or the origin of this filter. Can someone explain what problem it was trying to solve? The comments just say it breaks things in a way that requires admins to fix. Exactly what does happen when a non-scribunto page is moved into Module space? If the filter is changed to warn-only, it should tell users what to expect if they click "Save" again, or better yet link to a documentation page explaining what's up. Suffusion of Yellow (talk) 23:55, 26 February 2019 (UTC)
@Suffusion of Yellow: My understanding of what happens is that the page is still interpreted as Wikitext and therefore can't be #invoke-d, and the only way to fix that issue is for an admin to Special:ChangeContentModel it to Scribunto. Someone techier than me could probably provide a better explanation, though. {{3x|p}}ery (talk) 00:15, 27 February 2019 (UTC)
(edit conflict) @Suffusion of Yellow: MediaWiki allows pages to have an associated "page content model", so normal article pages have a page content model of "Wikitext". but Module:WikidataIB has a page content model of "Scribunto" and stylesheet pages should have a page content model of "Sanitized CSS". You can see what a page's content model is by following the "Page information" in the tools menu in the left column of a page. The content model generally corresponds to the namespace in which the page was created and governs its behaviour. However, moving a page from one namespace to another does not change its content model – you need an admin to do that. There are occasions when it's useful to be able to move a page into module namespace (even though an admin may need to update its content model in some circumstances). Does that help? --RexxS (talk) 00:20, 27 February 2019 (UTC)
@RexxS: Thanks. Will any harm come from this, apart from the moving user getting confused as to why their module doesn't work? I've also found that it is possible to move a move a module to a /doc page, but again I don't see the harm apart from someone saying "why isn't the documentation rendering?". Suffusion of Yellow (talk) 00:28, 27 February 2019 (UTC)
@Suffusion of Yellow: I was suggesting that still be disallowed because I see no usecase for it and therefore see no need to change it. If someone accidentally creates a module that should be a doc page outside of the /doc namespace, then someone will need to change its contentmodel, and so the move might as well happen after the content model change. {{3x|p}}ery (talk) 00:33, 27 February 2019 (UTC)
Extending some of the comments #Regex check to create these filters should be pretty easy --DannyS712 (talk) 23:43, 26 February 2019 (UTC)
@DannyS712: Tried that, and from what I can tell new_content_model and old_content_model are (along with most other variables) empty during page moves. Suffusion of Yellow (talk) 23:05, 27 February 2019 (UTC)
@Suffusion of Yellow: you're right - see mw:Extension:AbuseFilter/Rules format#Notes --DannyS712 (talk) 23:11, 27 February 2019 (UTC)
@Suffusion of Yellow and DannyS712: Gah! Someone should probably report that bug, but in the mean time, how about these suggestions:
  1. One filter that warns on any move from outside module namespace or from a module doc page to a title in module namespace not ending in /doc
    • With the exception of moving pages from template namespace titles than end in ".css" to module namespace titles that end in ".css"
  2. A second filter that warns (with a different message) on any move from a module non-doc page to a module doc page (the only legitimate reason I can think of for doing this that doesn't require a content model change later is a revert of a move that triggered the first filter and was performed incorrectly).
{{3x|p}}ery (talk) 23:35, 27 February 2019 (UTC)
@Pppery: For the first 1, I think https://en.wikipedia.beta.wmflabs.org/wiki/Special:AbuseFilter/466 might be a start --DannyS712 (talk) 23:47, 27 February 2019 (UTC)
@DannyS712: Thanks! But because of the stupid way performance is measured, I think there should only be one filter, with both possibilities mentioned in the warning, i.e. "If you doing X ... this will happen, if you were doing Y, that will happen". This filter has only ever had 77 hits, so it's not worth wasting even one condition, just to make the warning slightly less confusing. Suffusion of Yellow (talk) 23:52, 27 February 2019 (UTC)
@Suffusion of Yellow: if you make an account over there I'll give you EFM --DannyS712 (talk) 23:53, 27 February 2019 (UTC)
@DannyS712: Thanks, but not right now. Suffusion of Yellow (talk) 00:11, 28 February 2019 (UTC)

@DannyS712: I think there needs to be a "$" at the end of your regexes, else it would get confused about pages that have "/doc" elsewhere in the title. Also, (although this is my error), the CSS testing should only apply to subpages, as that's what TemplateStyles actually checks for. {{3x|p}}ery (talk) 00:04, 28 February 2019 (UTC)

@Pppery:  Done I think - also, the EFM thing applies to you - make a beta cluster account and I'll add you --DannyS712 (talk) 00:12, 28 February 2019 (UTC)

Is anything stopping this from going live now? (other than the lack of a willing admin) {{3x|p}}ery (talk) 02:22, 28 February 2019 (UTC)

@Pppery: DannyS712's filter still needs a few finishing touches. If you have something specific you've been waiting to move, I'll try to get to it when I'm less hungry. An admin will also need to change the warning, but that's probably best done after the filter conditions have been updated. Suffusion of Yellow (talk) 02:47, 28 February 2019 (UTC)
@Pppery and DannyS712: Final (I hope) version is at testwiki:special:Abusefilter/190. If it still makes sense to me in the morning (US) I'll copy it over here. Suffusion of Yellow (talk) 06:11, 28 February 2019 (UTC)
@Pppery:  Done Filter is updated, but set to log-only until the warning message is changed. Suffusion of Yellow (talk) 20:27, 28 February 2019 (UTC)
@Suffusion of Yellow: OK, I've done a few of these moves, and they seem to work, except for a few pre-existing templates and modules that fallaciously assume all Module namespace pages that don't end in "/doc". I've fixed Template:Documentation, and edit-requested that the editnotices be fixed, but there are probably many others. {{3x|p}}ery (talk) 21:52, 28 February 2019 (UTC)
@Suffusion of Yellow: the /doc allowance could also extend to /testcases? --DannyS712 (talk) 23:39, 28 February 2019 (UTC)
@DannyS712: I would oppose that: the purpose of this filter is to warn on any attempt to move a page to a title that would have been in a different content model if it were created at that title. /testcases pages are Lua by default (unlike /doc pages), so they shouldn't be exempted in the filter. {{3x|p}}ery (talk) 23:47, 28 February 2019 (UTC)
@Pppery: (ec) I already changed it to allow moves from non-module-space pages TO /testcases pages, on the assumption that the editor would never want a Lua /testcases page anyway. If that's a problem, I can revert. Suffusion of Yellow (talk) 23:52, 28 February 2019 (UTC)
@Suffusion of Yellow:. Plenty of Lua /testcases exist, in fact most modules have testcases coded in Lua at this time. It's not correct to assume that that the editor would never want a Lua /testcases page, and therefore this should be reverted. {{3x|p}}ery (talk) 23:54, 28 February 2019 (UTC)
 Done Suffusion of Yellow (talk) 23:58, 28 February 2019 (UTC)
@Suffusion of Yellow and Pppery: wait then how have you been moving the testcases pages so far? --DannyS712 (talk) 00:08, 1 March 2019 (UTC)
@DannyS712: The filter is currently log-only as a temporary measure pending update of the warning, and in any case would be warn-only, so I just triggered the filter when I executed the move. {{3x|p}}ery (talk) 00:10, 1 March 2019 (UTC)
@Pppery: but if this is enabled, you wouldn't be able to any more... so again, we need to decide where, long-term, testcases for modules should be left --DannyS712 (talk) 00:11, 1 March 2019 (UTC)
@DannyS712: I will still be able to, I'll just have to click through a warning first. {{3x|p}}ery (talk) 00:20, 1 March 2019 (UTC)
@Pppery: oh, duh, its not disallow. feel free to trout me --DannyS712 (talk) 00:21, 1 March 2019 (UTC)
@Suffusion of Yellow: The MediaWiki message has now been changed. {{3x|p}}ery (talk) 20:07, 5 March 2019 (UTC)
@Pppery:  Done, finally! Suffusion of Yellow (talk) 23:16, 5 March 2019 (UTC)

New warning

The current warning reads:

I'm tempted to just go with:

But maybe it could go into more detail:

I'm not sure WP:VPT is best place to direct people, but I don't know where else to send them. WP:EF/FP/R isn't really the right place either, since it's not a case of a "false" positives, but rather needing help from an admin to do something. Any thoughts? Suffusion of Yellow (talk) 00:45, 28 February 2019 (UTC)

Maybe WT:Lua? --DannyS712 (talk) 00:49, 28 February 2019 (UTC)
@Suffusion of Yellow: Replace "a" with "this" for clarity. I think the longer version is better, as the short version sounds like it's almost attacking the user for their inexperience. Also, because of the bug of content model variables not being available, this filter will also trigger on some reverts of moves that triggered the filter, so maybe that should be accounted for in the warning. {{3x|p}}ery (talk) 00:54, 28 February 2019 (UTC)
Took me a moment, I guess "If you are moving a Lua script" -> "If you are moving this Lua script" ~ ToBeFree (talk) 01:03, 28 February 2019 (UTC)
@ToBeFree: Nope, I meant "Moving a page will not change its content model" -> "Moving this page will not change its content model". {{3x|p}}ery (talk) 01:07, 28 February 2019 (UTC)
Oh, I see. :D Then I kindly suggest mine too. As it isn't necessarily a Lua script, mine is probably not good. ~ ToBeFree (talk) 01:22, 28 February 2019 (UTC)

Ok, made those changes, and also made it less shouty as both actually seemed a bit insulting on a re-read. If you can think of any more improvements, feel free to edit this comment.

Suffusion of Yellow (talk) 01:29, 28 February 2019 (UTC)

Requested at MediaWiki talk:Abusefilter-warning-scribunto-contentmodel. {{3x|p}}ery (talk) 23:10, 28 February 2019 (UTC)

This is slightly off-topic, but I made a request to improve the error message when moving a page out of module namespace at MediaWiki talk:Content-not-allowed-here. On the dark side, that means I now have four highly obscure edit requests to MediaWiki namespace pending. {{3x|p}}ery (talk) 01:33, 28 February 2019 (UTC)

Before we go moving all of the testcases, we should have an rfc - I've started a draft here --DannyS712 (talk) 23:30, 28 February 2019 (UTC)
Do we really need an RfC? Just ping like the five people who do any regular work in modules and who would care about this. Not like there many testcases for modules anyhow. Galobtter (pingó mió) 13:29, 4 March 2019 (UTC)

@DannyS712: Is something preventing a discussion on this from starting? {{3x|p}}ery (talk) 22:38, 13 March 2019 (UTC)

@Pppery: I mean not really; I assumed that Galobtter was right and we didn't need an RfC, but if we do you can feel free to copy my draft. --DannyS712 (talk) 23:18, 13 March 2019 (UTC)

MediaWiki bug/feature discussion

There is now a discussion about the underlying MediaWiki behavior at Wikipedia:Village_pump_(technical)#Should_moving_a_page_change_its_content_model_in_some_situations?. ~ ToBeFree (talk) 01:26, 28 February 2019 (UTC)

Cutler LTA, round++

The filter for this LTA was updated a few weeks ago plus a range block, but he's posting a new version of his wacko delusions. [8] and [9] for examples from today. While not as crazy and BLP violating as his previous rants, would it be possible to update the filter to block his latest drek? Thanks! Ravensfire (talk) 16:16, 14 March 2019 (UTC)

More exceptions for emoji filter (680)?

Resolved
 – Pageid's added. — xaosflux Talk 04:27, 30 March 2019 (UTC)

The filter and an example blocked good edit. On List of Falcon 9 first-stage boosters and List of Falcon 9 and Falcon Heavy launches we use an emoji in the filtered range (♺) to indicate reused rocket boosters. Adding these symbols is part of routine article updates. Currently Emoji and Principia Mathematica are exempt from this rule. Is it possible to add the two rocketry articles (page ids: 37574004, 54585305) to the exceptions? — Preceding unsigned comment added by Mfb (talk • contribs)

@Mfb: See Talk:List_of_Falcon_9_and_Falcon_Heavy_launches#What's_with_the_emoji? first. We certainly COULD exempt more pages, but I think a better question is why should we at all? — xaosflux Talk 00:41, 30 March 2019 (UTC)
Also it doesn't look like either of those articles is using that text anywhere. I could possibly see the use for it somewhere in Emoji. — xaosflux Talk 00:43, 30 March 2019 (UTC)
Which text? The booster list uses the symbol 25 times, the launch list uses it 29 times. These numbers will increase in the future as most future launches are expected to reuse a booster. Well, let's discuss on the talk page there first. --mfb (talk) 03:20, 30 March 2019 (UTC)
The "current exemption" pages you referenced (Emoji and Principia Mathematica). — xaosflux Talk 04:22, 30 March 2019 (UTC)
@Mfb: all that being said, this isn't a debate to be had about the edit filter. I've exempted the pageid's and will follow up at the article talk. — xaosflux Talk 04:26, 30 March 2019 (UTC)

Filter 50: Add __INDEX__ exception?

Special:AbuseLog/23781241 flagged as shouting, presumably because of the addition of __INDEX__. There's a good chance that adding __INDEX__ should be getting logged if done by new users or IPs (I'd guess that it would be pretty likely promotional editing), but it's not a case of shouting.— Preceding unsigned comment added by Creffett (talk • contribs) 20:34, 19 April 2019 (UTC)

@Creffett:  Done. I just made an exception for __[A-Z]+__, so the filter won't need to be updated every time a new magic word is added. I suppose some people might emphasize words like __THIS__, but in the last 500 hits, no one had done so. I'm ambivalent on logging additions of __INDEX__ in mainspace. Yes, there's a good chance of spam/COI issues, but it doesn't actually do anything; only new page patrollers can actually index a mainspace page. See also Wikipedia:Edit filter noticeboard/Archive 4#VisualEditor. Suffusion of Yellow (talk) 22:46, 19 April 2019 (UTC)

Request for comments: AbuseFilter stats

Hi everyone! Lately, I've been working on implementing a new feature in AbuseFilter: on-wiki detailed profiling, with a log like Special:AbuseLog which would collect data about slow executions and runtime errors (and possibly more). The feature is on gerrit and there's still a lot to do, so don't expect to see it shortly. However, I'm here to ask comments about the visibility of this feature. I think there are 3 options: 1 - Use an existing restriction for the page itself (e.g. use the "abusefilter-log" right), and require "abusefilter-view-private" for entries related to private filters. 2 - Same as 1, but introduce a new right. 3 - Restrict the whole page to people who can see private filters. The reasoning behind 3 is that the log could disclose performance issues about existing filters, although I don't think they'd be exploitable in any way. I also prefer 1 instead of 2 to avoid adding new rights. What do you think the best choice would be? Keep in mind that it can be changed later, this is just to finish building the first working example. Please feel free to ping me if you have any question! Thanks, --Daimona Eaytoy (Talk) 17:35, 26 March 2019 (UTC)

We already have two user groups for AbuseFilter, we don't need another one :) So I concur, option 1 seems best. Thank you for working on this exciting and long desired feature! — MusikAnimal talk 00:36, 27 March 2019 (UTC)
@MusikAnimal: I don't think this question was about "groups" it is about permissions (of which we have many). That being said, I suggest a slight variation on (1) using (abusefilter-log-detail) and (abusefilter-view-private). Some projects don't allow the "any" group to view detail like we do, and this seems to be closer related to that level. — xaosflux Talk 00:54, 27 March 2019 (UTC)
Great! Thank you both for the comment. I think abusefilter-log is actually the right one for the whole page and abusefilter-log-detail for details of single entries. --Daimona Eaytoy (Talk) 09:35, 27 March 2019 (UTC)
That seems fine, then just use -view-private if it is a private filter for screening. — xaosflux Talk 11:39, 27 March 2019 (UTC)
  • @Daimona Eaytoy: Will this new log include the name of the user or the page being edited? If so, is there any possible way that api.php?action=stashedit could cause an entry to appear in the log? It seems to cause the standard "On average, its run time is 0.1 ms, and it consumes 1 condition of the condition limit" stats to update, at least on my local wiki. I wouldn't consider it public information that User:Foo was editing page Bar at time T, but chose not to click "Publish changes". Suffusion of Yellow (talk) 00:30, 7 April 2019 (UTC)
    @Suffusion of Yellow: Yes, user and page will be included; you can find here the messages for the log entries. The recording of slow filters is (=will be) done together with the other profiling data for consistency. However, IIRC, profiling stats recorded on stashed edits shouldn't show up anywhere in the interface. What we do is just save runtime etc. in cache during stashedit, and reuse it upon saving if the user effectively saves the edit. Could you please check (on master) that stashed edit data appears in the UI even if the user chooses not to save the edit? I ensured it didn't happen in phab:T191032 and phab:T191430. Thanks! --Daimona Eaytoy (Talk) 08:34, 7 April 2019 (UTC)
    @Daimona Eaytoy: I tried it on master this time, and now it seems that stashedit doesn't cause updates to the (old-style) stats. I also went ahead and tried the new feature (should have done that in the first place...) and there's no way I've found to cause anything to appear to at Special:AbuseFilter/problems without attempting save the edit. So, all good! Suffusion of Yellow (talk) 22:53, 7 April 2019 (UTC)
    Ha, that's great! Glad to hear that everything is working as expected :-) Thank you for your thoughts. --Daimona Eaytoy (Talk) 09:23, 8 April 2019 (UTC)

Over at the false positives page, there's the occasional false positive where the filter is only tripped due to a reference being added where the title is in all caps, and has a word banned by the filter. Additionally, link names sometimes contain a disallowed word and trip the filter to disallow the entire edit. Would it be possible to exempt links and refs from filter 225? EggRoll97 (talk) 18:12, 15 April 2019 (UTC)

Is it possible to give the particular diffs? This particular public filter gets a lot of hits and for a very small number of FPs, there's not much of a point making another exception. --qedk (t 桜 c) 12:58, 16 April 2019 (UTC)
Something like this got disallowed by the filter because the Youtube link URL had "FUCK" inside it. Special:AbuseLog/23686623. The ID of the video was gmCKcFUCKBE.
One other: Special:AbuseLog/23742552. This was tripped because the news article was in all caps and had the word "NAZI" in it, which is, today, somewhat frequently used by the news, so it would make sense that it would be part of the title of a reference in an article. EggRoll97 (talk) 13:27, 19 April 2019 (UTC)
 Done Yeah, that sort of FP has been popping up too much. Galobtter (pingó mió) 07:43, 20 April 2019 (UTC)

Prevent publishing of empty edit request

Moved to Wikipedia:Edit filter/Requested
 – * Pppery * has returned 14:59, 20 April 2019 (UTC)

Protected edit request on 14 May 2019

At Template:Edit filter warning, please change 

  }} }}}|60px|Your action has triggered the Edit Filter|link=]]

to 

  }} }}}|60px|Your action has triggered an edit filter|link=]]

because "Edit Filter" is not generally capitalized on enwiki (so "Edit Filter" -> "edit filter") and because there are multiple edit filters (so "the" -> "an"). Thanks, --DannyS712 (talk) 23:56, 14 May 2019 (UTC)

 Done — JJMC89 (T·C) 05:10, 15 May 2019 (UTC)
@JJMC89: I noticed you only did part of the requested changes - would you also be willing to change "the" to "an"? Thanks, --DannyS712 (talk) 05:12, 15 May 2019 (UTC)
Oops. Done now. — JJMC89 (T·C) 05:17, 15 May 2019 (UTC)

Setting filter 988 to disallow

Should be self explanatory from the ANI thread and the filter log. It's been enabled since April 28 with no false positives. The harassment of User:Cyphoidbomb and others is ongoing, so I'd like to set it to disallow if there are no objections. Suffusion of Yellow (talk) 21:32, 4 May 2019 (UTC)

Looks reasonable. -- zzuuzz (talk) 21:47, 4 May 2019 (UTC)
 Done. Suffusion of Yellow (talk) 00:58, 7 May 2019 (UTC)

Semi-false positives at 657

657 (hist · log)

Hi. Following up on this false positive report, which flagged adding an "incoming links" tag to a disambiguation page, I just came across a series of 25 edits ([10]) that were also flagged, where the only change was adding an afd template. Is there some way to filter out external links that are transcluded rather than directly added? Thanks, --DannyS712 (talk) 21:05, 5 May 2019 (UTC)

Translcusion alone is too much of an exclusions (esp as this isn't a blocking filter) - are the FP's mostly related to AFD though? We could exempt new text like "Article for deletion" added_lines or the like? — xaosflux Talk 22:28, 5 May 2019 (UTC)
@Xaosflux: Template:Incoming links adds external links, and that is a template that is specifically designed for dab pages, so if you want to screen out specific templates I would suggest adding that too --DannyS712 (talk) 22:50, 5 May 2019 (UTC)
@DannyS712: Here are the hits going back to February 23 and NOT matching "http" (case-insensitive). It looks like {{subst:afd1}} and {{subst:proposed deletion}} are main culprits. There are some from {{refimprove}} but that doesn't belong on a dab page. Others, like {{Discogs artist}}, are genuine external links. Do you see any other FPs? Suffusion of Yellow (talk) 00:40, 7 May 2019 (UTC)
@Suffusion of Yellow: Well, like I noted above incoming links would be a false positive (but the list doesn't go back far enough). Other false positives:
Otherwise, all good --DannyS712 (talk) 00:47, 7 May 2019 (UTC)
 Done. Allowing {{incoming links, {{subst:proposed deletion, and {{subst:afd, which I hope covers all the variants. Suffusion of Yellow (talk) 01:29, 7 May 2019 (UTC)
@Suffusion of Yellow: Thanks so much --DannyS712 (talk) 01:32, 7 May 2019 (UTC)

New disallowing filter 983

Hello, 983 will be set to disallow to implement the confirmed requirement to create portal pages per this RfC. Let me know if there are any questions. Custom error message is at MediaWiki:Abusefilter-disallowed-nonconfirmed portal creation. — xaosflux Talk 16:49, 5 May 2019 (UTC)

Has been in log only since 20190412, one possible FP found - fixed by adjusting the "suggest" link on that portal. — xaosflux Talk 16:50, 5 May 2019 (UTC)
Meh. That filter seems quite overreaction/unnecessary to me. For almost one month it logged only one action and one false positive. I am quite sure it will be disabled in the long run, but for now it should be set to disallow per the discussion. – Ammarpad (talk) 19:13, 5 May 2019 (UTC)
@Ammarpad: I think it's pretty much useless as well, but the RfC is what it is, and using yet another namespace permission and software change seems like a worse route. — xaosflux Talk 20:01, 5 May 2019 (UTC)
Would it be slower or more server-intensive? Aside from requiring more work on the part of developers for yet-another-enwiki-special-config (although admittedly ACPORTAL may be easier given ACTRIAL/ACPERM) and likewise should we undo that change, what makes the software-side change worse than checking another abuse filter? ~ Amory (u • t • c) 00:24, 6 May 2019 (UTC)
@Amorymeltzer: it is soley the yet-another-enwiki-special-config. As the first condition of this is ns=100, and edits to that ns are rare, this should rarely consume more than the 1 condition. It certainly could build upon wgArticleCreationWorkflows, and we could reject this EF request and send the RfC closer to fill out a phab request - but that seems like overkill to me. In contrast, we have 803 which performs a similar function on ns=2 that was kept in the EF. — xaosflux Talk 01:29, 6 May 2019 (UTC)
 Done — xaosflux Talk 11:40, 8 May 2019 (UTC)
@Xaosflux: Can't we use the title blacklist for this? Something like Portal:.* <errmsg=Titleblacklist-nonconfirmed portal creation|autoconfirmed> (where the message would live at MediaWiki:Titleblacklist-nonconfirmed portal creation, for consistency). — MusikAnimal talk 17:23, 8 May 2019 (UTC)
@MusikAnimal: good idea, I'll mock it up on testwiki - would certainly be "cheaper". — xaosflux Talk 18:04, 8 May 2019 (UTC)
@MusikAnimal: worked on testwiki, and I converted it here as well - thanks for the feedback! — xaosflux Talk 23:02, 8 May 2019 (UTC)

279 scope

279 (hist · log)

What's the point of 279, "repeated attempts to vandalize"? Is it only meant for when the same user goes after the same page repeatedly, or does it "watch" the user on other pages for a short time? User:2600:387:B:984:0:0:0:31 triggered thirteen filters in two minutes on a single article, including 279, but then this edit, similar to the filtered ones but on a different article, was able to happen. I don't have a clue how 279 works, since the code appears to be restricted to defining the user groups, the namespace, the user's appearance in recent contributions, and requiring the requested action to be "edit". Nyttend (talk) 02:38, 12 May 2019 (UTC)

I just had to explain this to another user. I'll recycle my response. The filter trips whenever an user (or group of IPs) unsuccessfully attempts to save an edit four times in five minutes on a single page. Could be another filter (that's the intent), could be the spam blacklist, could be that they checked the "Prompt me when entering a blank edit summary" box in their preferences but didn't leave a summary, or it could be a bug in MediaWiki or an extension that prevented saving. The idea is to catch users who try "FUCK JIMBO", then "fuck jimbo", then "fukc jimbo", then "fvck jimbo", then finally get past the filter with "f jimbo" (or whatever). In practice, it can trip for all sorts of reasons. IMO it's still valuable, but every log entry needs to be checked to ensure that it's actually vandalism. I've just renamed it to "Repeated attempts to save edit". I hope that will prevent any future confusion. Suffusion of Yellow (talk) 02:49, 12 May 2019 (UTC)
Adding: it can also trip when four different IPs edit the same page within a span of five minutes, even if all the edits save successfully. That part would be easy to "fix" by changing the throttle to "user,ip,page", but no one has ever told me if it's a bug or a feature. Suffusion of Yellow (talk) 02:57, 12 May 2019 (UTC)
Suffusion of Yellow - I would think that "user,ip,page" would break the filter and have it return no results, since it's looking for edits to the same page, by the same account, and by the same IP - where one can only either be an account or an IP. From what I've read and believe... The proper way to resolve the matter and have it so that a filter would trip if the same IP attempted the same edit to the same page over a rate limit would be to create another edit filter almost exactly like this one, but with small changes to the conditions and with the throttle set to "ip,page". Please correct me if I'm wrong anywhere. :-) ~Oshwah~(talk) (contribs) 03:06, 12 May 2019 (UTC)
@Oshwah: Last I checked (which was a while ago, so things might have changed), "user" means "user id", so the "user" throttle key for all IPs is "0". Throttling by "user,ip,page" would only fail on a registered account if the underlying IP switched between edits. Which, given the five minute span, is unlikely. Suffusion of Yellow (talk) 03:21, 12 May 2019 (UTC)
But, Daimona Eaytoy has been revamping the AbuseFilter filter extension, and a lot has recently changed about how throttling works. So he's probably the only one can answer this with certainty. Suffusion of Yellow (talk) 03:23, 12 May 2019 (UTC)
Interesting... it might be worth testing on the test-wiki to see what happens. If anything, I'm just curious to see if you're correct and if I'm wrong (which is probably much more likely... lol) ;-) ~Oshwah~(talk) (contribs) 03:35, 12 May 2019 (UTC)
Nyttend - It's meant for the same user who edits the same page more than three times within a five minute period (and where the user is not the last ten most recent contributors to the page beforehand, meaning that their previous edit attempts have been disallowed by another filter). It's a little tricky to spot how it works, but the rate limit is throttled by "user, page" meaning that the rate limit only increments if both the user and the page are the same, and an edit is attempted. It does not "follow you" from page to page; it only keeps track of how many times and how often you've tried to edit the same page. ~Oshwah~(talk) (contribs) 02:50, 12 May 2019 (UTC)
Okay, thank you. I wasn't clear if it paid attention to the page, or the editor, or the combination of them. Nyttend (talk) 03:09, 12 May 2019 (UTC)
Nyttend - No problem - always happy to help! The answer to your question above is that it pays attention to both. ;-) ~Oshwah~(talk) (contribs) 03:34, 12 May 2019 (UTC)
Hello everyone! Yes, there have been a few changes to how throttling works, although they were mostly about the backend implementation. Most notably, the 3 form fields for throttle weren't previously validated, so it's been a major PITA to add validation and remove any junk that was inserted in the database. Actually, this is still ongoing at T209565, but that's another story. For this specific case, Suffusion of Yellow is right: "user" throttles by user ID, so all IPs are counted as a single user, whereas "ip" throttles by the actual IP (and that works for registered users, too). That said, I'm unsure if that should be considered a bug or a feature. Using the IP for anonymous users with the "user" option would probably be more intuitive, since different IPs are effectively different users. OTOH, there might be situations where you want all IPs to be counted as a single entity, and throttling by "user" is currently the only way to do that. I sent a patch for this at T211101 some time ago; some of the things I wrote in the task description aren't actually true, but point 1 (i.e. "user" using 0 for IPs) still is. At any rate, I think fixing that should wait for other major overhauls, mainly gerrit:478232. Should you have any questions, feel free to ask but please ping me. --Daimona Eaytoy (Talk) 07:55, 12 May 2019 (UTC)

MediaWiki bug tripping page-blanking filters

Tracked in Phabricator
Task T223023
Resolved
Resolved
 – Bug was resolved weeks ago --DannyS712 (talk) 17:22, 1 June 2019 (UTC)

A mobile editing bug is causing some users to blank out every section except the one they are editing. This, in particular, tends to trip 957 (hist · log). There probably isn't much we can do about it from here (disabling the filter would cause the corrupt page to get saved), but please assume good faith when it comes to "vandals" who are repeatedly doing this, particularly when user_mobile is set. Suffusion of Yellow (talk) 22:14, 11 May 2019 (UTC)

I added a note to the warning of 957. Galobtter (pingó mió) 10:05, 12 May 2019 (UTC)

Edit Filter Helper for EggRoll97

 Not done as this request has failed to gain a consensus of support, it is being closed without action. — xaosflux Talk 18:04, 5 June 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)

I believe I've fixed the problems that..let's say..worried, others in my last request. I'd like to request this again. For anyone not familiar with the previous requests, I'm requesting edit filter helper to assist with private filter false positives.

As per the requesting process, here are the notifications for the participants (and closing sysop) of the last request: (Abel excluded, as he retired, no reason to ping him)

@Serial Number 54129: @Nihlus: @Xaosflux:

Previous request

Thank you for taking the time to consider my request, EggRoll97 (talk) 00:59, 1 June 2019 (UTC)

  • Oppose I am still not seeing much progress on the concern I had in the previous request. I would have expected you to wait at least six months before trying this again, so this seems premature. If this fails again, I would suggest waiting until December before trying to get the rights again. Nihlus 21:12, 31 May 2019 (UTC)
    • Comment The concerns raised (by you) were that I was already handling another new tool, and the other was my general "lack of experience in various wiki areas". I believe I have definitely taken on board and corrected all suggestions regarding the tool that have been given to me. On the lack of experience, I would love some clarification, as the reasoning seemed broad. I wouldn't presume to say that I have become the "perfect Wikipedian" (no one has), but I think I've definitely improved highly from the previous request. EggRoll97 (talk) 02:43, 1 June 2019 (UTC)
  • Thoughts: While helping at EF/FP is always welcomed, I don't see that eo ipso rising to the level of "demonstrated need" expressed in the EFM creation discussion. This was supposed to be a rare role that fits a quite small niche gap in abilities for a small handful of individuals. It was never intended to be similar to NPP or rollback where they allow one to help in an overloaded area. CrowCaw 17:12, 5 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New script for examining user contributions

Hi. I've made User:DannyS712/Examine edits to easily navigate to Special:AbuseFilter/examine already preloaded for a user. It adds a link to user contribution pages next to the "filter log" link. Hope this is useful --DannyS712 (talk) 22:39, 12 June 2019 (UTC)

Set filter 987 to disallow

For background see Wikipedia:Edit filter/Requested/Archive 13#Prevent publishing of empty edit requests and other old discussions linked from there.

Filter 987 has been enabled for three weeks now and has perfect record; zero false positive. Virtually all the edits it trapped were reverted, in the few cases were they were not reverted (answered with templated responses) they're still meaningless, clutter talkpages, and waste editors' time in responding to them. To save time of editors wasted in reverting this junk every time it gets saved, this filter should be set to disallow edits that tripped it. People should be told empty edit request cannot be saved; either write something or discard the edit. Thanks. – Ammarpad (talk) 20:46, 14 May 2019 (UTC)

@Ammarpad: Sorry about that! Of course it's pointless to just log these. I tried writing the warning message several times, hated the results, and moved on to something else. I would still like to try a warn-only filter first, and only set to disallow if too many people ignore it. Anyone else want to have a go at the message? Suffusion of Yellow (talk) 23:43, 14 May 2019 (UTC)
@Suffusion of Yellow: sure, I'll give it a crack --DannyS712 (talk) 23:45, 14 May 2019 (UTC)
@Suffusion of Yellow: User:DannyS712/Abusefilter-warning-empty-edit-request --DannyS712 (talk) 23:52, 14 May 2019 (UTC)
@DannyS712: Better than what I came up with. But, I'm not sure we should mention the edit filter in the first line, or perhaps at all (except for the WP:EF/FP/R link). A good number of people tripping this filter have never edited Wikipedia before, and the exact mechanism by which the message was sent is of no interest to them. It's more important in other filters, where they need to know that a human being is not accusing them of vandalism. What if we went with something more like Mediawiki:abusefilter-unexplained-removal for the first line:
Or does that seem condescending? Suffusion of Yellow (talk) 00:55, 15 May 2019 (UTC)
@Suffusion of Yellow: I mean, it does appear a bit condescending. I borrowed the start of the phrasing from MediaWiki:Abusefilter-warning-persondata/MediaWiki:Abusefilter-warning-EL-in-disambiguation/MediaWiki:Abusefilter-warning-removal-disambiguation, but I'm not very attached to the need to mention the edit filter at the start. --DannyS712 (talk) 01:26, 15 May 2019 (UTC)
@Suffusion of Yellow: any updates on when this might be enabled with a warning? --DannyS712 (talk) 22:18, 19 May 2019 (UTC)
@DannyS712: An admin still needs to create the warning page. I was hoping for a third opinion on what should go on the first line. If any passing admin thinks that either Danny's version or mine (above) is good enough for now, go ahead and create MediaWiki:Abusefilter-warning-empty-edit-request with whichever one you prefer, and I'll flip the switch. Suffusion of Yellow (talk) 22:24, 19 May 2019 (UTC)
@Suffusion of Yellow: I haven't been following this too close - but if the only thing holding you up from activating this is the message - then you can pick, drop an edit request at MediaWiki talk:Abusefilter-warning-empty-edit-request and we'll do it. — xaosflux Talk 23:37, 19 May 2019 (UTC)
@Xaosflux:  Done. Suffusion of Yellow (talk) 05:34, 20 May 2019 (UTC)
And @Ammarpad:,  Done. Warning enabled. Thanks to DannyS712 for help with message (and prodding me into action). Suffusion of Yellow (talk) 19:08, 20 May 2019 (UTC)
@Suffusion of Yellow: No problem. Thanks for the filter --DannyS712 (talk) 19:10, 20 May 2019 (UTC)

Incomplete filter?

@Ammarpad and Suffusion of Yellow: Why was Special:Diff/898798351 not caught by the filter? * Pppery * survives 00:25, 26 May 2019 (UTC)

@Pppery: Is that the correct link? It's to a deleted page. Suffusion of Yellow (talk) 02:32, 26 May 2019 (UTC)
Yes, that was the correct link; it was the creation of File talk:Interface-protection-shackle.svg containing nothing but an empty edit request, since deleted by JJMC89 as a test page. * Pppery * it has begun... 02:34, 26 May 2019 (UTC)
If JJMC89 (or another admin) wants to email me the page (or undelete it, I have it watched) I'll take a look. Suffusion of Yellow (talk) 02:43, 26 May 2019 (UTC)
The only edit to the page contained: 
== Protected edit request on 26 May 2019 ==
{{edit fully-protected|File:Interface-protection-shackle.svg|answered=no}}
 [[User:Kenj115188|Kenj115188]] ([[User talk:Kenj115188|talk]]) 00:20, 26 May 2019 (UTC)
— JJMC89 (T·C) 06:34, 26 May 2019 (UTC)
@Suffusion of Yellow: It also failed on Special:Diff/898846118, which it should have caught --DannyS712 (talk) 08:24, 26 May 2019 (UTC)
@Pppery: This example should have been caught. The way filters work on page creations is slightly different from the way they work on existing pages, and I didn't account for that. If you think it's really all that common for people to make edit requests on redlinked talk pages, I can try to fix it.
@DannyS712: IMO, the filter was working as intended there. The user put some gibberish in the Subject/headline field, and the filter assumes that if there's anything but the boilerplate "Protected edit request on..." text there, it may be just because the user put their request in the wrong box, so a human should decide if it's an actual request. Suffusion of Yellow (talk) 02:56, 27 May 2019 (UTC)
I have no idea how prevalent empty edit page creations are; I just happened to notice that one while doing some unrelated lurking after filing another (non-empty) edit request, so can't properly judge on whether it is worth fixing, and the fact that many of them are deleted makes it difficult for a non-admin to do so. * Pppery * it has begun... 03:00, 27 May 2019 (UTC)
I agree there's no need to check for the edit on non existing pages. It doesn't happen frequently like on existing pages and such edits would be deleted anyway as test pages or g8. – Ammarpad (talk) 07:01, 27 May 2019 (UTC)
@Suffusion of Yellow: What about Special:Diff/898998648? --DannyS712 (talk) 07:27, 27 May 2019 (UTC)
@DannyS712: The user was already autoconfirmed. You answer a lot of requests; do you see many autoconfirmed users making this mistake? I can raise the limit to extendedconfirmed, I guess. Suffusion of Yellow (talk) 22:15, 27 May 2019 (UTC)
@Suffusion of Yellow: yes, sometimes they do - maybe use filter 1 to test how often confirmed but not extended confirmed usesr make the mistake? --DannyS712 (talk) 22:19, 27 May 2019 (UTC)
@DannyS712:  Done. I didn't test it first (apart from the usual Special:AbuseFilter/test sanity checks of course...); the rest of the pattern wasn't changed and we haven't had any complaints about false positives. I'm less worried about the effects of an FP on a somewhat experienced user; they are more likely to say "Your stupid filter is broken, please fix it" than "Your stupid website is broken and a waste of my time, I'm outta here" if the filter flags a non-empty request. Suffusion of Yellow (talk) 22:25, 28 May 2019 (UTC)
@Suffusion of Yellow: !("extendedconfirmed" in user_rights) & means that admins will not be exempt, increasing the number of conditions checked overall. Can I suggest also restricting admins? --DannyS712 (talk) 00:17, 29 May 2019 (UTC)
@DannyS712: Sysops and bots do have the extendedconfirmed user right. See, for example Special:AbuseLog/24084226. Confusingly they are not, typically, in the extendedconfirmed user group. So there are two ways to say the same thing:
  • !contains_any(user_groups, "extendedconfirmed", "sysop", "bot")
  • !("extendedconfirmed" in user_rights)
I like the second because it's simpler, and won't need updating if we create another group of users with EC rights. Suffusion of Yellow (talk) 00:25, 29 May 2019 (UTC)
@Suffusion of Yellow: apologies, I misunderstood --DannyS712 (talk) 00:28, 29 May 2019 (UTC)

Expansion?

Hi. I have also been coming across "edit requests" which are not empty as defined by this filter because they only contain the first part of the edit request preload. Specifically, the added_lines is 


== Semi-protected edit request on 12 June 2019 ==

{{edit semi-protected|Vijay Deverakonda|answered=no}}
{{subst:trim|1=
<!-- State UNAMBIGUOUSLY your suggested changes below this line, preferably in a "change X to Y" format. Other editors need

and since the preload is cut off, the filter doesn't catch these. Can someone with access to the testing interface take a look at whether tweaking line 12 and removing line 13 from the filter (copied below) would create any new false positives? By changing line 12 to just be part or all of the html comment, and removing 13, I think these types of "empty" requests could be caught too. 

"<!--.*?-->\n+" +
"\}\} ~~~~\n*$"

Pinging Suffusion of Yellow, since they are most familiar with this filter. Thanks, --DannyS712 (talk) 06:38, 12 June 2019 (UTC)

Ideally, it should also catch edit requests such as Special:Diff/901473450 --DannyS712 (talk) 07:12, 12 June 2019 (UTC)
@DannyS712: I checked all 1 hits from the few days back in April when it was just logging all protected-edit requests, and I couldn't find any examples of this. So I don't think it's all that common. IMO, if this filter is made too "aggressive" it will start flagging people who are making requests, but just mangling the form in some creative way. Special:Diff/901473450 was just someone ignoring the warning, and clicking "Publish" a second time. See that IP's filter log. Have you seen any FPs at all from this filter? Maybe it's time to, as the section heading implies, actually set it to disallow. Suffusion of Yellow (talk) 18:18, 13 June 2019 (UTC)
@Suffusion of Yellow: Oh, okay. And yes, I agree that it should be set to disallow soon --DannyS712 (talk) 20:53, 13 June 2019 (UTC)

894 - equal to any using regex?

Hi. I just came across 894 (hist · log). The first line is page_namespace rlike "^(0|118)$" & (. Is there a reason that this comparison is done using a regex string comparison, rather than equals_to_any(page_namespace, 0, 118) & (? Just wondering, since it seems less efficient to convert an integer into a string and do this regex rather than using the built in equals_to_any. Thanks, --DannyS712 (talk) 03:38, 19 June 2019 (UTC)

My guess is that the regex-matching means there's always one condition, while an equals_to_any(page_namespace, 0, 118) would be a worst-case of two conditions (don't quote me on that). --qedk (t 桜 c) 05:34, 19 June 2019 (UTC)
@QEDK: but doesn't the regex or (|) mean that the cases are the same? Equals to any is the same as doing a = b or a = c, but it is numerical comparison instead of strings --DannyS712 (talk) 05:46, 19 June 2019 (UTC)
Regex-matching would just mean matching the entire string to the regex, so the entire string is compared at the same time, instead of two different times, page_namespace == 0 and then if that fails, page_namespace == 118. --qedk (t 桜 c) 05:51, 19 June 2019 (UTC)
Oh, that makes sense. Can anyone (maybe requires access to logstash?/something else?) see what is more efficient? --DannyS712 (talk) 05:54, 19 June 2019 (UTC)
I know @Daimona Eaytoy: has access, I don't know if there's anyone else. --qedk (t 桜 c) 05:59, 19 June 2019 (UTC)
@QEDK and DannyS712:, no, the reason is that equals_to_any was only relatively recently added as a function, so before that rlike was used to save conditions. Definitely, rlike should be replaced with equals_to_any, which does only use one condition, but it is not particularly urgent. Galobtter (pingó mió) 07:47, 19 June 2019 (UTC)
Woop, that's good to know. Good I wasn't quoted afterall. --qedk (t 桜 c) 07:53, 19 June 2019 (UTC)
Just to absolve myself of this crime, I will state I saw the examples on condition limits and observed that each lookup in the argument lists (or better called, invocations) counts as one condition, so this essentially looked the same to me. Noting that, I personally deal only with seeing edit filter logs and not making them. --qedk (t 桜 c) 08:00, 19 June 2019 (UTC)
@Galobtter: Well, given that it isn't urgent, I'm not going to file a bunch of "edit requests", but I've started keeping track (at User:DannyS712/sandbox2) of filters that should have their syntax updated. Thanks for explaining --DannyS712 (talk) 08:10, 19 June 2019 (UTC)
Galobtter is right. I added equals_to_any last year, and its main use case is, in fact, to check the namespace against a given list. It avoids the overhead of using regexps, and equals_to_any(val,a,b,c) is the same as val===a | val === b | val === c, but taking one condition instead of 3, and a bit more readable. Note that, in this case, the performance is roughly identical. This is just one of the many cases where more condition doesn't mean worse performance. Using rlike, instead, could be a very little bit slower. --Daimona Eaytoy (Talk) 09:24, 19 June 2019 (UTC)

New tool for testing filter changes

I've always been bothered by the fact that Special:AbuseFilter/test doesn't allow batch testing against old filter hits, so it's easy to break a filter without knowing it. So, I created User:Suffusion of Yellow/batchtest-plus (source). This script allows you to test a pattern against 100 old hits, with a single click. Comments, and suggestions for improvement, are welcome. Suffusion of Yellow (talk) 00:44, 11 June 2019 (UTC)

Suffusion of Yellow, very very nice! I generally manually test on a few past filter hits using examine when making most filter edits, but this is certainly much more convenient, and should save time. Also, testing against 100 hits would allow seeing how much a change to reduce false positives reduces the amount of abuse caught. Galobtter (pingó mió)
@Galobtter: Thanks! Glad to know at least person found it useful. I'd still like to make it faster, but don't like the idea of flooding the servers with requests as fast as the browser will send them. MusikAnimal or Daimona Eaytoy, would either of you know what an acceptable rate limit on abusefiltercheckmatch requests would be? Right now I'm limiting it to five requests per second, and never making concurrent requests. Am I being overly cautious? If you don't know, who do I ask? Suffusion of Yellow (talk) 18:30, 13 June 2019 (UTC)
Suffusion of Yellow, per the general mw:API:Etiquette, you should be perfectly fine if you wait for the one request to finish before sending a new request, such that you are never making more than one request at the same time, but on the scale of the WMF servers, I'd think being sent 100 requests at once (or over a few seconds) vs over 20 seconds isn't going to be much of a difference; the issue would more be about making a lot of requests over minutes and hours. (also, you should set a Api-User-Agent header, so that in case issues are caused you can be contacted - see m:User-Agent_policy) Galobtter (pingó mió) 19:41, 13 June 2019 (UTC)
I also agree with Galobtter, although TBH I don't know how heavy that API module can be (I guess it strongly depends on the input). I'd also love to bring this feature inside AbuseFilter, but I think I found it to be non-trivial the last time I looked. --Daimona Eaytoy (Talk) 08:28, 14 June 2019 (UTC)
Thank you Suffusion of Yellow! I think this will be very useful. I also concur with Galobtter. In general, I would not worry too much about flooding the servers. Twinkle for instance can fire off hundreds and hundreds of POST requests at a single time (batch delete, unlink, etc.), and the worse that happens is the servers reject a few of them. In this case you're not even doing POSTs, and 100 requests isn't that many, so I'd say make it as fast as you can :) — MusikAnimal talk 18:18, 14 June 2019 (UTC)
@Galobtter, Daimona Eaytoy, and MusikAnimal: Thanks for all your advice! I've removed the rate limit. I tried sending all the request at once, but some of them would timeout without any even an error response. So, instead I've limited it to 10 parallel requests, which seems to work, and finishes in a few seconds, usually. Let me know if you have any problems, and I can tweak the setting, or make it user-configurable. Suffusion of Yellow (talk) 19:41, 20 June 2019 (UTC)

Set filter 993 to disallow

I was about to turn this off, thinking they had gone away. Seems not. I've already set it to disallow, as the LTA was just active, and there have been no FPs in over a month. If anyone objects, please revert. Suffusion of Yellow (talk) 21:08, 29 June 2019 (UTC)

Suffusion of Yellow, the reason it seemed they had gone away was because I had blocked Special:Contributions/181.21.128.0/17 for a month - probably should have told you. You can probably merge to 906 . Galobtter (pingó mió) 08:55, 30 June 2019 (UTC)
@Galobtter: LOL, that would do it. They've edited from a few other ranges in the past, but if they don't show up again in a few days, I'll merge. Suffusion of Yellow (talk) 17:17, 30 June 2019 (UTC)

False negatives

384 (hist · log)

Can I suggest that \bass\s?holes?\b be replaced with \b(ass|butt)\s?holes?\b? See Special:Diff/902637086. I don't know if this would cause any false positives, since I can't check, but I doubt that it would. Thanks, --DannyS712 (talk) 06:51, 20 June 2019 (UTC)

I'm very tired right now and so not gonna trust myself with regex, but just noting that "asshole" is used in twice as many articles as "butthole", so not anticipating a problematic number of false positives. Someguy1221 (talk) 07:17, 20 June 2019 (UTC)
@DannyS712 and Someguy1221: Testing in 839 (hist · log). Since that's a rather expensive filter for just one word, now would be a good time to test other possible additions to 384. Any suggestions? I'd like to avoid memes or anything else that will go "stale"; 614 is better fit for those. Suffusion of Yellow (talk) 20:54, 25 June 2019 (UTC)
@Suffusion of Yellow: Maybe expand the ass to include when it doesn't have \s?holes\s?? "__BLP__ is a pain in the ass" doesn't trigger it. --DannyS712 (talk) 20:58, 25 June 2019 (UTC)
@DannyS712:  Done Checking for (dumb)?ass. With >10K uses in mainspace, I'm fairly sure that there will way too many FPs for plain "ass", but I'm curious anyway. Suffusion of Yellow (talk) 21:19, 25 June 2019 (UTC)
@Suffusion of Yellow: (?:dumb)?ass matches dumbass (but not dumb ass) as well as just plain ass, which I don't think you wanted. can I suggest dumb\s?ass? --DannyS712 (talk) 21:21, 25 June 2019 (UTC)
@DannyS712: I mean to check to for both "dumbass" and plain "ass", for a little while, in case I'm wrong about the FPs for plain "ass". If there are too many FPs, I'll change it to your suggestion. Suffusion of Yellow (talk) 21:29, 25 June 2019 (UTC)
@MJL and QEDK: Also added some "shit"-related tests, as you suggested in the other thread. I modified the regex so as not to overlap with 384 during testing. Suffusion of Yellow (talk) 23:40, 25 June 2019 (UTC)
680 (hist · log)

Can I suggest that [🄀-🇿🌀-🙏🚀-🛳☀-☄☇-☿♃-♬♰-✒✙-✯✱-➿] be replaced with [🄀-🇿🌀-🙏🚀-🛳☀-☄☇-☿♃-♬♰-✒✙-✯✱-➿🤪🤙]? See Special:Diff/903247214. I don't know if this would cause any false positives, since I can't check, bu tI doubt that it would. Thanks, --DannyS712 (talk) 16:50, 24 June 2019 (UTC)

DannyS712 - thanks for spotting! Rather than adding individual emojis, I've added the range U+1F90D to U+1F9FF (see Unicode blocks) per Template:Emoji (Unicode block) to update things till Unicode 12. Galobtter (pingó mió) 17:42, 24 June 2019 (UTC)

AbuseFilter/384

Renamed this header btw from False Negative?. –MJL ‐Talk‐☖ 23:37, 7 June 2019 (UTC)

A recent vandal ([11]) has brought to my attention that this did not trip any of our edit filters. I'm not well versed in this process, but could we edit 384 with the following code to catch this in the future? 

\b(horse|dog)?shit(|s|ti?er|t?y|t?ing)?\b

Hopefully, I am not making a terrible suggestion here. –MJL ‐Talk‐☖ 07:49, 17 May 2019 (UTC)

For quick reference, 384 currently catches \b(horse|dog)?shits?\b. I would say that I suspect some of the new things to catch would be prone to false positives. "Shitty" appears quite a bit in titles and quotes. What happened here was the vandal actually worked the edit filter until he found the sweet spot where his language wasn't bad enough to trip 384, but his deletion wasn't big enough to trip 12. Someguy1221 (talk) 08:19, 17 May 2019 (UTC)
Possibly set to log-only and see what we're catching first then? bull seems to be a no-brainer addition imo, given the other two are up there. --qedk (t 桜 c) 08:22, 17 May 2019 (UTC)
Great addition qedk! Also, I'm fine with a log-only if we want to play it safe. –MJL ‐Talk‐☖ 10:05, 17 May 2019 (UTC)
I don't think bull is a no-brainer addition - bullshit has way more legitimate uses than horseshit or dogshit, and so more scope for FPs. Galobtter (pingó mió) 14:56, 18 May 2019 (UTC)
What are the chances an un-confirmed editor is using any of these words constructively, hmmm. Can't say for sure but instincts tell me rarely. --qedk (t 桜 c) 10:23, 20 May 2019 (UTC)
Yeah, if someone is working around a filter, the solution is blocking them, really, because if someone tries enough they certainly can always get around the filter. Galobtter (pingó mió) 14:56, 18 May 2019 (UTC)

Edit filter 51

Hi everybody! I'm creating this discussion to give everyone a heads up that an update I made about 25 minutes ago to edit filter 51 included a typo that caused a bunch of edits to be flagged as positive hits. This was resolved with a subsequent update about 24 minutes later. Any edits and actions that were flagged as a positive hit between 14:17, 27 July 2019 and 14:41, 27 July 2019 are most likely going to be false positive hits and can be acknowledged and closed as 'fixed' if reported to the false positives noticeboard. My sincere apologies are owed to anyone that this issue affected or caused any inconvenience upon. If anyone has any questions or further concerns, please feel free to message me here (just ping me in your response so that I'm notified) or on my user talk page, and I'll be happy to address and answer them. :-) Best regards - ~Oshwah~(talk) (contribs) 14:55, 27 July 2019 (UTC)

Expanding 664

664 (hist · log)

Can I suggest that it be expanded to include the draft namespace, not just the main namespace? Since non-confirmed editors can't create pages in mainspace, their test pages are generally drafts. See this page creation (Special:AbuseFilter/examine/1162056102) with the word "Hello". Thanks, --DannyS712 (talk) 13:25, 10 July 2019 (UTC)

DannyS712 - This would be easy to implement. MusikAnimal is the creator and maintainer of this edit filter. Unless he responds and explicitly objects to this proposal, I'm perfectly okay with implementing this edit filter to also look in the draft namespace as a condition. Draft namespaces shouldn't be used for testing in the manner that the filter looks for with content, so the current test warning provided to users as an action from this filter would be accurate and shouldn't cause any harm. I'm going to go ahead and implement the change you proposed; MusikAnimal, you are free to revert the change that I make without my permission or input beforehand; just respond here (ping me so that I'm notified) with your objection so that I know and can understand your thoughts. :-) Cheers - ~Oshwah~(talk) (contribs) 16:40, 27 July 2019 (UTC)
 Done. ~Oshwah~(talk) (contribs) 16:44, 27 July 2019 (UTC)

Whitelisting in filter 247?

I watch the "added email address" tag, and I've noticed a few false positives the past couple days on WP:Files for discussion where people mention that they've contacted permissions-en@wikimedia.org and their edit gets flagged for adding an email address (example). If Special:AbuseFilter/247 has a way of excluding specific addresses, would it make sense to whitelist *@wikimedia.org? If it doesn't have that, would that be a worthwhile addition? Might be an uncommon enough need that it isn't worth doing, but figured I'd ask. creffett (talk) 01:05, 21 July 2019 (UTC)

Creffett - With the way that the edit filter is currently coded, it is set to check if the current edit being made is to the mainspace or the Wikipedia namespace in one condition. It currently does not have separate conditions which allow exceptions only if the current change is being made to the Wikipedia namespace. Ideally, we should still flag edits made to the mainspace that add email addresses - even if they include "@wikimedia.org"; they don't belong in the mainspace at all. However, I think that you have a good thought here. I would have to implement this by separating the namespace check condition, and adding an exception like this only if the namespace being edited is the Wikipedia namespace. It shouldn't be too hard to do... ~Oshwah~(talk) (contribs) 16:53, 27 July 2019 (UTC)
Oshwah Well, glad to hear I'm not totally off base. I know the filter is private, but I'd definitely be interested in helping if there's anything I can do. creffett (talk) 01:07, 29 July 2019 (UTC)

Filter 320

Hello. I have just looked at filter 320, and noticed that it checks if the page title includes "Mother insult". However, Mother insult is a redirect (seemingly since 2010) to Maternal insult. Should it be changed? Edible Melon (talk) 10:48, 28 July 2019 (UTC)

@Edible Melon: CC @MusikAnimal, who made the edit that introduced the page_title check - Special:AbuseFilter/history/320/diff/prev/19804 --DannyS712 (talk) 12:12, 28 July 2019 (UTC)
MusikAnimal only updated some deprecated terms. The same check has been there since before the page move in 2010. I've updated it. -- zzuuzz (talk) 13:03, 28 July 2019 (UTC)
@Zzuuzz: Thanks for updating it --DannyS712 (talk) 05:28, 4 August 2019 (UTC)

EFH for DannyS712 (2)

Per the consensus below, access is added. — xaosflux Talk 15:49, 7 August 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Earliest closure has started. (refresh)
Previously requested at Wikipedia:Edit filter noticeboard/Archive 5#EFH right for DannyS712

Hi. I'd like to request edit filter helper again. Since my previous request, I have continued helping out at the false positives report page, but have also gotten more active in other edit filter-related business. Recently, I proposed a new filter that is now logging at 632 (hist · log), and in the past have requested edits to filters after manually scanning through log entries or recent changes, and this would allow me to use the testing interface. See, most recently, #Expanding 664 above, but also Wikipedia:Edit filter noticeboard/Archive 5#False negatives (the first part currently logging for testing at 839 (hist · log), the second incorporated into 680 (hist · log)), Wikipedia:Edit filter noticeboard/Archive 5#Semi-false positives at 657, and Wikipedia:Edit filter/False positives/Archive 102#Tiptoeslightly (implemented at 384 (hist · log)). Users without access to private filters can request to view them on an individual basis (WP:PRIVATEFILTER), and Oshwah has shown me a version of 51 (hist · log), but it has changed since then, meaning that I couldn't deal with Wikipedia:Edit filter/False positives/Reports#199.250.32.53 by myself. In short, I'm requesting this right primarily to access the testing interface, so that I can see the effect of changes before I propose them, and so that I can view private filters to respond to false positives and related.

Per Wikipedia:Edit filter helper#Process for requesting, I'm now notifying users who participated in the previous discussion. Thanks, --DannyS712 (talk) 05:20, 4 August 2019 (UTC)

All notified, see [12] DannyS712 (talk) 05:27, 4 August 2019 (UTC)
information Administrator note prior request closed as no-consensus to add in January 2019. — xaosflux Talk 05:38, 4 August 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 960

960 (hist · log)

Can I suggest that action = 'delete' be excluded? Any admin can delete a user script, and I assume the intent of this was to log edits by interface admins. Just an idea --DannyS712 (talk) 04:39, 8 August 2019 (UTC)

Sorta Done: @DannyS712:, changed it to only match on actual edits, as that was the original intent. — xaosflux Talk 13:10, 8 August 2019 (UTC)
@Xaosflux: Thanks. However, can I suggest that the restrictions check be put first? It'll be the most effective filter. Also, unless the filter is intentionally excluding edits made by interface editors, etc., the check on user groups containing sysop seems redundant. Thanks, --DannyS712 (talk) 08:15, 9 August 2019 (UTC)
@DannyS712: "restrictions"? Some of the checks are cheaper then others, of those we usually but the ones that avoid the most edits first. (Some of this is mooted by efficiency improvements in the abuse filter parser). Checking things like "namespace" is cheaper then a regex - so it is normally first, especially if it is one with low edits (such as ns:2). Also, filter 960 doesn't have conditions about user groups - I think you're getting filters confused. — xaosflux Talk 11:08, 9 August 2019 (UTC)
@Xaosflux: indeed - I was looking at 942 (hist · log). Sorry for the confusion --DannyS712 (talk) 20:00, 9 August 2019 (UTC)

The right way to create a new (edit) Tag？

Could any wise friends on this page kindly point me to where should I go to if I want to apply for a new Tag to be activated for en-Wiki (or global)? I built a tool that I want to have something similar to tags like STiki to mark all edits created by that tool. Previously discussed on Wikipedia_talk:Tags#How_to_(apply_to)_add_new_tags?

An admin (@Graham87:) expressed interest to help create one, but neither of us know what to do and what's the right process. Please kindly advise. Thank you!

Xinbenlv(t) please notify me with {{ping}} 06:41, 13 August 2019 (UTC)

@Xinbenlv: probably asking here is the best option, since admins and edit filter manager are the only ones that can create tags, and edit filter managers are probably more familiar with them. But, you'll need an admin to create the relevant messages. To answer your other questions, tags can only be created for enwiki (as far as I know global tags come from either the core ChangeTags::definedSoftwareTags, an extension (like mass message) or through a global abuse filter). To create a tag, someone with the rights needs to go to Special:Tags. At the top there is a field to create a new tag, and all you need is a key for it. Then, an admin should create MediaWiki:tag-$name and MediaWiki:tag-$name-description for the tag to have a proper name and description (but these aren't technically necessary). Hope this helps --DannyS712 (talk) 07:13, 13 August 2019 (UTC)
@DannyS712: thank you! @Graham87:, it seems DennyS712 gave a thorough instruction, could you help us create the tag with the instructions from provided by DennyS712, if you see it fit? Xinbenlv(t) please notify me with {{ping}} 09:12, 15 August 2019 (UTC)
@Xinbenlv and DannyS712: I've created it as "WikiLoop Battlefield" with the title at MediaWiki:Tag-WikiLoop Battlefield and the description at MediaWiki:Tag-WikiLoop Battlefield-description. Graham87 10:34, 15 August 2019 (UTC)
@Graham87: Can confirm that it is working - Special:Diff/910915523 and Special:Diff/910915644 are both tagged (I manually tagged them while editing). Can an admin or EFM please remove the tags from those edits? Thanks, --DannyS712 (talk) 10:51, 15 August 2019 (UTC)
 Done removed. — xaosflux Talk 12:05, 15 August 2019 (UTC)
Thank you @Graham87:!. Hi @DannyS712: my next question is, how did you apply tags? In particular, I tried
None of these seem to be able to add Tag to the edit. Can you help me understand what's the best way to apply the tag with the URL? Xinbenlv(t) please notify me with {{ping}} 12:08, 15 August 2019 (UTC)
Since you are here @Xaosflux:, could you help me understand how to do it? Xinbenlv(t) please notify me with {{ping}} 12:09, 15 August 2019 (UTC)
@Xinbenlv: generally client-requested tags are made as part of your edit request when using the api, not the webui. Is your new custom tag using the API? See also mw:API:Tag. — xaosflux Talk 12:53, 15 August 2019 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_5&oldid=1092677781"