Wikipedia:Edit filter/Requested/Archive 13

Archive 10Archive 11Archive 12Archive 13Archive 14Archive 15Archive 20

Scam phone number

Transmania hoax (redux)

@Jauerback: The filter can match "Transmainian". But 260 contains certain exceptions, intended to reduce false positives, that prevented it from matching this edit. So maybe "Transmania" should be moved to a more aggressive filter, but I'm not sure which one. 614 would be a possibility, but that's private, and this is mostly drive-by vandalism, so it should ideally be in a public filter. @Crow: Any ideas? Suffusion of Yellow (talk) 19:35, 23 December 2018 (UTC)
  • Yes 260 matched the string but took no action due to other conditions. 614 might be the right place for that. It is private but for the nature of this one, it does meet the definition for the filter, as this is likely not a single person doing this, as a quick google search reveals. CrowCaw 17:43, 24 December 2018 (UTC)
  • Added to 614 after more false-negatives. CrowCaw 22:03, 6 January 2019 (UTC)

Update monitored words

  • A few months back "chode" seemed to be the vandalism word of choice. I'm seeing a fair bit of the addition of "chungus", a relatively new meme (this example came up as soon as I started Huggle today, which might want monitoring. Furthermore, I've noticed that before Alex Jones got banned from all his social media platforms a few such as YouTube and Facebook started citing Wikipedia directly which led to a now-deleted because he's been banned rant about Wikipedia being part of the "globalist plot". Since then I've seen a few instances like this example (the second Huggle diff I saw today) where words like "government" are replaced with "illuminati". Perhaps the edit filter can be modified to combat this kind of stuff or at least tag it? SITH (talk) 21:05, 8 January 2019 (UTC)
    I already added "big chungus" to Special:AbuseFilter/614 (which disallows the edit) a few hours before your comment. Tracking all new additions of "Illuminati" and some stuff at Special:AbuseFilter/953. Galobtter (pingó mió) 04:28, 9 January 2019 (UTC)

Demonym extraneous addition vandal

There's an IP hopper / SPA master who seems to be adding extraneous markup to demonyms e.g. piping links to European Americans when not needed. They also seem to enjoy inverting nationalities of parents (example). Could this be tackled with the filter? Thanks, SITH (talk) 20:12, 9 January 2019 (UTC)

Edit: example diffs of extraneous markup in link piping here, here and just changing demonym nationalities here. Thanks, SITH (talk) 20:16, 9 January 2019 (UTC)
Those all look difficult to impossible for a filter to deal with - edit filters cannot determine if piping is unnecessary as it doesn't know where a piped linked redirects to. Galobtter (pingó mió) 18:07, 11 January 2019 (UTC)

Add "Fixed" to canned edit summary filter

""Fixed" on its own gets thrown around a lot by vandals. [Username Needed] 11:22, 17 December 2018 (UTC)

Back in mid-2018, GameZone was deleted and unlinked. People occasionally add this to articles, making it require re-unlinking. A filter to warn people that they shouldn't be linking it(with a friendlier message than usual, they are good-faith edits) would prevent this. [Username Needed] 09:26, 7 January 2019 (UTC)

What about this:
!("confirmed" in user_groups) &
article_namespace == 0 &
removed_lines irlike: "GameZone" &
added_lines irlike: "[[GameZone]]"

[Username Needed] 12:24, 14 January 2019 (UTC)

And this for a warning message. [Username Needed] 12:44, 14 January 2019 (UTC)

I agree with Crow Galobtter (pingó mió) 09:04, 17 January 2019 (UTC)

Audiovisual Communicators, Inc. and variants

  • Task: Tag edits containing the word and variants thereof.
  • Reason: It's a recurring hallmark of long-term abuser Bertrand101, who has been falsely attributing said company to a number of made-up or unrelated radio networks in the Philippines. Flagging such edits should help with keeping this guy's antics at bay or at least slow him down, as this would bring him to the attention of concerned admins. Blake Gripling (talk) 09:06, 20 January 2019 (UTC)

Switching text from Israel to Palestine or Indian to Pakistan

Task Add a tag when text is switched between Israel to Palestine (or vv) or India to Pakistan (or vv). This would apply to article space only (and not to article talk pages). A separate filter for each would be best as the ARBPIA filter could also block IPs from doing this.

Reason These switches are a very common low level breach of ARBPIA and ARBIP and not easy to spot. This would aid editors to spot possible breaches and of course to advise new editors of the sanctions. Doug Weller talk 17:03, 31 October 2018 (UTC)

@Doug Weller: Something like this?
!("confirmed" in user_groups) &
article_namespace == 0 &
added_lines irlike "\bPalestine\b" &
old_wikitext irlike "\bIsreal\b"
Haven't done edit filters before, but have been trying to learn about them. zchrykng (talk) 01:41, 6 November 2018 (UTC)
Copied and tweaked from the Nazism filter. zchrykng (talk) 01:42, 6 November 2018 (UTC)
@Zchrykng: Thanks, I'm pretty clueless though. It might work. Doug Weller talk 19:41, 6 November 2018 (UTC)
Doug Weller, okay, so that pattern was wrong, but this one works on the test wiki. Can someone else review and see if it is worth including here?
!("confirmed" in user_groups) &
article_namespace == 0 &
"Palestine" in added_lines &
"Israel" in old_wikitext
zchrykng (talk) 01:46, 7 November 2018 (UTC)
Actually looks like this is a better option.
!("confirmed" in user_groups) &
article_namespace == 0 &
"Palestine" in added_lines &
!("Palestine" in old_wikitext) &
"Israel" in old_wikitext
Just need someone with the right perms to look and see if this is good. Maybe just as a warning. zchrykng (talk) 02:54, 13 November 2018 (UTC)
Anyone? Doug Weller talk 20:41, 30 November 2018 (UTC)
Unarchive. @Doug Weller and Zchrykng:, testing on Special:AbuseFilter/953. The filter catches edits like these so hopefully the edits caught are largely ARBPIA disruption. Galobtter (pingó mió) 11:54, 14 January 2019 (UTC)

Exaronews.com (Exaro)

This is actually request for a Spamblacklist addition. Ruslik_Zero 20:52, 22 January 2019 (UTC)

Testing an idea

Hi. I'd like to request a filter to investigate an idea I had (see Wikipedia:Village pump (idea lab)/Archive 28#To reduce the collateral damage from semi-protected articles for context). This would disallow edits from non-extended-confirmed editors to User:DannyS712/not pending. I was thinking something along the lines of:

page_prefixedtitle == "User:DannyS712/not pending"
& !("extendedconfirmed" in user_groups)

If the syntax is wrong, I'm sorry, this was just the idea I had. Thanks, --DannyS712 (talk) 01:02, 25 January 2019 (UTC)

DannyS712, I don't think this really needs technical testing - it is certainly possible to disallow all edits by non-extendedconfirmed or non-autoconfirmed users to a certain page (although the code should actually be !("extendedconfirmed" in user_rights)) - the question here is more "should we do it" than "is it possible technically". Galobtter (pingó mió) 09:01, 25 January 2019 (UTC)
@Galobtter: Would you be okay with enabling it for this one page, just to see how feasible it is from a use point of view? I understand that it should be possible, but I'd like to try it before I propose it, or have some data about the effect of enabling it for a specific page. --DannyS712 (talk) 09:09, 25 January 2019 (UTC)
DannyS712, ok, Filter 1 is set to disallow for the page. Galobtter (pingó mió) 10:40, 25 January 2019 (UTC)

Part 2

@Galobtter: Having tested it a bit, I'd like to move on to a trial:

New filter: Disallow ALL EDITS by DannyS712 test2

user_name == "DannyS712 test2"

This would allow me to test it out on higher-visibility pages without affecting anyone else. I would like this to be in addition to filter 1, so that I could still use 1 for testing. I was thinking along the lines of: I (test2) try to make an edit, it gets disallowed; wait while the page is edited by others; I (main) make the edit for the test account. Would you be okay with this? See the history at User:DannyS712/not pending for evidence that I have been testing this out.

Thanks, --DannyS712 (talk) 04:27, 28 January 2019 (UTC) Just to confirm, `DannyS712 test2 (talk) it under my control - I'm not just trying to revoke edit permission from someone else --DannyS712 test2 (talk) 04:29, 28 January 2019 (UTC)

DannyS712 test2,   Done Galobtter (pingó mió) 14:55, 28 January 2019 (UTC)

Brazilian political extremes

tech support scam phone numbers, again

Thanks - saw that one when it happened and added it. Kuru (talk) 01:10, 4 February 2019 (UTC)
Awesome. Beeblebrox (talk) 21:56, 6 February 2019 (UTC)

Comicbookmovie.com

  • Task: Create a similar filter like the one for the Daily Mail to warn editors attempting to cite comicbookmovie.com
  • Reason: Despite consensus that Comicbookmovie.com is considered an unreliable source as it relies on user-generated content, it is still frequently cited by IPs and newly registered users.--TriiipleThreat (talk) 19:56, 25 January 2019 (UTC)
@MusikAnimal: who worked on the Daily Mail filter.--TriiipleThreat (talk) 21:14, 6 February 2019 (UTC)
@TriiipleThreat: Is there consensus to use a filter? MusikAnimal talk 22:17, 6 February 2019 (UTC)
No, I was hoping to establish a consensus for a filter through this proposal.—TriiipleThreat (talk) 00:36, 7 February 2019 (UTC)

Anti-spambot filters

  • Task: Anti-spambot (New filter or modify existing)
  • Reason: I have noticed an upswing in spambots recently whose only post is to create their userpage with an innocuous-looking generated message, including a spam link at the end such as User:EveretteCalder3 User:AlexandraOsburn User:SiennaCoote64 and others (check my contributions to AIV). These messages appear to have some commonalities that might be able to be blocked by an edit filter. shoy (reactions) 22:06, 6 February 2019 (UTC)
    @Shoy: All those edits were caught by the log-only filters 499 (hist · log) and 935 (hist · log). Unfortunately both filters need to be private for WP:BEANS reasons, which makes it difficult for people like you to patrol the logs. Not sure what the solution is here. The filters have way too many false positives to be set to disallow. Perhaps a possible spambot tag? Suffusion of Yellow (talk) 23:26, 6 February 2019 (UTC)
@Suffusion of Yellow: I figured that was the case. I frequently patrol the New Editor Contributions page, and a tag would be nice if that is possible. shoy (reactions) 13:57, 7 February 2019 (UTC)

Catching a prolific sockmaster

  • Task: I'm hoping someone can help me with an edit filter that will flag userpages created by relatively new users with certain keywords to catch socks of a prolific sockmaster who's been at it for over a decade.
  • Reason: The socks' userpages tend to be very similar, and this puppetmaster is good at flying below the radar for periods of time after creating a new account. I don't know if this kind of detection is possible with an edit filter, but I figured I'd ask. cymru.lass (talkcontribs) 18:28, 11 February 2019 (UTC)
    Cymru.lass, This should be doable. I'd suggest emailing the details at wikipedia-en-editfilters lists.wikimedia.org. Galobtter (pingó mió) 18:33, 11 February 2019 (UTC)
    Galobtter, sounds good! I'll put together a list of keywords and shoot that email on over. Thank you! cymru.lass (talkcontribs) 18:35, 11 February 2019 (UTC)

Special:AbuseFilter/891

Note really a request, more a question. Does filter #891 target the draft namespace? If not, it should. Headbomb {t · c · p · b} 18:17, 17 February 2019 (UTC)

It does. -- zzuuzz (talk) 18:20, 17 February 2019 (UTC)

Import request

Hello!

Please can an edit filter manager import or copy over testwiki:Special:AbuseFilter/192 and testwiki:Special:AbuseFilter/194 to English Wikipedia?

The relevant discussions are on testwiki:User talk:Xaosflux (courtesy ping Xaosflux) and testwiki:Wikipedia:Requests/Permissions/StraussInTheHouse.

Many thanks,

SITH (talk) 19:17, 21 February 2019 (UTC)

The first filter should be
equals_to_any (page_namespace, 2, 118) &
added_lines irlike "{{subst:submit}}|{{AFC submission\|\|\|" &
new_wikitext irlike "{{mfd"
Checking new_wikitext is slow (because it is a large piece of text) so it should go last, and a namespace check is pretty fast and reduces the number of regexes run. The other filter needs to be similarly modified. I wonder if the filters should be combined - they are pretty similar and so do they need to have separate logs? Galobtter (pingó mió)
@Galobtter: thanks for the feedback, I've implemented both the code changes and the amalgamation, the updated filter can be found at testwiki:Special:AbuseFilter/198. SITH (talk) 17:24, 22 February 2019 (UTC)
StraussInTheHouse, See Special:AbuseFilter/964. Galobtter (pingó mió) 17:34, 22 February 2019 (UTC)
Galobtter, excellent, thanks! I don't know if we have to import the tag or whether that can just be manually done (I can't see that bit). Many thanks, SITH (talk) 18:17, 22 February 2019 (UTC)
StraussInTheHouse, I didn't actually notice the tag in the testwiki filter, but anyhow, let it get a few hits to make sure it is working properly, then we can start tagging. Galobtter (pingó mió) 18:21, 22 February 2019 (UTC)

New regex for 633

I? ?(([Tt]ypo)? ?[Ff]ix(ed)? ?[Aa]? ?([Ss]ome)? ?([Tt]ypo(es)?s?|[Gg]rammar)?|[Aa]dded [Aa]? ?([Ss]ome)? ?([Ll]inks?|[Cc]ontent)) checks out and should encompass much more than the original, including quite a few that I have found being commonly used by vandals. [Username Needed] 13:52, 28 February 2019 (UTC)

The point of the filter, per MusikAnimal in this phab task is to tag them as such so patrollers don't misinterpret them, them being canned edit summaries from drop downs in mobile - which is why the filter only checks mobile edits - not actually to catch summaries used by vandals. Galobtter (pingó mió) 15:21, 28 February 2019 (UTC)
Indeed, this filter is meant to match the available canned edit summaries exactly, not any variant of it. On that note I just removed the single word "Fixed" added in December 2018. I'm pretty sure that is not one of the options; it definitely isn't on Android. Crow please correct me if I'm wrong. MusikAnimal talk 17:23, 28 February 2019 (UTC)
Oh. Maybe we should have a different filter for that then? [Username Needed] 17:28, 28 February 2019 (UTC)

File name changes

  • Task: Revert any edits which alter a file name to one which is not technically linked on the project server (aka breaking a file by changing its filename).
  • Reason: As a bit of background, I patrol CAT:MISSFILE. In my patrolling, I have noticed that users will often attempt to change the name of a file in good faith to correct a perceived typo. Of course, this causes the image names to link to files are not technically linked or uploaded on the project servers, thus breaking the image. If possible, I would also recommend the filter by applied to anyone with under 100 edits (as I think autoconfirmed is too low in this case). This is an ongoing problem which accounts for at least 1/3 of the pages flagged in CAT:MISSFILE. I should probably also add that occasionally, AWB edits by experienced users will also cause file name breakage, when they alter the special characters (often quotes) in a file name. Please see this conversation for more information. Best, Katniss May the odds be ever in your favor 01:28, 1 October 2018 (UTC)
This will also have the added "bonus" of stopping the deliberate changing of an infobox image for something a little more pornographic, which has been seen more than once... Ronhjones  (Talk) 15:16, 1 October 2018 (UTC)
  Impossible We can to some extent detect changes to image link syntax, but unfortunately we can't detect if the image exists. We are actively working on the issue Ronhjones speaks of. MusikAnimal talk 18:15, 8 October 2018 (UTC)
  Monitoring at 971 @MusikAnimal: Zzuuzz commented at Wikipedia:Edit filter noticeboard#Edit filter for adding nonfree file that it would be possible to detect red-linked files, and I realized the new_html is different depending on whether a file exists or not. We can at-least warn with an explanation of how to upload a file and regarding file renaming. Galobtter (pingó mió) 09:23, 4 March 2019 (UTC)
Wow. I had guessed that looking at new_html would be hopelessly slow. But the filter's only claiming an average runtime of 0.26 ms! It's too bad that old_html is disabled, or this filter would be trivial. Suffusion of Yellow (talk) 18:10, 4 March 2019 (UTC)
Speed is why I put added_lines irlike "\.(?:jpg|png|svg|gif|tiff)", which should eliminate most edits, and why it isn't slow (showing 0.12 ms for me..) Galobtter (pingó mió) 18:16, 4 March 2019 (UTC)
I had (incorrectly, it seems) assumed that the filters are run before the page is parsed. Based on a few stabs at the test interface, about maybe 0.25% - 1% of edits are making it to the new_html test, so that check can't be taking longer than 25-100ms on average. Parsing a page should take much longer than that. Suffusion of Yellow (talk) 18:30, 4 March 2019 (UTC)
@Galobtter and Suffusion of Yellow: I am impressed you manage to figure this out! However, new_html is helplessly slow... It see it showing up in Logstash frequently, sometimes taking up to 5 seconds to run. It looks like with your implementation, any edit that touches a line with an image causes new_html to get called. We should look only for image changes (something akin to Special:AbuseFilter/955). Still, I wonder if this filter is really worth the expense. MusikAnimal talk 19:17, 8 March 2019 (UTC)
@MusikAnimal: Is it really slowing down the edit, or is the filter just getting "blamed" for the page parse? That is, once the edit actually saves, is the parsed page just being retrieved from the cache, so the user sees no difference? Or does new_html really force two page parses? Suffusion of Yellow (talk) 19:28, 8 March 2019 (UTC)
@Suffusion of Yellow: That is a good question. As far as I know, the slow filter dashboard was meant to identify slow filters, not normal editing. Obviously the parser can be involved here too (for the pst variables), whether that affects the recorded filter runtime, I'm not sure. Pinging Daimona Eaytoy, they may know.
Some recent examples, for those with Logstash access: [6] (1.8 seconds), [7] (2.5 secs), [8] (4.5 secs), [9] (2.8 secs).
It seems unusual to me for edits to take this long to save. MusikAnimal talk 19:51, 8 March 2019 (UTC)
@MusikAnimal: See 1 . Any edits made to User:Suffusion of Yellow/BigPage with the string "new_html" in the summary will look for a string that that happens to occur only at the very end. I tried this three times without mentioning "new_html", and twice mentioning it, and the response time was about the same (10-13 seconds before data transfer even started) every time. So, how long did Filter 1 take to produce Special:AbuseLog/23441382 and Special:AbuseLog/23441400? Suffusion of Yellow (talk) 20:32, 8 March 2019 (UTC)
@Suffusion of Yellow: What a clever way to debug! Indeed, my edit took 10+ seconds to save. I'm amazed. Surprisingly, filter 1 did NOT show up in the slow filter dashboard. This is very interesting. Apparently use of new_html makes no difference to the perceived time it took to save the edit. But why, then, is 971 being reported as slow? I'm looking at all the slow filters in the past four hours, and 3 out of the 8 are for 971, which is an unusually high frequency. Maybe new_html isn't the problem after all, but something is up. Note that the "threshold" for a slow filter is currently at 1 second. If the profiling did include the runtime of the full edit, those edits to filter 1 would have shown up. I'm confused :( MusikAnimal talk 20:55, 8 March 2019 (UTC)
If the problem is the size of new_html causing the in check to be very slow: because the vast majority of image breaking occurs in the lead, something like "wpDestFile" in substr ( new_html, 0, 10000 ) should catch 80-90% of cases while preventing the filter from having to check over all of the parser output. Galobtter (pingó mió) 19:46, 8 March 2019 (UTC)
@KatnissEverdeen and Ronhjones: Y Done Well, set to warn such users with MediaWiki:Abusefilter-warning-missing-file (suggestions welcome to improve the warning) and tag such edits with "missing file added". That should cut down the number of those bad edits. Galobtter (pingó mió) 15:29, 5 March 2019 (UTC)
Awesome! Thank you so much, @Galobtter:! Katniss May the odds be ever in your favor 14:31, 6 March 2019 (UTC)
Hi :-) I'm currently on mobile and checking the code would be a PITA, so I'll go by memory. Several variables (notably the ones which require parsing wikitext) are saved in a shared cache which is later reused upon saving. The time it takes to compute them is included in the filter runtime, since to avoid it we'd have to subtract the time taken at the end etc. So yes, even if it shows up as slow on logstash, it actually isn't. Needless to say, this isn't true for all variables. For instance, old_html would require parsing the old wikitext, and it would really make filters heavy. --Daimona Eaytoy (Talk) 20:43, 8 March 2019 (UTC)

tech support scam numbers yet again

 Y Done Galobtter (pingó mió)
Thank You. For the record we usually revdel these edits because of the potential harm they can cause, even in the edit history, by making it appear that these numbers are legit. Beeblebrox (talk) 17:05, 12 March 2019 (UTC)

Atharva Mittal

-- Matthew hk (talk) 11:10, 3 March 2019 (UTC)

@Matthew hk: Has semi-protection been tried yet? If he's only targeting one article, that usually the better route. Suffusion of Yellow (talk) 17:05, 3 March 2019 (UTC)
It would just mean edit protection expire and he is back again, based on the experience on another Indian SIVASANKAR G A. Despite "SIVASANKAR G A" case is more wide spread and suddenly gone. Matthew hk (talk) 17:09, 3 March 2019 (UTC)
@Matthew hk: Another question: Has this been going on for more than two days? I'm not seeing anything else in the history of Cathay Pacific. Filters are generally a last resort, when everything else has failed. Yes, he may become an LTA. But then again, he may not. Every filter (at least slightly) slows down every edit, so I think semi-protection or even just WP:RBI may be better, unless this goes on for weeks and spreads to many articles. Suffusion of Yellow (talk) 17:45, 3 March 2019 (UTC)
Matthew hk, that's the point of protection though. We don't create edit filters for single pages, especially when other options exist such as protection and blocks. It's been protected for 6 months and that recently expired, so it should be upped to a year long protection or more. WP:RFPP is the better venue for this issue. Nihlus 23:47, 3 March 2019 (UTC)
@Nihlus: they have hit several other articles. See Brahmastra (film) and List of film production companies in India, which are now semi-protected or pending changes because of them. Unfortunately, the IPv6 address range is too big for any viable block and their activity seems to come in spurts. For now, I've got a couple of strings that I search for on a regular basis to find their edits. I know they've hit several other articles besides the ones hit by the IP's mentioned here and the two articles I listed, but I can't remember off the top of my head. I think PC is a viable option for articles they hit more than once. Ravensfire (talk) 17:41, 12 March 2019 (UTC)

Filter to prevent usage of the word "goddamn" on the mainspace

You know, to prevent this from occurring... ᴀɴᴏɴʏᴍᴜᴤᴤ ᴜᴤᴇʀ (ᴛᴀʟᴋ) 23:15, 4 March 2019 (UTC)

That's why we have User:ClueBot NG. Headbomb {t · c · p · b} 23:16, 4 March 2019 (UTC)
I think a new filter as an extra layer of protection would be appropriate; any objections? ᴀɴᴏɴʏᴍᴜᴤᴤ ᴜᴤᴇʀ (ᴛᴀʟᴋ) 23:38, 4 March 2019 (UTC)
@Anonymuss User: It could be added to 380 (hist · log) or 384 (hist · log). But those filters are already set to disallow, so "goddamn" would need to be tested in a log-only filter for a few days before being added, in case there are more legitimate uses than is obvious. Suffusion of Yellow (talk) 23:51, 4 March 2019 (UTC)
There are zillions of legitimate uses. No real objection to a 'warning'/'tracking' filter though. Headbomb {t · c · p · b} 23:57, 4 March 2019 (UTC)
Not exactly sure of utility but   Testing at 953 anyhow. Galobtter (pingó mió) 11:49, 6 March 2019 (UTC)
Perhaps the filter should be disabled if the word "goddamn" already exists in the article, and/or if the instating user isn't autoconfirmed? ᴀɴᴏɴʏᴍᴜᴤᴤ ᴜᴤᴇʀ (ᴛᴀʟᴋ) 22:12, 6 March 2019 (UTC)
  • Remember the EF checks every edit against every filter, and has quirks about what is sees an "addition". So given Headbombs link and ClueBot, I'm not sure this is worth the added load. Yes there's a couple of hits that should be reverted, but I don't think it rises to the volume that an EF is needed. CrowCaw 15:48, 13 March 2019 (UTC)

Advameg sites (city-data.com, filmreference.com, notablebiographies.com, etc.)

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.


  • Task: To disallow Main article space edits which include links to these sites, and particularly to prevent them from being used as references.
  • Reason: The Advameg sites listed below have been described in many prior discussions as a content farm primarily designed to bring visitors to advertisers. They are often brought to attention in spam reports, reliable sources discussions, and related to copyright violations. The data is not attributed to specific authors, there appears to be no editorial policy, and some data is user-generated - making them unreliable sources. In some cases, they should be considered WP:TERTIARY sources. Below is a (possibly incomplete) list of websites (taken from http://www.advameg.com/) which should be filtered, along with links to prior discussions involving them that I could find (feel free to add others). --Netoholic @ 09:56, 10 March 2019 (UTC)

Site list

  • americanforeignrelations.com [10]
  • bankencyclopedia.com
  • biologyreference.com
  • chemistryexplained.com
  • city-data.com [11][12]
  • currency-conversion.info
  • deathreference.com [13]
  • discoveriesinmedicine.com
  • drug-data.com
  • everyculture.com
  • faqs.org [14]
    • faqs.org/allusions/
    • faqs.org/childhood/
    • faqs.org/collective-nouns/
    • faqs.org/espionage/
    • faqs.org/health/
    • faqs.org/health-encyc/
    • faqs.org/minorities/
    • faqs.org/nutrition/
    • faqs.org/ologies-isms
    • faqs.org/people-search/
    • faqs.org/sports-science/
    • faqs.org/time/
  • fashionencyclopedia.com
  • filmreference.com [15][16][17][18]
  • foodbycountry.com
  • healthofchildren.com
  • humanillnesses.com
  • lovetheoutdoors.com
    • lovetheoutdoors.com/fly-fishing/
  • madehow.com [19]
  • minddisorders.com
  • musicbanter.com
  • mythencyclopedia.com
  • nationsencyclopedia.com
  • newsearching.com
  • nonprofitfacts.com
  • notablebiographies.com [20]
  • patentsencyclopedia.com
  • photo-dictionary.com
  • pollutionissues.com
  • presidentprofiles.com
  • pressreference.com
  • readabstracts.com
  • referenceforbusiness.com [21][22]
  • scienceclarified.com
  • shareranks.com
  • siteencyclopedia.com
  • surgeryencyclopedia.com
  • thegardenhelper.com
  • trademarkencyclopedia.com
  • unexplainedstuff.com
  • unit-conversion.info
  • waterencyclopedia.com
  • weatherexplained.com
  • whatdoesthatmean.com
    • whatdoesthatmean.com/dictionary/

Discussion

Is the MediaWiki:Spam-blacklist not suitable here? Galobtter (pingó mió) 13:13, 10 March 2019 (UTC)

I don't know the particulars. I'm sure the spam blacklist catches external links like http://www.filmreference.com/ but would it also catch attribution like "Source:filmreference.com" or "Source: Film Reference"? -- Netoholic @ 08:30, 12 March 2019 (UTC)
  • Yes, Spam Blacklist is the proper location for this, until they start trying to obfuscate the form beyond what the spam list will catch. CrowCaw 15:44, 13 March 2019 (UTC)
Thanks, I'll take this there then. -- Netoholic @ 17:37, 13 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.

Categories added to draft

Draft at [23], but a user-groups/rights check should be added to reduce the strain the filter adds. If possible, however, please set it to extendedconfirmed, however, since (auto-)confirmed users will still frequently add categories to drafts. Thanks, --DannyS712 (talk) 21:50, 11 March 2019 (UTC)

I don't think we should be warning for this, considering how easy this is to fix by a bot. Not worth warning IMO where it is easier for someone else to fix automatically, and where it is a trivial problem. Galobtter (pingó mió) 04:30, 12 March 2019 (UTC)
@Galobtter: I completely understand, and am not particularly tied to the idea. Would you be okay with creating a log-only filter for now? --DannyS712 (talk) 04:31, 12 March 2019 (UTC)
  • I believe there is a bot that fixes this already? If so, I'm not sure it is worth the cycles to identify something that will be fixed shortly thereafter, and it is not harmful to have cats in drafts, so a little time delay is not necessarily a bad thing. CrowCaw 15:43, 13 March 2019 (UTC)

Usernames containing "1488"

  • Task: Tag usernames containing the number "1488"
  • Reason: 1488 is a well known Neo-Nazi symbol - see Fourteen Words. While there may be some false positives, I suspect that most people using these usernames are trolls and POV users.

Feel free to delete this if this filter already exists - I'm not sure how to check if it does. Thanks. 199.7.157.16 (talk) 01:10, 31 March 2019 (UTC)

If it's not already implemented, this is a good idea. Headbomb {t · c · p · b} 06:17, 3 April 2019 (UTC)

  Done - well, added to User:DeltaQuad/UAA/Blacklist. Galobtter (pingó mió) 08:23, 3 April 2019 (UTC)

Southern Region

Not needed. I blocked Special:Contributions/2A02:8084:6A80:5C80:0:0:0:0/64 which covers all the IPs mentioned (a /64 range block is basically equivalent to blocking a single IPv4 address). Galobtter (pingó mió) 08:57, 3 April 2019 (UTC)

Visibility of filter 364

I think filter 364 should be public because it appears to me to be aimed at your typical hit-and-run vandal, rather than any particular LTA. Edit filters are generally made private if they are aimed at an LTA so that he/she does not use the information to figure out how to get around the filter. I mean, people change the names in biographical articles all the time and I doubt these are all the works of a single person. Bolt Strike (talk) 16:59, 3 April 2019 (UTC)

Yeah,   Done. Galobtter (pingó mió) 19:23, 3 April 2019 (UTC)

TNA to impact

  • Task: Catch sock puppet user from violating their block. TNA ----> impact
  • Reason: The thing that gives this editor (Wikipedia:Sockpuppet investigations/Tonyjenkins450) away when they edit from IPs or create new accounts is they change historical mentions of TNA Wrestling to Impact Wrestling. Noticeably they always type it "impact", with the lowercase "i". I don't know the technically side of this, as this is my first request here. I was told to come here to stop this disruption after recent SPI case. Any questions feel free to ask. StaticVapor message me! 20:46, 17 March 2019 (UTC)
STATicVapor   Done as 980 . Galobtter (pingó mió) 09:57, 5 April 2019 (UTC)

Date of Death

Dear Wikipedia,

A simple algorithm criterion like - future date for death not allowed, should be helpful. I just corrected one article where Death date was written in future.

Please take note, Thank you, Regards, Shilpa

It makes pretty much sense to me.--Ymblanter (talk) 12:29, 5 April 2019 (UTC)

Kıbrıs Türk devletı ?

Prevent publishing of empty edit requests

I am sure I have asked for this but was archived without any action. I couldn't quickly find that. Please prevent submitting of edit request that consists only of the template and/or signature.

Empty edit requests are essentially meaningless and unnecessarily bloat the edit requests category thus exhausting editor time that can be used to respond to other meaningful requests. Requesting edit is just two clicks away in any protected page, I guess that's what incentivize those newbies to just continue clicking to see what would happen until they end up publishing nonsense. I couldn't remember any situation where empty edit request by IP or non-autoconfirmed user can be useful to the project. – Ammarpad (talk) 09:42, 20 April 2019 (UTC)

It's been asked for three times: here, here, and (by you) here. I wouldn't object to a warn-only filter here, but (echoing the concerns of Nihlus in the first thread) the warning will need to be really friendly, since we're getting the user a point where they're already frustrated by the page protection. It looks like Crow did attempt something but nothing ever came of it. To answer Ivanvector's question in the last thread (Question: can this filter be configured to allow instances where a user asks a question but then adds the template all by itself in a subsequent edit?): sort of. We can check if the user's name is already on the page, or if they're one of the last ten unique editors to the page, which should cover everything but highly dynamic IPs. And the filter won't even check for users manually adding the template (only ones who push the "Submit an edit request" button). So the only way an FP (of the type Ivanvector describes) could happen is:
  1. User posts to Talk:Foo with a requested edit
  2. User goes back to Foo and clicks "view source"
  3. User clicks "Submit an edit request"
  4. Without modifying the edit form, user clicks "Save", but sometime between (1) and (4), their IP changed.
This seems unlikely. One may argue that even for true positives, a filter would be WP:BITEy. But I'm not sure the current system of bot-like "it's not clear what changes you want to be made..." responses is really any better. I'll try something. @Ammarpad: Any suggestions on the warning message? Suffusion of Yellow (talk) 20:10, 20 April 2019 (UTC)
For the moment, I'm just logging all edit requests made by non-autoconfirmed users 1 , because Special:AbuseFilter/test doesn't work well with substed templates, so I need some past hits from an actual filter to test against. Once it logs a few dozen empty and non-empty requests, I'll move on. Suffusion of Yellow (talk) 20:56, 20 April 2019 (UTC)
Thanks, Suffusion of Yellow. When we move on I think the message could just be something like MediaWiki:Blankarticle, since it will be set to warn initially. If the issue persists (Which I believe is possible, because people would still be curious to click 'yes' and see what would happen thereafter), then it should disallow and explain that empty request cannot be saved. – Ammarpad (talk) 11:58, 21 April 2019 (UTC)
@Ammarpad: Now logging at 987 (hist · log). Suffusion of Yellow (talk) 20:48, 23 April 2019 (UTC)

Extending filter 869 to cover all deprecated sources with consensus to implement edit filter warnings

To enact the changes described in the recently closed discussion WT:RSN § Implementing edit filter warnings for deprecated sources, I'm requesting the extension of filter 869 to cover all deprecated sources for which previous RfCs have shown consensus to implement edit filter warnings.

This extension would involve two steps:

  1. The language in MediaWiki:Abusefilter-warning-dailymail should be amended to apply to multiple deprecated sources, not just the Daily Mail. The discussion concluded with a recommendation to use WT:RSN § Modified option 1, reproduced below:

Filter 926 also appears to use MediaWiki:Abusefilter-warning-dailymail, but since I'm unable to see the details of filter 926, I can't determine the best course of action for that filter. If MediaWiki:Abusefilter-warning-dailymail is revised to the above, it may be worth renaming it to MediaWiki:Abusefilter-warning-deprecated, which better reflects the new message.

  1. Filter 869 should be amended to apply to the domains of all currently deprecated sources with the necessary RfCs:
    1. The Daily Caller (RfC): dailycaller.com, dailycallernewsfoundation.org
    2. Daily Mail (2017 RfC, 2019 RfC): dailymail.co.uk
    3. Last.fm (RfC): last.fm
    4. NNDB (RfC): nndb.com
    5. Occupy Democrats (RfC): occupydemocrats.com
    6. Rate Your Music (RfC): rateyourmusic.com, cinemos.com, glitchwave.com, sonemic.com
    7. The Sun (United Kingdom) (RfC): thesun.co.uk
    8. Telesur (RfC): telesurtv.net, telesurenglish.net
    9. VDARE (RfC): vdare.com
    10. WorldNetDaily (RfC): wnd.com, worldnetdaily.com

      — Newslinger talk 22:06, 13 April 2019 (UTC)

@Newslinger: 926 is unrelated to MediaWiki:Abusefilter-warning-dailymail; it looks the filter number was put there in error. Checking again, Zzuuzz has already fixed it. Suffusion of Yellow (talk) 23:39, 13 April 2019 (UTC)
Indeed. Just to quickly note that filter 899 should probably also be factored in. Also, this seems like a horribly inefficient way forward. -- zzuuzz (talk) 23:41, 13 April 2019 (UTC)
Thanks for the correction. Do you have any recommendations for implementing these changes more efficiently? — Newslinger [[User talk:Newslinger#top|talk]::] 23:44, 13 April 2019 (UTC)
Not really. Filter 899 should probably provide the template for how this type of thing is properly done. A long list with 4+ lines for each item is probably not a good thing. -- zzuuzz (talk) 00:10, 14 April 2019 (UTC)
@Newslinger: T216001 would make this a whole lot easier. But I don't think anyone has even started working on that, so there's no way to customize the warning based on the matched phrase. The filter warning will probably need to list all of the deprecated sources to avoid forcing the user to switch back and forth between two tabs trying to figure out which source was the problem. We already get complaints that MediaWiki:Abusefilter-warning-selfpublished is confusing, and it only lists five sources. This one will have ten. I'm not opposed to this, but the current software will make the implementation clumsy. Suffusion of Yellow (talk) 00:07, 14 April 2019 (UTC)
@Suffusion of Yellow: Just to clarify, the consensus was to use the message that links to the current list, instead of including a link for each source (which was specifically rejected). I would also argue that it's probably much easier to read from the formatted table even if it does involve switching tabs, especially as the list is likely to expand in the future. Sunrise (talk) 01:36, 27 April 2019 (UTC)

Like a 1995

I have no idea of filter costs, but, in year articles, IPs frequently add expressions like "2003, like a 1998 or 2005". I would like to know if it's happening on other articles. The search tag would but, added text "like a" 4 digit number, whether or not the number is linked. (It could be "like a 1998.) — Arthur Rubin (talk) 17:23, 26 April 2019 (UTC)

Before anyone comments, I realize that "like a 2005 Ford Taurus" could be legitimate, although probably not a good tone. — Arthur Rubin (talk) 01:46, 27 April 2019 (UTC)
@Arthur Rubin: I thought a rangeblock already took care of this one. Guess not. Have you spotted anything outside of:
If not, I think I'll ask for a block of the /54 over an ANI. If there's anything from outside those ranges, then I suppose it's time for a filter. Suffusion of Yellow (talk) 00:35, 1 May 2019 (UTC)
@Suffusion of Yellow: I haven't seen anything recently, so you may be correct. — Arthur Rubin (talk) 03:33, 1 May 2019 (UTC)

User space spambot

  • Task: Tag edits by new users in their user spaces that contain the word "keto" (case-insensitive and even if it's in URL).
  • Reason: I find and report a bunch of Keto spambots every day. It'd be easier to have them all in one place instead of scrolling through all the unfiltered contributions of new users. —RainFall 06:45, 25 April 2019 (UTC)

Specific block

@Cyphoidbomb: this is how to request one :) -- Amanda (aka DQ) 15:19, 20 April 2019 (UTC)
Thanks, friend! So will this only prevent me from getting pinged or will it impede the vandalism in any way? The person behind the IPs seems to be in this to damage stuff. Somehow I've just become the target of his mockery. Cyphoidbomb (talk) 15:24, 20 April 2019 (UTC)
@DeltaQuad: I probably should have pinged you. Cyphoidbomb (talk) 15:25, 20 April 2019 (UTC)
@Cyphoidbomb: The filter can either be set up to disallow the edit, tag it, or warn & tag - considering this is likely to be vandalism they can set it up to disallow the edit (and tag for blocking). Amanda can correct me if I'm wrong. Dusti*Let's talk!* 15:28, 20 April 2019 (UTC)
(edit conflict) Yes, it would stop you being pinged, and maybe even prevent the initial damage. Normally I'd write it up myself, but I don't have enough experience to trust myself not to block the entire wiki from editing using that function. -- Amanda (aka DQ) 15:29, 20 April 2019 (UTC)
@Cyphoidbomb: Testing at 988 (hist · log). I see 49.199.9.254 was up to the same thing today, so hopefully this can be set to disallow soon. Suffusion of Yellow (talk) 22:57, 28 April 2019 (UTC)
@Suffusion of Yellow: Thanks! I appreciate your efforts. Regards, Cyphoidbomb (talk) 23:11, 28 April 2019 (UTC)
@Suffusion of Yellow: Just got a batch of pings from 49.199.3.106 (talk · contribs · deleted contribs · filter log · WHOIS · RDNS · RBLs · http · block user · block log). Cyphoidbomb (talk) 21:10, 4 May 2019 (UTC)
I've left the required notice at WP:EFN#Setting filter 988 to disallow. Will flip the switch soon if there are no objections. Suffusion of Yellow (talk) 21:35, 4 May 2019 (UTC)

Non-confirmed editors changing the display title of a page

Potential implementation:

!"confirmed" in user_groups & (
  !equals_to_any(page_namespace, 2, 3) & (
    added_lines contains "{{DISPLAYTITLE"
  )
)

Thanks, --DannyS712 (talk) 23:46, 30 April 2019 (UTC)

@DannyS712: I think Od Mishehu has already started on something; see 358 (hist · log). Suffusion of Yellow (talk) 00:07, 1 May 2019 (UTC)
@DannyS712 and Od Mishehu: should also include the
DannyS712, Od Mishehu, and Suffusion of Yellow, are you envisioning only someone modifying (but not removing) an existing DISPLAYTITLE, or would you also be interested in the addition of a new DISPLAYTITLE or the complete removal of an existing one? Maybe your potential implementation answers this question, but I don't speak this coding language :-) Nyttend (talk) 04:26, 2 May 2019 (UTC)
@Nyttend: the removal of an existing one, though odd, isn't what I (personally) was thinking of. Instead, the addition of a new DISYLAYTITLE, or the alteration of an existing one, should be logged - those are the 2 ways to exploit the behaviour. --DannyS712 (talk) 04:33, 2 May 2019 (UTC)
Agreed with DannyS712. Removal is not as problematic as adding or altering it to a malicious DISPLAYTITLE. --qedk (t c) 07:04, 2 May 2019 (UTC)
The potential damage which could be caused by someone removing a DISPLAYTITLE is minimal; the damage of someone modifying one has already reached displaying the title of a BLP as "Shit"; and the potential for modifying an existing one is as bad as creating one for a page which doesn't already have. עוד מישהו Od Mishehu 11:49, 6 May 2019 (UTC)

Numeric summary

Frequently, editors to number (and less frequently, year) articles have an edit comment consisting entirely of a number, and the text edit changing some number in the file to that number. These are usually IPs, but I recall seeing one recently from a logged in editor (immediately reported to AIV). I don't know if just "edit comment = number" would provide too many false positives. The most recent one I reverted is here. — Arthur Rubin (talk) 16:49, 24 April 2019 (UTC)

(Talks to self). If implemented on a test basis, and it has an acceptable cost, I'll look at the entries to verify the false positive rate. — Arthur Rubin (talk) 17:18, 26 April 2019 (UTC)
Testing on 953 . Galobtter (pingó mió) 19:38, 3 May 2019 (UTC)
Some hits - 5-10 a day - with a simple check for summary irlike "^\d+$" by new users; decent proportion of that was vandalism but quite a bit wasn't. Galobtter (pingó mió) 18:32, 17 May 2019 (UTC)

Gorillion

  • Task: What is the filter supposed to do? Prevent vandalism. To what pages and editors does it apply? Articles related to the Holocaust.
  • Reason: Why is the filter needed? It's used for vandalism, like "Muh six gorillion", and doesn't have any legitimate use. Benjamin (talk) 22:12, 26 April 2019 (UTC)
@Benjaminikuta: Do you have any diffs of this being used for vandalism? Agree it has no legitimate use, but a filter should only be used if it's a frequent problem. Suffusion of Yellow (talk) 22:10, 28 April 2019 (UTC)
I've only seen it once, since I don't do anti vandal work very often, so I don't know how common it is. Is there some way to tell? Benjamin (talk) 00:34, 29 April 2019 (UTC)
@Benjaminikuta: If you've only seen it once it's probably not worth adding to a filter. The only way to be sure would be to test for it with a log-only filter, and if someone else chimes in here with an example before this thread gets archived, I suppose it might be worth checking for. But in general, filters can't cover every possible vandal word or phrase, or they'd quickly become unmaintainable. Suffusion of Yellow (talk) 00:17, 1 May 2019 (UTC)
Okay, I'm not too familiar. Would it be possible to teach ClueBot to look out for it, or something like that? Benjamin (talk) 00:33, 1 May 2019 (UTC)
I don't know much about ClueBot. The algorithm is described here, but the link to the review interface 404s for me. Suffusion of Yellow (talk) 00:42, 1 May 2019 (UTC)
@Benjaminikuta: Checking on Special:AbuseFilter/953. Seeing if a term is being used for vandalism using a log-only filter isn't much trouble if done in a batch with other terms, and if there's no chance of false positives (since that is what really takes time and creates maintenance) Galobtter (pingó mió) 16:00, 3 May 2019 (UTC)
Nope, nothing. Galobtter (pingó mió) 16:20, 17 May 2019 (UTC)

Base64 image data

  • Task: Catch people adding base64-encoded images to pages (instead of just uploading the image). Off the top of my head, should apply to mainspace and userspace (and their talk pages), but should specifically exclude User:(username)/*.css and User:(username)/*.js, since as far as I can tell those are legitimate uses for themes. To get an idea of the content it would catch, search userspace for "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD"
  • Reason: Other than the above-mentioned exception, I can't see many legitimate uses for people uploading base64-encoded images (or any sort of file, for that matter) to Wikipedia - this isn't the place for file storage, it goes around the standard file upload method, and there's no way to verify the files conform to Wikipedia's licensing requirements. Also, it's not easily readable without plugging the data into a decoder. I don't think this would necessarily be a high-traffic filter, but I do think it would be useful as a warning or a tag.

If this does seem like a useful filter, I'm happy to throw together a prototype -- I just wanted to check whether it seemed useful to other people before starting on it. creffett (talk) 02:21, 1 June 2019 (UTC)

Creffett, I added "data:image" to filter 220 . Galobtter (pingó mió) 13:24, 7 June 2019 (UTC)
@Galobtter: That works. Thank you! creffett (talk) 13:25, 7 June 2019 (UTC)

Russian filter on 1 page

Abote2 (talk) 10:57, 7 June 2019 (UTC)

  Done, added to 906 . Galobtter (pingó mió) 12:29, 7 June 2019 (UTC)

Log edits to other's editnotices

  • Task:
  1. Namespace is User or User talk
  2. Page creations or edits
  3. base user/usertalkpagesPages ending in Emailnotice or Editnotice (user SUBpages editnotices are already in the titleBL)
  4. Edit not made by username==basepagename , admins, bots, templateeditors (I don't really think we need pagemovers here - their titleblacklist access is primarily for a different reason)
Done, see Special:AbuseFilter/989. Galobtter (pingó mió) 14:03, 6 May 2019 (UTC)
Good work, it even caught this edit. Galob (talk) 19:38, 7 May 2019 (UTC)
First instance of actual vandalism caught now, Special:AbuseLog/24014455. Galobtter (pingó mió) 09:05, 19 May 2019 (UTC)
@Galobtter: More instances found, though in this case it was vandalism and then self reversion: https://en.wikipedia.org/w/index.php?title=User_talk:Materialscientist/Editnotice&action=history DannyS712 (talk) 00:13, 8 June 2019 (UTC)
Also pinging Materialscientist so that they are aware --DannyS712 (talk) 00:14, 8 June 2019 (UTC)
Materialscientist has disabled pings :) I saw the instance of vandalism above; need some more discussion to set this to disallow. Galobtter (pingó mió) 08:51, 8 June 2019 (UTC)

Prevent unregistered editors from creating GA-review pages

  • Task: Prevent IP editors from creating /GA[0-9] subpages of pages in the Talk: namespace
  • Reason: Per WP:GAREVIEW, only registered users are allowed to review good article nominations. However, since the process involves creating a /GA[0-9] subpage of the talk page of the article in question, IP editors can create review pages. This confuses the bot that maintains WP:GAN and the GA process (e.g. [26]) and requires admins to manually delete these pages and revert the bot's edits. So an edit filter that simply blocks such creations could save some work and is unlikely to cause problems since there is no conceivable reason why an IP editor should create such a subpage. Regards SoWhy 10:59, 27 May 2019 (UTC)
Something along the lines of user_age === 0 && page_id === 0 && page_namespace === 1 && page_title contains '/GA' might do the trick. Can someone with access to the test interface take a look? --DannyS712 (talk) 15:59, 7 June 2019 (UTC)
  • I'd like to see a custom message created prior to blocking anyone, as the default will just say "your edit was unconstructive". I'll set up log-only to see how big of a problem this is. Remember that EF runs against every edit, so having a good ROI is desirable. Is fixing the bot so it looks at the page creator an option? CrowCaw 19:22, 7 June 2019 (UTC)
    @Crow: that still wouldn't fix the fact that the page was created. I agree that this shouldn't block for now, but even log only would be helpful. Also, what is ROI? DannyS712 (talk) 20:01, 7 June 2019 (UTC)
  • If it rises to that level. So far zero hits on the watch filter. As for the bot, it should be possible for a bot to check the creator and either outright delete the page (if approved) or simply add a CSD-G6 to it. Yes an admin would still have to delete it of course. CrowCaw 15:26, 9 June 2019 (UTC)
  • Of note, still zero hits on the filter 2 weeks on. While disruptive, I don't think this rises to the level where an EF is appropriate. Perhaps a Bot Task can be created to check the creator of /GA pages and tag them G6 if an IP created them (or if the bot has admin, to delete them). CrowCaw 21:34, 22 June 2019 (UTC)
    @Crow: CC @SoWhy Thanks for checking. If the problem comes up again, an alternative (and probably better idea) would be to use the title blacklist. Something like: Talk:.*/GA\d <autoconfirmed> which would prohibit non-confirmed users from creating GAs. --DannyS712 (talk) 21:45, 22 June 2019 (UTC)
  • Granted autoconfirmed is not far from Newly Registered, but a new account is technically allowed to create a /GA without being autoconfirmed, so the TBL is probably erring on the restrictive side of things. CrowCaw 22:32, 22 June 2019 (UTC)
    Still, I cannot think of a valid reason for a non-autoconfirmed user to create a GA review, so changing the GA rules might be possible. Thanks for the feedback! Regards SoWhy 09:37, 23 June 2019 (UTC)

Isn't there a filter for this already?

Indian Society of Cinematographers

  • Task: To combat spam by people affiliated with the organisation, this filter would prevent people from adding "Indian Society of Cinematographers" to articles.
  • Reason: Over the last few months, which I have detailed at WP:AN, various users (Roastedcocoa and Indiravallam) as well as many IPs (including but not limited to 49.207.63.117, 106.51.107.188, 106.51.109.159 and 106.51.109.35) have been editing Indian cinematographer articles and Indian film articles, and wherever a cinematographer's name appears, tacking on postnomials "ISC" and links to Indian Society of Cinematographers, which redirects to Indian cinematographers. In biographical articles they add these initialisms to the infobox parameter |name= which is not typically done, as well as the |title= parameter, which makes no sense, since ISC is not a title, it's an organisation. They also typically add it to the first appearance of the name in the lead, which is not a big deal. The reason why I'm asking for this edit filter is to stop the erroneous use of these parameters. Also, we never indicate organisational memberships in film articles. If someone is a member of the Director's Guild of America, you never see "DGA" after the director's name. I've tried to explain this to various IPs, but they just hop to the next IP.

I raised this matter at WP:AN as detailed above, and MER-C suggested an edit filter set up as "\bindian\bsociety\bof\bcinematographers". The formats that I usually see are:

  • Indian Society of Cinematographers
  • [[Indian Society of Cinematographers]]
  • [[Indian Society of Cinematographers|ISC]] or |I.S.C.]]
  • [[Indian cinematographers|Indian Society of Cinematographers]]
  • [[Indian cinematographers|ISC]] or |I.S.C.]]
  • [[Indian cinematographers|'''ISC''']] or |'''I.S.C.''']]

MER-C noted that "Trying to stop the addition of "\bisc\b" has too many false positives" but I wonder if it's possible to do with proper context. So if ISC appears in a link to one of those cinematography articles, we could prevent the addition that way.

I have been unable to get the Edit summary search to work for me the last few weeks to demonstrate how much of a problem this has been, but it is significant. There may ultimately be a legitimate reason to include some mention of this organisation in articles, but to me there is a clear promotional campaign going on and since none of these people seem willing to learn the rules, we have to first get their attention by not letting them add the phrase, then engage them in discussion. Also, to promote discussion, it would be ideal if they could still use the phrase on talk pages, for example. Thanks in advance, Cyphoidbomb (talk) 20:45, 3 July 2019 (UTC)

@Abecedare: Yes indeed. Thanks to the linking page I was able to clear out a ton of them in the last two days. I still think the edit filter would be helpful, because they're still creating a ton of needless work. Regards, Cyphoidbomb (talk) 22:26, 3 July 2019 (UTC)
Ha! Of course, you had thought of that already. I have some related questions but will post them on your talkpage instead of further spamming this board. Abecedare (talk) 22:53, 3 July 2019 (UTC)

Filter name

{{resolved}}

Maybe so, but in the meantime could this be implemented? Especially if stewards don't get to this before the issue is fixed (after which OAuth will need to be re-instated). Headbomb {t · c · p · b} 20:42, 18 June 2019 (UTC)
Seems resolved now. No idea why, but the EF is no longuer needed. Headbomb {t · c · p · b} 22:17, 18 June 2019 (UTC)

Creation of blank pages

  • Task: Track the creation of blank pages
  • Reason: Such pages , are generally eligible for speedy deletion per WP:CSD#G7 or WP:CSD#G6.

Proposed logic:

action = 'edit' &
page_id == 0 &
new_size == 0

Thanks, --DannyS712 (talk) 13:39, 10 July 2019 (UTC)

We have (deleted) filter 632. I tend to agree it probably won't be worth it. Is there just one example of this actually happening? I suppose a test run should provide any data, but it will need to exclude user and user talk, and page_id is documented as being unreliable, so page_age should probably be used instead. -- zzuuzz (talk) 12:58, 27 July 2019 (UTC)
I've re-enabled the filter for a while to gather some data. -- zzuuzz (talk) 13:36, 27 July 2019 (UTC)
  • Not sure this rises to the need of an EF, as remember EF's are run against every edit. Checking the logs, and from my prior NPP experience, a lot of new users will create a blank page, save, then edit subsequently. NPP should be sufficient to catch those edits that never progress beyond that. If the EF is decided upon, it should also exclude Talk (as I see many people creating a blank Talk to clear the redlink), and Category (as they will often/usually be empty at first until populated, depending on the creator). CrowCaw 20:01, 4 August 2019 (UTC)
    @Crow: in that case, can you exclude 1 and 14 from the namespace check? Thanks, --DannyS712 (talk) 04:21, 5 August 2019 (UTC)

nexushd filter

  Resolved
 – Tagging so that its archived --DannyS712 (talk) 04:22, 5 August 2019 (UTC)
@Galobtter: Many thanks. General Ization Talk 04:37, 24 July 2019 (UTC)

WikiLoop and WikiLoop Battlefield

  • Task: What is the filter supposed to do? To what pages and editors does it apply?
We would like to create a tag for "wikiloop battlefield" which is for edits created using WikiLoop Battlefield (currently it direct you to the URL that reverts a revision if the editor thinks the revision is a vandalism)
We would like to group, count and review the reversions using WikiLoop Battlefield tool and make sure it functions well and try to improve it.

Xinbenlv(t) please notify me with {{ping}} 21:14, 31 July 2019 (UTC)

I don't think there is a need for an edit filter. Either use OAuth to make the edit on the editors behalf, and OAuth will automatically add a tag, or mw:API:Edit allows you tag edits once the tag is created by an admin. Galobtter (pingó mió) 03:52, 5 August 2019 (UTC)
  Resolved
 – Resolved by Crow at 871 --DannyS712 (talk) 09:24, 24 August 2019 (UTC)
  • Task: Block or tag any usage of "Jonard Aclo" or "Evan Pettiwhisker Tildrum" on articles.
  • Reason: Mostly to keep a certain sockpuppeteer-slash-troll at bay due to his wanton and repeated vandalism. Blake Gripling (talk) 02:33, 12 August 2019 (UTC)
As someone who has a search for Jonard Aclo bookmarked, I would like to support that part of this request. "Evan Pettiwhisker Tildrum" currently appears in three interlinked WP articles - and appears to be a "real" fictional character, with 11,400 G-matches. As the last game was issued in March 2018 there may me sequels, so I am less sure about a total block on that name - Arjayay (talk) 12:05, 14 August 2019 (UTC)

Kibris Türk devleti + Kıbrıs Türk devletı + variants

  Resolved
 – Added to 718 by Crow --DannyS712 (talk) 09:25, 24 August 2019 (UTC)

SciAlert.net predatory journals

  Resolved
 – Added to 891 by Crow --DannyS712 (talk) 09:25, 24 August 2019 (UTC)
De-archived. Headbomb {t · c · p · b} 19:09, 20 August 2019 (UTC)
  • Added DOI 10.3923 to list. Edit request in for IE to add it to the warning description. Heads up on EF/FP for the usual spate of FPs as people edit sections where existing citations are made, as they will likely trip the filter. CrowCaw 19:32, 20 August 2019 (UTC)
  • Sorry, was on a roll! :) I added an edit request to the fully protected page that contains the Filter warning that is presented to the editor upon saving. Because there are a lot of citations to scialert.net currently published, people editing paragraphs or sections which already contain those citations will probably receive a warning about predatory journals even if they don't touch that text, so I was giving a heads-up to the Edit Filter False Positives patrollers that there will likely be some False Positives around this as a result in the near term. CrowCaw 19:39, 20 August 2019 (UTC)
    @Crow: thanks for the heads up --DannyS712 (talk) 08:52, 23 August 2019 (UTC)