User talk:AnomieBOT

  1. Home
  2. Wiki


Peer review bot

[edit]

I noticed you have AnomieBot 83 that maintains peer reviews. I also have a bot User:GreenC bot/Job 20, though different. I wonder, are we working at cross purpose or is it complimentary? Example: Talk:Poisoning of Abbot Greenwell (see history). -- GreenC 06:31, 28 July 2025 (UTC)[reply]

Looks like our bots do different things. In that example, it looks like the user incorrectly added {{Peer review|archive=2}} (rather than |archive=1=), then a week later GreenC bot removed it; meanwhile AnomieBOT responded to Wikipedia:Peer review/Poisoning of Abbot Greenwell/archive1 being in Category:Current peer reviews by adding a section transcluding it to the talk page, which no one else has touched. Anomie⚔ 12:16, 28 July 2025 (UTC)[reply]
That works. -- GreenC 16:02, 28 July 2025 (UTC)[reply]

Duplicate WikiProject templates

[edit]

This edit correctly replaced {{WikiProject Adelaide}} with Adelaide=yes within {{WikiProject Australia}}, however there already was an existing {{WikiProject Australia}} template. Can the bot check for duplicate WikiProject templates within the banner wrapper and either just skip it or incorporate it within the existing template? The-Pope (talk) 13:43, 12 September 2025 (UTC)[reply]

The TemplateSubster task just substitutes templates that it has been instructed to substitute via {{Subst only|auto=yes}}, it doesn't know anything about the actual content or usage of any of the templates. If you compare the page before and after, you can see that the visual rendering has not changed. Anomie⚔ 14:04, 12 September 2025 (UTC)[reply]

Just a note, AnomieBOT is updating some of its old redirects

[edit]

Wikipedia:Bots/Requests for approval/AnomieBOT 86 was approved to allow AnomieBOT to update its EnDashRedirectCreator redirects when they're lacking things like {{User:AnomieBOT/Auto-G8}} or {{R avoided double redirect}} or the targets in those templates are incorrect. So it'll be working through the backlog on that for a bit, in case anyone sees the edits happening and wonders what's up. Anomie⚔ 22:32, 14 September 2025 (UTC)[reply]

Getting the bot to deal with instances of maintenance templates accidentally added with CURRENTMONTH and CURRENTYEAR instead of the actual month/year

[edit]

Hi @Anomie:, the subject line kinda says it all ... except I've changed the syntax to make it easier to link to the section if need be. I've found over a hundred instances (mostly added with Parsoid over the years) where instead of the wikitext saying "{{vague|date=September 2025}}", it occasionally says "{{vague|date={{CURRENTMONTHNAME}} {{CURRENTYEAR}}", as if these magic words weren't substed properly somewhere along the line. See the diffs in this permalink to my contribs for examples. Could this bot be programmed to catch and fix these as soon as they happen in articles? At the time of writing, I've fixed them all, but the sooner they're detected, the easier they are to fix, so I was wondering if this bot could help out with this task. Thanks! Graham87 (talk) 14:00, 18 September 2025 (UTC)[reply]

Hmm. A search like that is probably the only way to really find these, but it's probably do-able. I'll have a look. OTOH, I note that at least one person in at least one place seems to want to insist on using it with {{as of}}, so I might exclude that template unless someone else wants to fight that fight instead. Anomie⚔ 14:19, 18 September 2025 (UTC)[reply]
Thanks. Oops, I just meant instances where the wikitext was like {{<pick a maintenance template>|date={{CURRENTMONTHNAME}} {{CURRENTYEAR}}}}, so excluding most (all?) "as of" templates you were talking about. I've been tinkering in the "as of CURRENTYEAR" space too and had my own battles there (WP:CURRENTLY broadly agrees with us). Good to know we've had similar ideas, though I think I would've left that one alone because it does indeed contain some convoluted template weirdness further down in the table (even though it breaks caching and most likely all sorts of other things), but I wouldn't have realised that at first. Graham87 (talk) 15:01, 18 September 2025 (UTC)[reply]
BRFA filed Anomie⚔ 15:52, 18 September 2025 (UTC)[reply]
Sounds great! Thanks very much. I've watchlisted it. Graham87 (talk) 16:04, 18 September 2025 (UTC)[reply]

BRFA bot suggestion

[edit]

Hi @Anomie. Since you've been more active lately in bot work, wondering if you can modify the BRFA clerking task to also close the BRFA (inserting the headers and footers) once a BAG member marks it as  Approved. or Speedily Approved.? – SD0001 (talk) 09:23, 23 September 2025 (UTC)[reply]

I probably could (although it'd need a BRFA). It's not clear we need it though. In the past 5 years, I see only two BRFAs that this proposal would have closed (Special:Diff/prev/1023220337 and Special:Diff/prev/1054503351). If we extend it to denied and expired, that adds two more (Special:Diff/prev/1024073056, Special:Diff/prev/1060563095), and a few where someone made an error or something else confusing was happening (Special:Diff/prev/1037926220 (category lag?), Special:Diff/prev/1094004606 (both "denied" and "expired"), Special:Diff/prev/1267060680 (wrong value passed to {{BT}})). Adding "withdrawn" too (and allowing the botop to have added the tag for this case) would catch a lot more. OTOH, 5–10 years ago there were a lot more that the bot might have handled; I'm not sure how much of that is due to certain BAGgers becoming less active versus them learning better how to close things. Overall, before doing this I'd want some discussion at WT:BAG or WT:BRFA WP:BON to see whether other BAGgers think this would be helpful or not. Anomie⚔ 16:56, 23 September 2025 (UTC)[reply]

CfDClerk down?

[edit]

AnomieBOT hasn't updated Wikipedia:Categories for discussion/Old unclosed discussions for several hours, even though I've closed lots of discussions since then. * Pppery * it has begun... 23:12, 26 September 2025 (UTC)[reply]

Looks like T404584 again. Restarting the job. Anomie⚔ 00:00, 27 September 2025 (UTC)[reply]

Reference GIGO

[edit]

I've been spending some time on Category:Pages with incorrect ref formatting recently and have seen the following pattern, well, more than once:

  • (In the distant past) An editor adds a reference with the name enclosed in curly quotes in place of straight quotes
  • (In the distant past) Visual editor "corrects" this by wrapping the curly quotes in straight quotes
  • (Now) AWB running as Monkbot converts the curly quotes to straight quotes (example)
  • (Now) AnomieBot removes the contents of the outer pair of quotes (example)

And the last step breaks the reference, which incredibly MediaWiki manages to parse at all the previous steps. I don't know how best to avoid this story ending with a broken reference, but could I suggest that one improvement would be for AnomieBot to convert <ref name=""foo""> into <ref name="foo"> rather than <ref name="">, since that is apparently how MediaWiki parses it? I can also see that it might be good for AWB to remove the curly quotes in this situtation rather than converting them, or for a new bot task to fix all the references with curly quotes, nested or otherwise. Pinging @Trappist the monk for comments since Monkbot is involved as well. Thanks, Wham2001 (talk) 15:39, 5 October 2025 (UTC)[reply]

PS Since I'm here, perhaps now is a good moment to say thanks for AnomieBot, which amongst its many helpful tasks has saved me countless hours manually filling in the |date= param on maintainance templates, for which I am very, very grateful. Best, Wham2001 (talk) 15:41, 5 October 2025 (UTC)[reply]
Yeah, monkbot (not AWB) is likely guilty of creating name=""summat"" ref names. But not all. If we are to believe this search there are about 460 articles with reference names that begin name="“ or name="”. There were a couple of articles in the categories where task 21 is working that I have fixed.
Similarly, this search indicates that there are some number of ref names that end with “" or ”"; the search times out. Constrained to the categories where task 21 is working, the search finds no articles.
Given these search results, I not inclined to tweak task 21's code though I will make a note in the source should I ever decide to reuse it on another task.
—Trappist the monk (talk) 16:28, 5 October 2025 (UTC)[reply]
Sounds good. 460 is few enough that I'm tempted to go through and fix them all myself. Is this the sort of task that AWB would be useful for? Otherwise I could simply work through all the hits in your search by hand. Best, Wham2001 (talk) 19:11, 5 October 2025 (UTC)[reply]
Perhaps. This find regex:
(<ref\s+name\s*=\s*")[“”]([^\>]+)[“”]("\>)
and this replace:
$1$2$3
should be good for a start. The above won't fix stuff like <ref name="“”"> or <ref name="Historical Log 3C: Mutant-Hunting Exonims Begin “The Decimation”">.
—Trappist the monk (talk) 20:01, 5 October 2025 (UTC)[reply]
Note that search-and-replace will probably break articles like Diictodon in a different way. MediaWiki considers <ref name=“Ray2003”> and <ref name="“Ray2003”"> as being the same. The search-and-replace described here will only change <ref name="“Ray2003”"> to <ref name="Ray2003">, which MediaWiki will not consider the same as <ref name=“Ray2003”>, leaving one of the two orphaned. On the plus side, it looks like AnomieBOT will do the right thing with that to finish the fix. Anomie⚔ 00:08, 6 October 2025 (UTC)[reply]
Anomie: Right – if I do this using AWB I would want to check each edit manually before saving it. AIUI it lets you do this.
TTM: Thanks – in that case I will request access at PERM and give it a go. Best, Wham2001 (talk) 09:27, 6 October 2025 (UTC)[reply]
I note the summary is not quite correct, it's broken already after Monkbot's edit. See the error in Special:Diff/1314161747#Lifestyle for example. Anomie⚔ 23:46, 5 October 2025 (UTC)[reply]
That said, the suggested fix seems reasonable enough since the bot already has a similar fix for <ref name=''foo''>. Anomie⚔ 23:53, 5 October 2025 (UTC)[reply]
You're quite right – I didn't check the article state between the two edits carefully enough. Wham2001 (talk) 09:25, 6 October 2025 (UTC)[reply]

COI tag Rowan Winch

[edit]

Hi @AnomieBOT, I saw you tag the above article with COI, could you explain why do you thing the creator has COI? Uncle Bash007 (talk) 21:48, 5 October 2025 (UTC)[reply]

Look more closely at AnomieBOT's edit, it only added |date=September 2025 to a tag added by another editor in an earlier edit. Anomie⚔ 23:56, 5 October 2025 (UTC)[reply]

Druze

[edit]

I'm curious why AnomieBOT only substituted some of the instances of {{Format ISBN}} and not all of them in this edit: https://en.wikipedia.org/w/index.php?title=Druze&diff=prev&oldid=1313816758 --Lexiconaut (talk) 03:13, 6 October 2025 (UTC)[reply]

Some of AnomieBOT's wikitext processing hasn't kept up with certain changes in MediaWiki over the years. In this case, AnomieBOT saw the <!-- near the end of line 505 (not far after the last instance of the template it did subst) as beginning a comment which contains the rest of the article, while MediaWiki's parser at some point changed to ignore a <!-- not matched by a -->. Probably I should look at changing that in AnomieBOT one of these days. Anomie⚔ 03:23, 6 October 2025 (UTC)[reply]
Turns out it's a bit more complex than that. MediaWiki actually does still let an unclosed comment run out, the tricky part is that an unclosed comment inside an extension tag like <ref> only runs to the end of the tag, not to the end of the document. For that matter, if you try to do like <ref> ... <nowiki></ref></nowiki>, MediaWiki sees that as an unclosed <nowiki> inside a <ref> rather than an unclosed <ref>, while currently AnomieBOT's "strip_nowikis" function would see it as the opposite. I'll have to adjust AnomieBOT's code that "strips" comments and nowikis to take this into account. Anomie⚔ 17:22, 6 October 2025 (UTC)[reply]
Thanks very much for your reply. I have been seeing more unclosed <!-- inside <ref></ref> recently. I can't figure out why they are suddenly popping up. I've removed the offending <!--. --Lexiconaut (talk) 17:52, 6 October 2025 (UTC)[reply]
I think what often happens is that someone does something like {{cite whatever |blah=... |blah3=... <!-- |blah2=... -->}}, and then other bots or scripts try to reorder the parameters or otherwise adjust parameters without properly handling comments (e.g. {{cite whatever |blah=... |blah2=... --> |blah3=... <!--}}). See Wikipedia talk:ProveIt#Does not properly handle commented-out parameters in cite templates for one example.
In this case with Druze, it looks like Monkbot saw {{cite journal |... |jstor=25802822<!-- |access-date=22 November 2023 -->}} and decided to remove the access-date non-parameter in Special:Diff/1313811285. @Trappist the monk: for info. Anomie⚔ 18:38, 6 October 2025 (UTC)[reply]
Nice find! Interestingly, Monkbot only changed one instance of a commented-out access-date; there's another instance further up in that diff that the bot didn't change. --Lexiconaut (talk) 19:11, 6 October 2025 (UTC)[reply]
Looks like the other three in the article weren't actually parameters to the template, they were like <ref>{{cite whatever}}<!--|access-date=...--></ref>. Looks like those probably go back to Special:Diff/724728852 from 2016. Anomie⚔ 19:39, 6 October 2025 (UTC)[reply]
(edit conflict)
Monkbot deletes |access-date= parameters that exist in a cs1|2 template when that template does not have |url= (or one of the |chapter-url= aliases). The commented-out |access-date= parameters that were not deleted are outside of cs1|2 templates so were ignored.
I have modified the task to delete the parameter and its assigned value (must be one of the permitted date formats) commented or not. The bot will then delete the <!--...--> markup if empty. Right now this applies only to |access-date=.
—Trappist the monk (talk) 19:45, 6 October 2025 (UTC)[reply]

User:AnomieBOT III

[edit]

Hello, Anomie,

I think that AnomieBOT III needs to be restarted. It missed its last reporting cycle reports. Thanks. Liz Read! Talk! 22:42, 10 October 2025 (UTC)[reply]

Looks like it's running fine? The BrokenRedirectDeleter task made its last update at 20:20 UTC, and will be due for the next shortly after 02:20. Anomie⚔ 00:40, 11 October 2025 (UTC)[reply]