Wikipedia talk:Article alerts/Bugs

Use this page to report bugs in the reports, such as articles not picked up by AAlertBot, incorrect information, broken links, etc. See How to Report Bugs Effectively for advice on how to write bug reports.

Click here to report a new bug about Article Alerts bot.

Please make sure it is not listed below.

	It didn't report a page being discussed in a workflow in my WikiProject
	Make sure that your WikiProject's banner is present on the talk page of the article being discussed. While talk page tagging is the most reliable way to include a page in the article alerts, your project may also subscribe to article alerts via different ways (e.g. categories, deletion sorting). You can customize subscription options at your project's subscription settings to catch some of those untagged articles.
	It says a page is "closed" and does not provide details
	Not all workflow closure details have been implemented. Some will just show closed when the page is removed from the workflow (deleted, moves, merged, promoted, etc.)
	Discussion page is a red-link
	Some discussion pages await creation until a reviewer/commenter does so. The bot should say "start discussion" for red-links. That said, if the page linked to is wrong, report this please.
	Wrong user/time for an article entry
	First, please check that this has not arisen due to vandalism of the page, i.e., a vandal removed the workflow tag and it was subsequently restored. If this is not the case, please report below.
	Workflow X isn't covered
	See Wikipedia:Article alerts/Workflows for a current list of what is/is not covered at the moment. Request new workflows on feature requests page.
	Old bot did X before, it doesn't do it now
	Not everything is yet implemented from the previous bot's specification. Please do bring up crucial features on discussion page or new features on feature requests page.

Subst templates in archived

  New bug

Filled by: H3llkn0wz (talk · contribs)

Time filed: 09:49, 22 May 2011 (UTC)

Link(s):

Comments:

Subst: expensive parser and unneeded templates in archive pages. Some are reaching limit and the load times are high. —  HELLKNOWZ  ▎TALK 09:49, 22 May 2011 (UTC)

WikiProject Disambiguation/Article alerts

  New bug

Filled by: France3470 (talk · contribs)

Time filed: 19:25, 24 June 2012 (UTC)

Link(s): Wikipedia:WikiProject Disambiguation/Article alerts, see the following requested moves:

• Talk:Daniel Ortiz#Requested move
• Talk:Arthur Forrest#Requested move
• Talk:Arthur Conway#Requested move

Comments: Not a bug per se. But I have noticed that for Wikipedia:WikiProject Disambiguation/Article alerts multi-moves involving disambiguation pages don't appear to be picked up. Since such multi-moves are a frequent occurrence for dab article might there be a way for to be changed. Thanks, France3470 (talk) 19:25, 24 June 2012 (UTC)

Thanks for report. To not repeat myself, I explained this below -- #Mass move nominations. —  HELLKNOWZ  ▎TALK 11:32, 9 August 2012 (UTC)

Bot mistakes deletion sorting templates substitution with participation in discussion

  New bug

Filled by: Czarkoff (talk · contribs)

Time filed: 12:06, 1 August 2012 (UTC)

Link(s): any AfD with {{delsort}} substitution

Comments:

Probably the bot should try to match the comments against {{subst:delsort}}. Unfortunately I have no knowledge of the bot's algorithm, so I can't propose any particular diff. — Dmitrij D. Czarkoff (talk) 12:06, 1 August 2012 (UTC)

Thanks for report. The bot does this slightly differently. It counts the number of participants from the page's history (contribs list), not the actual comments as I don't rely on signature parsing. It also takes away 1 from the totals if delsorts are detected (assuming the same user made all the delsorts). So, in the most cases, delsorts are actually taken into account and it's rarish that multiple users do delsorts. I'm sure I could come up with a diff where this isn't the case.

I didn't spend too much time on this, as the numbers are supposed to be approximations anyway since pure !vote counts and participant counts don't really matter and only arguments do. I could at some point make this parsing smarter, but the bot already eats a lot of resources checking each AfD each run. —  HELLKNOWZ  ▎TALK 11:30, 9 August 2012 (UTC)

Mass move nominations

  Bug fixed

Filled by: Fyunck(click) (talk)

Time filed: 08:58, 9 August 2012 (UTC)

Talk:Robert Varga (tennis): Talk:Robert Varga (tennis) – Requested move

Comments: Robert Varga (tennis) was put up for RM (in a multi-move) on August 7. It's August 9 and it has not appeared on article alerts for Wikipedia:WikiProject Tennis. Is it slow right now? I'm lucky I noticed it but other tennis editors will miss the ship if it doesn't show up a Tennis Project. Thanks. Fyunck(click) (talk) 08:58, 9 August 2012 (UTC)

Thanks for report. Well, the page is not in Category:Requested moves, so it wasn't picked up. And the bot doesn't parse the actual nomination text, where the multiple pages are listed. It's not really a bug, more like an unimplemented feature. But I am aware of this and know this needs doing.

It is a bit of a mess from algorithm perspective. The bot first attempts to get the list of all the pages that will need reporting (AfD, TfD, RM, etc.), and only then parse individual ones as needed for subscriptions/projects. For example, RMs come from Category:Requested moves and multiple nominated pages do not appear there. So, once the bot reads the actual multiple nominations, it would need to add these new pages to the list. However, projects to whom these pages belong may have already had their report delivered. For example, Hungary's report is delivered before Tennis' (alphabetically), and if bot discovers pages while checking Tennis-related RMs and one of those pages happens to belong to Hungary as well, it won't be delivered there anymore. Next run, same problem, as the pages don't appear in preliminary lists and bot would think they are removed from RMs until it again gets checking individual pages. However, it doesn't even check pages it has seen already because it is very big waste of resources (with 1k pages per run). I guess I would need to parse all the RMs prior to even starting writing reports. This is possible, but will need a bigger rewrite than a simple fix. That said, I can detect when {{requested move/dated|multiple=yes}} is used (I'll probably change the template to categorize pages) and check those only. Anyway, pardon the technicalities, just thinking aloud. —  HELLKNOWZ  ▎TALK 11:22, 9 August 2012 (UTC)

Actually it's interesting to hear you think aloud. I'd swear it didn't used to be this way. That when editors did multi-rms they were required to do it differently so that all articles under a multi-rm were listed under Category:Requested moves. It seems like I had to do it that way in the past myself... but it looks like no more. Fyunck(click) (talk) 22:31, 9 August 2012 (UTC)

@Fyunck(click): You're right! This predates my becoming active on Wikipedia, so I had to do some digging to find it... On 23 November 2006 Duja created Template:Multimove, a new template for multiple page moves, and updated the instructions to explain its intended use. {{Multimove}} populated Category:Requested moves. But it wasn't until two years later (31 December 2008) that the closing instuctions were updated to say "don't forget to remove the {{move}} tag from the talk page and {{multimove}} from the talk pages of any bundled pages." On 29 May 2009 Harej (the original RM bot operator) changed the procedure and removed these multimove instructions. The last version of the instuctions to request moving several pages at once looked like this. On 8 August 2009 Harej deprecated Template:Multimove, changing it to say "This template has been deprecated. A bot will post on this page that a move discussion is in progress." On 30 October 2009 Harej removed "and {{multimove}} from the talk pages of any bundled pages" from the closing instructions.

Now that I've reviewed the history of this, let's see if I can restore the old functionality using RMCD bot. I'm upgrading this to high priority, so expect a solution soon. wbm1058 (talk) 01:45, 31 March 2019 (UTC)

Contemporary discussions about this issue and the related changes I listed above are at Wikipedia talk:Requested moves/Archive 16 § Multimove integrated yet? and Wikipedia talk:Requested moves/Archive 16 § Phasing out multimove templates. Note that {{moveheader}} was userfied to User:Wbm1058/Template:Move header over six years ago, so that I could look at it (before I became an administrator). {{moveheader}} has been de facto superseded by by User:RMCD bot/subject notice. wbm1058 (talk) 16:48, 31 March 2019 (UTC)

• I know it's been a few years but I guess it's still treated as a bug. There's a mass move request at Wikipedia talk:WikiProject Outlines/Drafts/Outline of ancient history for Outlines that touch basically tons of other WikiProjects but it seems like there's no way to report to the all projects about the relevant requests in a sensible manner. -- Ricky81682 (talk) 08:56, 22 June 2016 (UTC)

• Another mass move request for List of rail accidents by country that includes 30 pages, but no notifications. I had been wondering why; good to see that it's a known problem. If we were to manually add Category:Requested moves to the relevant talk pages, would that solve the notification issue without upsetting anything else? And further to this, there is of course the option of changing the way your bot operates. But why aren't mass move pages not all be included in said category? Isn't that where the way things are done should be changed? Schwede66 18:54, 22 July 2016 (UTC)

• And another mass move request that's been filed. This time, I've gone through the talk pages manually and added the relevant category. And I've suggested that RMCD bot include that category when the talk page notifications are delivered. Let's see whether that will get some discussion going. Schwede66 20:40, 27 April 2018 (UTC)

• Since RMCD bot now also places {{User:RMCD bot/subject notice}} directly on the affected articles, I'm thinking that transcluding a category via that template should help address this issue. I've raised the idea at User talk:RMCD bot#Adding category via User:RMCD bot/subject notice?. --Paul_012 (talk) 05:28, 29 March 2019 (UTC)

Paul_012, see my reply to Fyunck(click) above. wbm1058 (talk) 01:45, 31 March 2019 (UTC)

@Hellknowz: Fixing this may require a little coordination between us. I looked for your source code, and found that when Community Tech asked to see it, you emailed them. I see above that you start processing RMs by working through Category:Requested moves. But that just gives you the pages requested to be moved; how do you identify the proposed new titles? I assume you read the talk pages in Category:Requested moves to locate the {{Requested move/dated}} template, and parse the move target parameter out of that. The original ArticleAlertbot which was coded in Java ran from September 2008 to April 2010, so it predated the requested moves bots, the first of which began operation in May 2009. As I mentioned above, {{Multimove}} was created in 2006 and from its beginning it added tagged articles to Category:Requested moves. I don't know whether the original Java version supported requested moves, but if it did, it likely would have looked for {{Multimove}} and parsed the move target parameter out of that. However {{Multimove}} was deprecated in August 2009, which inadvertently removed this needed support for the alerts bot. So, if {{Multimove}} support existed in the Java version, it would have been nonfunctional by the time you rewote it for your version of the alerts bot. But, if you didn't know it was nonfunctional, you may have ported the logic anyway. So, can you look to see whether the current code looks for {{Multimove}} as well as {{Requested move/dated}}? If it does, I can just restore that deleted template and update it for the current need to populate Category:Requested moves, and you may not need to update your code at all. If the current version doesn't look for {{Multimove}} then you will need to update your code to support this, and since you would be coding the check from scratch, I may make a new template as a subpage of RMCD bot, as with User:RMCD bot/subject notice that template would be "bot use only" (intended for placement and removal by the bot). Oh, I see you just tagged the documentation, so you may be working on this. wbm1058 (talk) 13:47, 1 April 2019 (UTC)

I suppose getting all the pages transcluding User:RMCD bot/subject notice, as Paul suggested, would be another approach to this, but not all RMs may get subject-notice tags. If the page is admin-protected, that notice will only be placed if an admin (likely me) notices and places the tag, since the bot only has template-editor privileges. Also the bot is exclusion compliant (respects {{nobots}}) so an article so tagged will not have a notice of the talk page discussion of its requested move. wbm1058 (talk) 14:15, 1 April 2019 (UTC)

"when Community Tech asked to see it, you emailed them." -- The code would need an update to security and licensing if I were to publicly post it. It currently has stuff I can't disclose and stuff I can't license easily. But I can explain any details you need.

"you start processing RMs by working through Category:Requested moves" -- Yeah, that's how I currently get the list.

"But that just gives you the pages requested to be moved; how do you identify the proposed new titles? I assume you read the talk pages in Category:Requested moves to locate the {{Requested move/dated}} template, and parse the move target parameter out of that." -- Yes, I read the talk page of the article, find {{Requested move/dated}} and parse what page it points to. (I also parsed |multiple= to grab the first title from |new1=, but that hasn't existed for a while [1].) I never parsed multiple noms.

"So, if {{Multimove}} support existed in the Java version, it would have been nonfunctional by the time you rewote it for your version of the alerts bot. [..] you may have ported the logic anyway." -- I wrote everything from scratch, I never saw the old code. And I never used {{Multimove}} because it didn't exist. So I guess we don't need to worry about any of that.

"I can just restore that deleted template and update it for the current need to populate Category:Requested moves" -- That won't matter, because by the time the bot parses the talk page, it's too late to add more pages. This is the issue I detailed above. I need the pages to be detectable at the same time or I make a big concurrency mess.

"Oh, I see you just tagged the documentation, so you may be working on this." -- I am thinking to just use this template for key info -- detecting pages, getting the discussion page and section, and getting the new name (which I don't need to do, but it's convenient). I would still parse the talk page for date and author and later for closure. I'm still early testing the viability and I was going to ask you some details in a little while, but you beat me to it :)

See also User:AAlertBot/Workflows near "RM" workflow, it has some hints on what the bot does. —  HELLKNOWZ   ▎TALK 14:15, 1 April 2019 (UTC)

• Code = RM
• Name = "Requested moves"
• PageListRetrievalMethod = FromCategory
• PageListNamespace = ArticleTalk
• PageListRetrievalSources[1] = → Category:Requested moves
• ResponsibleTemplateNames[1] = → Template:Requested move/dated
• ResponsibleTemplateNames[2] = → Template:movereq

You could just add:

• ResponsibleTemplateNames[3] = → User:RMCD bot/multimove ...if I create that. Both Template:Requested move/dated and User:RMCD bot/multimove would populate Category:Requested moves; you would get them all from there at the same time to avoid concurrency issues. User:RMCD bot/multimove would be a different template (not a redirect) which simply populated the category. I could use the same parameter syntax as Template:Requested move/dated though. wbm1058 (talk) 14:36, 1 April 2019 (UTC)
  • Yes, if you add {{User:RMCD bot/multimove}}, I can use that to detect pages from Category:Requested moves. But I would still need some sort of data from this template about where the actual discussion is. It doesn't need to be the same as {{Requested move/dated}} (I don't think anyone cares besides bots). So you could just use the same parameters as {{User:RMCD bot/subject notice}}. —  HELLKNOWZ   ▎TALK 14:46, 1 April 2019 (UTC)
    • OK, the bot has made a test edit to THIS PAGE. That should be sufficient for the ArticleAlerts bot. wbm1058 (talk) 17:14, 1 April 2019 (UTC)

RMCD bot would be responsible for removing User:RMCD bot/multimove from talk pages after the discussion closed. It would work similarly to the automated removal of User:RMCD bot/subject notice from closed discussions. Of course, if the closing administrator removes those without waiting for the bot to do it, that's fine. The bot just saves the closing admins the bother of that task, and ensures that the notices are removed in a timely manner. wbm1058 (talk) 14:46, 1 April 2019 (UTC)

How do we keep commenting within seconds... —  HELLKNOWZ   ▎TALK 17:15, 1 April 2019 (UTC)

Good question – coinkydink, or because today is April 1?! These came _that close_ to being edit conflicts. I didn't see your edits before I saved mine. wbm1058 (talk) 17:28, 1 April 2019 (UTC)

So I think I can do multi-page requests fine now: [2]. I'm using {{User:RMCD bot/subject notice}} to find these and {{Requested move/dated}} to parse extra detail. (This isn't live.) I will change this to {{User:RMCD bot/multimove}} once I can test it. Could you please document the parameters that {{User:RMCD bot/multimove}} is going to have, so it's clear and I don't make any incorrect assumptions. —  HELLKNOWZ   ▎TALK 17:13, 1 April 2019 (UTC)

I just used the parameters for the subject notice, as you suggested.

{{User:RMCD bot/multimove|1=List of Annoying Orange episodes|2=Talk:The Annoying Orange#Requested move 31 March 2019 }}

1= the requested new title for the page

2= the page and section hosting the discussion. – wbm1058 (talk) 17:28, 1 April 2019 (UTC)

I think I won't use the |1= and parse {{Requested move/dated}} directly since I need to read the page for that template anyway most of the time. But, out of curiosity, how does the bot handle {{Requested move/dated|?}} / {{Requested move/dated|new1=?}} cases -- what's set in |1=?

See THIS DIFF for an example. I just write the single ? character, and the bot knows that isn't literally meant to mean the ? article about the question mark. There would be a bit of a syntax conflict if anyone ever proposed moving question mark to ?, but I guess I'll wait to cross that bridge when I see it. wbm1058 (talk) 21:45, 2 April 2019 (UTC)

Heh, I'm glad today is April 2, and not the first. wbm1058 (talk) 21:57, 2 April 2019 (UTC)

I'm using {{User:RMCD bot/multimove}} now and it looks good: [3] -- all three cases work (single nom, multi nom self, multi nom other).

Technical stuff follows, mostly for my own future reference. Weirdly, this approach actually means that I have to do more parsing and add more options for the workflow. Even though all the pages are now in the Category:Requested moves, which let's me find them easily, the "responsible template" for adding them to the category can be either {{Requested move/dated}} or {{User:RMCD bot/multimove}}. I don't know which one until I parse the talk page. Once I do, I get the actual template and therefore can parse the actual discussion location. I already had (most of) the logic to construct the discussion page name based on which template is "responsible". I use either |1= from {{User:RMCD bot/multimove}} or the section under which {{Requested move/dated}} is added. So far so good, but now I need to parse the {{Requested move/dated}} for the target page and addition revision for date/user, which is what every other workflow does. But the responsible template I have could very well be {{User:RMCD bot/multimove}} and the user/date there are not correct. In fact, I need to read the discussion page which definitely has the {{Requested move/dated}} template. I can't encode this into workflow options without making a mess, so I need to add this as separate options. So I added "auxiliary" template, which is only {{Requested move/dated}}. And I specify options to parse further values from the (1) discussion page and the (2) auxiliary template instead of the "normal" location where the responsible template is. So the second step of further parsing (which normally runs on the same responsible template and page) can instead choose a different page and different template to use for further parsing, which is how RMs get their user/date/target values. —  HELLKNOWZ   ▎TALK 12:36, 2 April 2019 (UTC)

I've implemented the basic code changes for this. I see that on Wikipedia:Requested moves/Article alerts all of these multimoves are listed as undated. Also, it can be hard to track down some of the discussions after they close if the pages are moved, especially in cases where a disambiguation page was involved and there was a change in primary topic. I'd still like to implement improved mechanisms on my end for tracking down these discussions after they've been closed and moved elsewhere. – wbm1058 (talk) 14:00, 8 April 2019 (UTC)

I still need to push the update that implements the above functionality. The bot found these pages because of Category:Requested moves (but then failed to read the discussion from the talk page).

Detecting what happens to the discussion is definitely not straight-forward. I am doing this as well for the closure results, but there are just so many things that can happen to it. It's further complicated for me by the fact that the bot needs to "repair" other records when people move pages during active discussions, like during TfD or something. —  HELLKNOWZ   ▎TALK 16:19, 8 April 2019 (UTC)

Something happened on a particular run of my bot that made it remove all these new notices. Probably a bug in my code... I need to investigate. wbm1058 (talk) 13:53, 11 April 2019 (UTC)

Fixed. Yes, someone combined two requests into a multi request, and then updated the bot's notice, rather than letting my bot do it. Just the presence of underscores in a title is enough to make it "different" when compared to the title with spaces instead of underscores. I suppose Murphy's Law says I should make my bot check for this, as it's likely someone else will make similar edits in the future. wbm1058 (talk) 00:23, 13 April 2019 (UTC)

Update now live with (mostly) dated multi-noms. —  HELLKNOWZ   ▎TALK 09:49, 31 July 2019 (UTC)

Duplicate archive entries again 2

  New bug

Filled by: Sir Sputnik (talk · contribs)

Time filed: 17:10, 11 May 2013 (UTC)

Link(s):

• 1
• 2

Comments: Like the last two times I posted here, articles are being listed several times in the archive for the WikiProject:Football. The first of the two links above is the first duplicate posting in this set, the second is the most recent one. Sir Sputnik (talk) 17:10, 11 May 2013 (UTC)

Thanks for report. Okay, so this definitely happens when I/Headbomb switch who is running at the time [4]. I couldn't reproduce this on my own last two times after I fixed the initial issue. So this definitely has to do with something going wrong if bot is transitioned to run on different computers. I'll look into it. —  HELLKNOWZ  ▎TALK 17:20, 11 May 2013 (UTC)

Missing date and names for MfD

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 15:08, 29 September 2014 (UTC)

Link(s): [5]

Comments: For some reason, the bot is missing some dates and for MfDs. Handles group nomination well however. Headbomb {talk / contribs / physics / books} 15:08, 29 September 2014 (UTC)

Without example, I assume the MfD tag template was substituted incorrectly. This is reason for no date for like 95% of the cases. —  HELLKNOWZ  ▎TALK 15:56, 26 June 2015 (UTC)

Closed TfDs not being removed

  New bug

For some reason, two TfDs that were closed in March and April are not being removed from Wikipedia:WikiProject Elections and Referendums/Article alerts by the bot. Any ideas why? Number 57 14:28, 30 September 2014 (UTC)

I suspect that it has to do with the facts that both templates are still tagged with {{being merged}}, which make them populate Category:Templates for deletion. Headbomb {talk / contribs / physics / books} 15:34, 30 September 2014 (UTC)

I'll see about detecting when a page is in a the TfD "holding cell" (Wikipedia talk:Article alerts/Feature requests#TfD holding cell) at "some point". —  HELLKNOWZ  ▎TALK 16:00, 26 June 2015 (UTC)

RFD bug

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 13:00, 29 August 2015 (UTC)

Link(s): [6]

Comments: The bot correctly reports the RFD in the edit summary, but the RFD itself is missing from the reports. Headbomb {talk / contribs / physics / books} 13:00, 29 August 2015 (UTC)

• Just saw this today: [7]. Mackensen (talk) 13:00, 22 October 2015 (UTC)

Untagged RfDs don't get archived

  Not a bug  (Archiving)

  Rare unfixable corner-case  (date prediction)

Filled by: Hellknowz (talk · contribs)

Time filed: 23:07, 21 February 2016 (UTC)

Link(s): [8][9]

Comments: See also [10] where things don't get archived either. Headbomb {talk / contribs / physics / books} 17:54, 7 April 2016 (UTC)

Can you be more specific? I see report removing entries and archive adding entries. I don't see any removals in [11]. —  HELLKNOWZ  ▎TALK 21:48, 7 April 2016 (UTC)

I meant the bunch of undated entries that date back to ~Summer 2015. Headbomb {talk / contribs / physics / books} 00:37, 8 April 2016 (UTC)

Undated do get archived, just pretty late, something like archive time * 2 + week (and physics has 60 days archive). I think I mentioned somewhere I need to add a date the record itself was created/closed, so I can use that for when the date is missing. —  HELLKNOWZ  ▎TALK 12:56, 8 April 2016 (UTC)

I thought that behaviour had been changed? Guess not. What is the purpose of haveing a double+ archive time?Headbomb {talk / contribs / physics / books} 14:33, 8 April 2016 (UTC)

Because default is 7 days and most workflows are also 7 days (AfD). If it's undated and I only wait 7 days from creation (and something like RM that sit there for decades), then it would never appear as closed before getting archived. So it's 2*7 plus something. I don't remember the actual number, but with 60 day archival it's pretty high, though not as high as it used to be. —  HELLKNOWZ  ▎TALK 15:04, 8 April 2016 (UTC)

So why not just archivetime + 7? Headbomb {talk / contribs / physics / books} 15:30, 8 April 2016 (UTC)

In any case, the underlying issues of undated entries should get fixed. The special handling of undated is basically a workaround. I might make some bug reports for better handling of undated, but I believe I already have them in FRs. —  HELLKNOWZ   ▎TALK 09:58, 31 July 2019 (UTC)

Undated A-class reviews

  New bug

Filled by: Peacemaker67 (talk · contribs)

Time filed: 09:25, 14 April 2017 (UTC)

Link(s): Wikipedia:WikiProject Military history/Article alerts

Comments: The A-class reviews are undated. Cheers, Peacemaker67 (click to talk to me) 09:25, 14 April 2017 (UTC)

Any chance this could be fixed? Thanks, Peacemaker67 (click to talk to me) 09:00, 1 October 2019 (UTC)

The problem with A-class is that different projects have different A-class syntax. For example, it used to at least partly work for MILHIST, but since then something changed and now it doesn't. It's really difficult to implement this, because the whole system assumes a consistent syntax for a workflow, like AfD not changing based on specific project. I could theoretically fix it for, say, MILHIST, but then it breaks for other projects. And the worst part is when a page belongs to multiple projects with A-class rating. Now the bot has no idea how to treat it and I doubt this is something I can reasonably implement.

I'm afraid I am very busy in real-life for at least a few months, so I don't have time to do such extensive modification to the code right now. I had previously spent way too long just on A-class implementation, and I honestly can't justify this much volunteer time on something that is essentially edge cases. It should really be a standard workflow, like GAN or FAC or something. Anyway, I know this is an issue and I am keeping it in mind, but I can't make promises to work on it at the moment. —  HELLKNOWZ   ▎TALK 09:50, 1 October 2019 (UTC)

Ah, OK I get it. Hadn't quite thought that one through to its logical conclusion. I totally understand the reticence to commit time to what must be a moving feast. Thanks anyway. Peacemaker67 (click to talk to me) 10:07, 1 October 2019 (UTC)

TfM not picked up

  Bug fixed

Moved from Wikipedia talk:Article alerts#Missed TfD for WikiProject Shakespeare

Template:Infobox Shakespearean character was TfD'ed on 29 April (and closed today), but never showed up on WikiProject Shakespeare's alerts page. The template is tagged with the project's banner, and other article alerts have been updated at least as late as 8 April (which is also, apart from this TfD, the last relevant process to affect the project's articles that I'm aware of). I'm also not aware of any changes to the project banner, the project's article alerts subpage, or its subscription. The other WikiProject that has tagged the template also did not get an alert for this TfD so far as I can tell. And I can't immediately spot anything about the format of the TfD itself that might trip up the bot, nor find anything in the public log, and I see it picking up other TfDs today. Anything else I should check before concluding ArticleAlertBot had a hickup somewhere? --Xover (talk) 11:53, 7 May 2019 (UTC)

Wikipedia:WikiProject Shakespeare/Article alerts hasn't been updated since 8 April. I thought at first that there could be a problem with the settings for that project; but I checked the contents of the (now deleted) template talk page, which was:

{{WikiProject Shakespeare|class=Template|importance=Low}}
{{WikiProject Fictional characters|class=template}}
{{tfdend|date=29 November 2010|result=no consensus}}

Now {{WikiProject Fictional characters}} is also set to trigger an article alert, at Wikipedia:WikiProject Fictional characters/Article alerts - but the infobox wasn't listed there either. Since the latter did receive other updates in this period, the bot must have been ignoring either the Tfd or the whole of the template talk page. --Redrose64 🌹 (talk) 14:21, 7 May 2019 (UTC)

The page wasn't picked up because the bot only looks for {{Template for discussion/dated}}. (And if it cannot find it, it skips reporting the TfD even as undated, because the likeliest scenario is that the user transcluded the nomination and polluted the category, which has happened before with hundreds of unrelated pages "nominated".) I don't know what {{Template:Infobox Shakespearean character}} had, but {{Infobox character}} had {{Tfm/dated}} from {{Tfm}}, which the bot doesn't know about. I didn't realize this was a separate template, so I need to use that. On a related note, it also doesn't pick up Modules. —  HELLKNOWZ   ▎TALK 15:37, 7 May 2019 (UTC)

The TfD proposal was to merge into {{Infobox character}}, so it's indeed highly likely that both had {{Tfm/dated}}. So, mystery cleared up it seems. Thanks! --Xover (talk) 15:45, 7 May 2019 (UTC)

Yes, it had

{{Tfm/dated|page=Infobox Shakespearean character|otherpage=Infobox character|link=Wikipedia:Templates for discussion/Log/2019 April 29#Template:Infobox Shakespearean character|type=sidebar|help=off|bigbox={{#invoke:Noinclude|noinclude|text=yes}}}}

so indeed it was {{Tfm/dated}} --Redrose64 🌹 (talk) 16:24, 7 May 2019 (UTC)

Fixed next update. —  HELLKNOWZ   ▎TALK 10:07, 21 July 2019 (UTC)

Now live. —  HELLKNOWZ   ▎TALK 09:54, 31 July 2019 (UTC)

Modules not reported for TfD

  Bug fixed

Filled by: Hellknowz (talk · contribs)

Time filed: 16:06, 7 May 2019 (UTC)

Link(s):

Comments:

Fixing next update. —  HELLKNOWZ   ▎TALK 10:05, 21 July 2019 (UTC)

Now live (haven't checked, but it's straight-forward). —  HELLKNOWZ   ▎TALK 09:54, 31 July 2019 (UTC)

Mishandling multiple RfCs on one talk page

  Rare unfixable corner-case  (Outside bot's design)

Filled by: Bradv (talk · contribs)

Time filed: 16:43, 25 May 2019 (UTC)

Link(s):

• Wikipedia:WikiProject Canada/Article alerts diff
• Talk:SNC-Lavalin affair#RfC: LavScam
• Talk:SNC-Lavalin affair#RfC: political scandal?

Comments: The bot is creating the article alert for the current RfC, but using the date and author from the previous closed RfC, which is still on the talk page. Wikipedia:Requests for comment/Politics, government, and law shows the correct information. – bradv🍁 16:43, 25 May 2019 (UTC)

Pinging Safrolic who raised the issue on my talk page. – bradv🍁 16:44, 25 May 2019 (UTC)

Thanks for reporting. Yeah, the bot doesn't do well with multiples of the same workflow. To the bot, a page is either in a workflow or not in a workflow. For RfC date and user, the bot looks for the RfC template insertion, and this fails when there was a previous one already like in the reported case here. In contrast, the RFC bot searches and parses sections and reads the user/date from there (I am like 85% sure that how it works), which isn't how AAB does it. And I can't really fix this easily. When the bot was designed, I didn't consider that the same workflow can be active multiple times for the same page, since none of the other workflows (AfD, RM, etc.) can (the only other comparable exception is ACR, which is project-dependent and the bot also breaks on it half the time). I will think about this, but I cannot promise fixing this soon. —  HELLKNOWZ   ▎TALK 19:52, 25 May 2019 (UTC)

By "RFC bot", do you mean Legobot (talk · contribs)? If so, this bot ignores sections and signatures. See source on github, in which this is the relevant regexp:

"/\{{2}\s?Rfc(tag)?\s?[^}]*\}{2}(.|\n)*?([0-2]\d):([0-5]\d),\s(\d{1,2})\s(\w*)\s(\d{4})\s\(UTC\)/im"

As I understand it, this looks for the five-character sequence "{{rfc" (case-insensitive) which it takes as the start of an open RfC; the next valid timestamp is taken as the end of the RfC statement. Anything that occurs after that timestamp is ignored unless another instance of "{{rfc" is found on the same page. User signatures before the timestamp are treated as text. That timestamp is also used as the start time for the purposes of calculating the 30-day duration of the RfC. --Redrose64 🌹 (talk) 21:10, 25 May 2019 (UTC)

Hmm, yeah, I guess it doesn't care about sections, just the occurrences of rfc templates. —  HELLKNOWZ   ▎TALK 21:50, 25 May 2019 (UTC)

I'm gonna tag this as unfixable for now, because having multiples of the same workflow on a page is basically impossible for the bot to detect. This happens very rarely and only for stuff like RfC and I can't really justify such a major rework. Unfortunately that means a rare missing/incorrect RfC. —  HELLKNOWZ   ▎TALK 10:02, 31 July 2019 (UTC)

Unfortunately, it does happen, particularly on (i) general discussion pages like WP:VPR and (ii) the talk pages of controversial articles. To illustrate the latter, Talk:Electric smoking system had, at one point less than a month ago, no fewer than eight open RfCs, but they're all gone now. --Redrose64 🌹 (talk) 13:05, 31 July 2019 (UTC)

I might consider smarter parsing to list all RfCs on a page, but it will still consider it a single entry. That might suffice, although the dates and users will likely be broken. —  HELLKNOWZ   ▎TALK 14:26, 31 July 2019 (UTC)

RFD gets removed upon relisting

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 23:18, 1 June 2019 (UTC)

Link(s): See [12], while Journal of the American Society of Nephrology : JASN is relisted.

Comments: And later re-appears... [13]. Headbomb {t · c · p · b} 13:23, 2 June 2019 (UTC)

I have no idea why. The bot doesn't care about relists. Nothing that I can see in histories changed. —  HELLKNOWZ   ▎TALK 14:52, 2 June 2019 (UTC)

Remove FPOC

  Bug fixed

Filled by: Hellknowz (talk · contribs)

Time filed: 10:22, 21 July 2019 (UTC)

Comments:

FPOC is deprecated, templates are being removed. It was removed from bot's list, but of course it's still being reported with 0 pages.

Anyway, removed in next update. —  HELLKNOWZ   ▎TALK 10:22, 21 July 2019 (UTC)

Now removed. —  HELLKNOWZ   ▎TALK 09:49, 31 July 2019 (UTC)

File reported

  Bug fixed

Hi, the alert appears to be reporting File:OOjs UI icon edit-ltr-progressive.svg but there is no talk page for any project tags to be on. Keith D (talk) 19:49, 23 July 2019 (UTC)

Yeah, I had a lot of trouble with this one today, it crashed the bot and everything. The bot reports images in FFD if they are used by any of the project's articles. So if page Sun uses File:Sun.png, it will get reported in Astronomy AA. In this case though, it's used on 687,798 pages, so technically pretty much every project had it reported as some page of theirs ends up using it (but of course the exact pages aren't listed, because there are 670k of them). I didn't really think of this case before.

I need to add a bunch of limits so the bot ignores such files. I thought I did so for today, but I messed something up. —  HELLKNOWZ   ▎TALK 20:32, 23 July 2019 (UTC)

Files with too many page usages won't be reported next update (although it's probably too late for this one before I can push it). New pages won't get added to workflow list. Old records will get (silently) removed. FFD has a workflow param to limit it to 100. Ideally, it would limit to the number of subscriptions, but that's too much effort for this corner case. It would still (theoretically) report if it the file itself belongs to a project, just not based on its usages. —  HELLKNOWZ   ▎TALK 10:44, 27 July 2019 (UTC)

Now live (and removed from all reports). —  HELLKNOWZ   ▎TALK 09:55, 31 July 2019 (UTC)

Still in Wikipedia:WikiProject Agriculture/Livestock task force/Article alerts Headbomb {t · c · p · b} 11:50, 31 July 2019 (UTC)

It is also still in Wikipedia:WikiProject Elements/Article alerts. I was under the impression that the bot only reports pages whose talk pages are tagged as part of the WikiProject (in this case, {{WP Elements}}). ComplexRational (talk) 01:31, 2 August 2019 (UTC)

Attempt #2. The file got readded (simply put) due to different circumstances on the follow-up run. Once the bot sees it and decides it wants to report it, it's really hard to flush it out of the system... I manually hard-coded it to skip it. —  HELLKNOWZ   ▎TALK 12:14, 2 August 2019 (UTC)

Too much content before AfD closure makes bot skip it

  New bug

Filled by: Hellknowz (talk · contribs)

Time filed: 08:17, 28 July 2019 (UTC)

Link(s): [14]

Comments:

By design, but it seems there are valid cases like the link. —  HELLKNOWZ   ▎TALK 08:17, 28 July 2019 (UTC)

Didn't skip over vandalism in history parse

  New bug

Filled by: Hellknowz (talk · contribs)

Time filed: 10:47, 30 July 2019 (UTC)

Link(s): [15] [16]

Comments:

• 12 Dec 2018 – Society for the Prevention of Cruelty to Animals (talk · edit · hist) is proposed for merging to List of animal welfare organizations by ClueBot NG (t · c); see discussion

Not sure why. —  HELLKNOWZ   ▎TALK 10:47, 30 July 2019 (UTC)

Not sure I see the bug/issue here? Headbomb {t · c · p · b} 10:57, 30 July 2019 (UTC)

Oh, cluebot. Headbomb {t · c · p · b} 11:02, 30 July 2019 (UTC)

Incorrect discussion link

  New bug

Filled by: Keith D (talk · contribs)

Time filed: 22:05, 30 July 2019 (UTC)

Link(s): [17]

Comments: The BOT has added 2 "Articles to be merged" entries but for the first of the entries the discussion link is to the incorrect talk page as the discussion is on the talk page of the second entry.

Thanks for reporting. I now realize that the default discussion location is implied depending on the template. The problem is getting the merge "directions" as otherwise the bot reports both articles, which isn't actually what I wanted, as I expected there to be {{merge to}} and {{merge from}}, not {{merge}} and {{merge to}}. —  HELLKNOWZ   ▎TALK 09:48, 31 July 2019 (UTC)

Not sure if this edit is the same issue- I added {{merge to}} to two pages (Buddhist prayer beads & Buddha chitta mala), the proper discussion link is the merge target page (Talk: Japamala), but in the Alert page the discussion link is to the talk page of the two pages being merged from. --Spasemunki (talk) 23:52, 27 January 2020 (UTC)

Similar issue: National Optical Astronomy Observatory had a {{merge}} tag for several months; other page NOIRLab had no tag; there was no discussion section on either article's talk page. Replaced existing tag on source page with {{merge to}}, and added tag {{merge from}} on destination page. However, article alerts for Wikipedia:WikiProject Astronomy is linking to wrong talk page for discussion. 13:56, 20 January 2021 (UTC) — Preceding unsigned comment added by 2603:4011:0:0:0:0:0:92 (talk)

The bot doesn't recheck the pages it has seen because of how many resources that would need. I will manually add the page for a recheck. But otherwise there's not much to be done for any workflow if pages change something like this. I haven't yet investigated the use of merge template combos, but they seem to be overly inconsistent. —  HELLKNOWZ   ▎TALK 14:12, 20 January 2021 (UTC)

That actually did not fix the link to the merge proposal discussion, even though it refreshed the date. Is there a bug? 2603:4010:0:0:0:0:0:23 (talk) 11:57, 22 January 2021 (UTC)

AFC submission date should use most recent submission

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 07:35, 31 July 2019 (UTC)

Link(s): See [18], which reports Draft:SoftwareX as dated from '25 Jan 2019'. Whereas the current submission's timestamp is 20190728231814 → 28 July 2019. Headbomb {t · c · p · b} 07:35, 31 July 2019 (UTC)

• You can tell it's the most recent submission by the empty |1= in the {{AFC submission}}. Headbomb {t · c · p · b} 07:36, 31 July 2019 (UTC)

I think you can also tell by the most recent date category in Category:AfC submissions by date. Headbomb {t · c · p · b} 08:19, 19 March 2020 (UTC)

Comments:

• old sub, new sub. —  HELLKNOWZ   ▎TALK 08:34, 31 July 2019 (UTC)

AFC closure weirdness

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 10:11, 31 July 2019 (UTC)

Link(s): [19]

Comments:

---

In the 30 July 2019 report, we had

• 23 Jul 2019 – Draft:Communications Physics
• 04 Jul 2019 – Draft:Biologia Plantarum
• 02 Jun 2019 – Draft:Berkeley Journal of Criminal Law
• 25 Jan 2019 – Draft:SoftwareX
• 15 Jun 2018 – Draft:Psychreg

In the 31 July report, we had

• 02 Jun 2019 – Draft:Berkeley Journal of Criminal Law
• 25 Jan 2019 – Draft:SoftwareX

and Archives 2 had

• 04 Jul 2019 – Draft:Biologia Plantarum submitted for AfC by HonzaKolar was closed

---

So a few things were. The declined wasn't reported (Draft:Communications Physics), and Draft:Psychreg (moved into mainspace) just disappeared. It probably would a good idea to keep the items in the listing for a few days [1 archive time? 7 days?] after 'closure'. Headbomb {t · c · p · b} 10:11, 31 July 2019 (UTC)

Possibly a one time thing due to dropped pages due to bot crashes. Headbomb {t · c · p · b} 10:12, 31 July 2019 (UTC)

The premature archiving is fixed at #Closure date based on close date, which is a slightly bigger overall thing. No idea where Draft:Communications Physics went. Likely one-time bug. —  HELLKNOWZ   ▎TALK 11:35, 1 August 2019 (UTC)

AfC promotion

  Bug fixed   (tagged with banner)

  New bug  (without banner)

Filled by: Hellknowz (talk · contribs)

Time filed: 10:42, 31 July 2019 (UTC)

Link(s): [20]

Comments:

Moved to mainspace = promoted. Need to parse talk page banner. —  HELLKNOWZ   ▎TALK 10:42, 31 July 2019 (UTC)

Redirected drafts detected and talk page parsed for closure properly, e.g. [21]. Current closed and prematurely archived stuff (#Closure date based on close date) won't appear. —  HELLKNOWZ   ▎TALK 11:33, 1 August 2019 (UTC)

Pages moves to mainspace without placing the banner on talk page don't get closure details. I need to manually parse the move. Might also mention if it's the author moving it (like deprods). —  HELLKNOWZ   ▎TALK 12:21, 2 August 2019 (UTC)

Closure date based on close date

  Bug fixed   (dated closure)

  New bug  (undated closure)

Filled by: Hellknowz (talk · contribs)

Time filed: 11:32, 1 August 2019 (UTC)

Link(s): every other report

Comments:

Was based on open date. This leads to workflows that are active for more than a week to fall off quicker than archive time. So really old ones got archived instantly. Now using the actual closure date + archive time. Undated will keep using open date + archive time + 7. —  HELLKNOWZ   ▎TALK 11:32, 1 August 2019 (UTC)

workflows = !AFC ignored

  Not a bug

Filled by: Headbomb (talk · contribs)

Time filed: 12:22, 11 August 2019 (UTC)

Link(s): See Wikipedia:WikiProject Articles for creation/Article alerts#AFC despite the subscription page having |workflows=!AFC

Comments:

"!AFC" means "The workflows I want is not AFC". So no workflows are selected, because that value doesn't say what workflows you want. Technically, it's working as intended, because no reports have been delivered since. What you want is "ALL, !AFC". I'll make the bot throw a warning if this happens. —  HELLKNOWZ   ▎TALK 09:37, 12 August 2019 (UTC)

Fixed. Stupid brainfart. Headbomb {t · c · p · b} 11:32, 12 August 2019 (UTC)

It still includes the AFC stuff btw. Should that just be manually deleted? Headbomb {t · c · p · b} 17:59, 14 August 2019 (UTC)

The code is "ALL", not "All". —  HELLKNOWZ   ▎TALK 18:18, 14 August 2019 (UTC)

WikiProject Banners being transcluded on log pages

  Bug fixed

Filled by: JPG-GR (talk · contribs)

Time filed: 17:41, 14 August 2019 (UTC)

Link(s): [22]

Comments: Log linked above has WikiProject Banners incorrectly transcluded instead of (presumably) linking to them, causing the log page itself to appear in Category:WikiProject banners with formatting errors. - JPG-GR (talk) 17:41, 14 August 2019 (UTC)

Will fix, thanks for report. —  HELLKNOWZ   ▎TALK 18:18, 14 August 2019 (UTC)

Closed RfD still shown a month later

  New bug

Filled by: ComplexRational (talk · contribs)

Time filed: 23:20, 17 September 2019 (UTC)

Link(s):

• [23] (reinstating the RfD that was closed as delete on 20 August, untouched since its initial listing on 22 July)
• [24] (RfD opened 4 September, closed as keep 16 September, removed quickly)
• [25] (RfD opened 8 September, closed as speedy delete 9 September, also removed quickly)

Comments: I don't understand why the bot continues to report an RfD that has been closed for nearly a month (and reinstates after I manually removed it, though I now suspect it is supposed to do that). Other RfDs have come and gone within that time frame, yet this one remains despite its closure. Is this a normal consequence of the nature of the RfD (e.g. its relisting), or is this a new bug? ComplexRational (talk) 23:20, 17 September 2019 (UTC)

"Articles to be merged" entry lingers; perhaps because of section in wikilink?

  Not a bug

Filled by: Czar (talk · contribs)

Time filed: 14:51, 2 November 2019 (UTC)

Link(s): Special:PermanentLink/924018773

Comments: The "Anarcho-tyranny" merge discussion is still marked as open when it has been closed for a while. Perhaps it has something to do with how the merge target includes a specific section title or how the discussion closure template seems non-standard? Wanted to flag for you either way. Thanks! czar 14:51, 2 November 2019 (UTC)

That's because the {{Merge from}} and {{Merge to}} templates on the articles have not been removed when the discussion as closed. —  HELLKNOWZ   ▎TALK 16:10, 2 November 2019 (UTC)

Resolved

 – czar 01:46, 24 November 2019 (UTC)

RFD issue?

  New bug

Filled by: Headbomb (talk · contribs)

Time filed: 04:58, 16 November 2019 (UTC)

Link(s): [26]

Comments: The two RFD links have a #<1> for anchor, rather than #Online_journal_of_biological_sciences for anchor. Headbomb {t · c · p · b} 04:58, 16 November 2019 (UTC)

Edit summary

  New bug

Filled by: Jmar67 (talk · contribs)

Time filed: 10:05, 15 December 2019 (UTC)

Link(s): Wikipedia_talk:Article_alerts#Missing_parens

Comments: The edit summary is missing a closing parenthesis at the end, and the one before the ending "signature" is superfluous. That is, the existing parenthesis is in the wrong place. I reported this earlier on the main talk page. Jmar67 (talk) 10:05, 15 December 2019 (UTC)

Speedy category processes not reported

Original heading was: Banner using redirect is not reported

  New bug

Filled by: Fayenatic london (talk · contribs)

Time filed: 12:33, 9 January 2020 (UTC)

Link(s): Category:Jewish-related television programs nominated 7 Jan, talk page was given the project banner redirect {{WP Judaism}} also on 7 Jan, not yet listed at Wikipedia:WikiProject Judaism/Article alerts as of 9 Jan. Compare Category:Jewish engravers by nationality, talk page was given fully-spelled-out {{WikiProject Judaism}} on 5 Jan, & was listed on Alerts on 6 Jan.

Comments:

The bot does not report speedy processes. The reported entry is a full CfD deletion discussion, the non-reported one is speedy (uncontroversial) renaming. The banner redirects are retrieved each run, so that should not be the issue. —  HELLKNOWZ   ▎TALK 12:49, 9 January 2020 (UTC)

Oh! Thanks; I have changed my heading, which turned out to be misleading. However, the explanation is a surprise. Is there a consensus against reporting speedy processes? C1 and C2 (except C2E) require 7 or 2 days notice respectively, so it would be worth reporting alerts for those processes. – Fayenatic London 14:57, 9 January 2020 (UTC)

At the time of implementing, there were no speedy processes that needed a review. They were--by definition--uncontroversial and normally resolved quickly (hours or even minutes). At the time, it was decided to keep only processes that have a formal timed discussion "phase" or there would be way too many pages to report and process. The only exception was PRODs, which technically don't have a discussion but are still commonly reviewed. Speedies have no discussion; they don't need a call to participate, so there was no need to report them and clog up the page with entries that quickly disappear anyway. At least, in theory, in the past. —  HELLKNOWZ   ▎TALK 15:24, 9 January 2020 (UTC)

@Fayenatic london and Hellknowz: See however this feature request. Headbomb {t · c · p · b} 17:51, 9 January 2020 (UTC)

@Hellknowz: Thanks for the history, but WP:CFDS should be another exception. The page currently [27] has plenty of active discussions on speedy nominations; objections are raised, and sometimes these are lifted in which case the speedy goes ahead, otherwise it doesn't. IMHO it would be useful and welcomed for C1 and C2 nominations to generate alerts. In any case it would only happen in the cases that had been set up well enough or long enough to have project banners on the talk pages. – Fayenatic London 08:19, 11 January 2020 (UTC)

Vandalism in AfD close not skipped, closer misreported

  New bug

Filled by: Hellknowz (talk · contribs)

Time filed: 09:42, 25 January 2020 (UTC)

Link(s): this update (reported Wikipedia_talk:Article_alerts#Misreported_close)

Comments:

RfD with pipe not parsed

  New bug

Filled by: Hellknowz (talk · contribs)

Time filed: 09:59, 22 February 2020 (UTC)

Link(s):

Comments:

#redirect [[Great_Britain#Language|Languages of the British Isles]]

#REDIRECT [[Banana|Banana (disambiguation)]]

"Bot edit" indicator missing, bot floods recent changes

  Not a bug

Filled by: Fram (talk · contribs)

Time filed: 08:20, 1 April 2020 (UTC)

Link(s):

Comments: This bot is making thousands of edits without the bot indicator, flooding recent changes (curiously, a fair number of edits does have the "b" indicating its bot status. Other bots active at the same time don't have this issue. I also notice that this bot erratically indicates its changes as minor or not, without apparent rhyme or reason to it. This as well should probably be consistent, but is less urgent than the "bot edit" indicator. Fram (talk) 08:20, 1 April 2020 (UTC)

This is on purpose, the report page deliveries are not flagged as bot edits so that editors watching the alert pages are notified of their watchlisted alert page changes, even if they have disabled bot edits in watchlist. Minor edits are used for report pages when there aren't any major changes worth reviewing. Non-report page edits are all minor and bot flagged. —  HELLKNOWZ   ▎TALK 09:33, 1 April 2020 (UTC)

So, for a few minutes every day, this bot makes recent changes rather useless (flooding it with hundreds of unflagged edits in a very short time), so that people can see it on their watchlist? Has this been approved as such? As it seems to me that this gets the priorities reversed, and that recent changes is more important than these watchlists (one can enable bot edits on a watchlist, one can't filter out these unflagged bot edits though). Fram (talk) 10:41, 1 April 2020 (UTC)

One can't follow report pages on watchlist without enabling every other bot change either. So whether it's more important is subjective and there hasn't been any formal discussion either way. The bot has run this way during trial, for 10 years since and the previous version ran the same. The shortcoming of bot flag being a binary toggle for recent changes (and by extension watchlists) has never been addressed. I don't know of a way to allow filtering out these bot edits in particular (edit filter? custom tag?). So the stance has been to allow users to watchlist pages to see alerts without forcing them to toggle on bot edits at the expense of a recent change flood. I don't mind holding an actual discussion/RfC about this. —  HELLKNOWZ   ▎TALK 11:18, 1 April 2020 (UTC)

Thanks. We can simply let this here for now: if no one else is bothered by it, then there's no reason to change it. If others would come here and agree that this is an issue for them, then we still can have a discussion somewhere to determine if this should be changed or not. But as it was like this for the past 10 years, it is hardly an urgent matter or something major. Fram (talk) 12:23, 1 April 2020 (UTC)

I don't think this page will attract much comment. This was brought up a few times before asking why no bot flag, and I always explained the same as above. There wasn't much follow-up for those. —  HELLKNOWZ   ▎TALK 13:44, 1 April 2020 (UTC)

This really isn't an issue. Also, those can easily be filtered by 'Experienced users' or 'Namespace' for the 10 minutes they're getting made. That said, minor changes could also be flagged as bot edits since those really don't need review and reduce the number of them that show up in RC. Headbomb {t · c · p · b} 17:27, 1 April 2020 (UTC)

Incorrect AfC report

  Rare unfixable corner-case

Filled by: Chrisspurgeon (talk · contribs)

Time filed: 17:24, 13 June 2020 (UTC)

Link(s): Wikipedia:WikiProject Birds/Article alerts

Comments: On the page for Project Birds at [[28]] Central Park Birding Incident is still listed as an article for creation, but the page has been created and exists at https://en.wikipedia.org/wiki/Central_Park_birdwatching_incident . Maybe the problem is that the draft capitalized Birding and Incident, while in the live article they are lower case? I'm kind of a newbie when it comes to anything but basic editing, and don't know how to fix this. Thanks!

Chrisspurgeon (talk) 17:24, 13 June 2020 (UTC)

Hi! The reports are automatic, so there isn't anything anyone can "fix" unless it's an actual manual human error somewhere. In this case, the bot got confused by original decline, then multiple page moves, then later-added redirect and probably other stuff in-between that it saw or didn't see. I set the page for re-retrieval, which effectively removed it from the list/archive. This isn't the correct closure result, but at least it's not a wrong one. This is one of those things I can't really predict or do anything about for the future, because next time it will be something else and the time it would take to cover every edge case is enormous. For reference, the capitalization shouldn't matter (since there's a redirect and the bot doesn't use the title to match the page, but the redirect/page move). —  HELLKNOWZ   ▎TALK 11:01, 14 June 2020 (UTC)

AfD result moved to draft

  New bug

Filled by: Hellknowz (talk · contribs)

Time filed: 10:23, 28 June 2020 (UTC)

Link(s): [29]

Comments:

The ones that are "The result was moved to Draft:Katie Ascough." Probably need to detect Draft and make sure the result isn't to move the page, which is a different one. —  HELLKNOWZ   ▎TALK 10:23, 28 June 2020 (UTC)

Wrong user attribution

  New bug

Filled by: Eagles247 (talk · contribs)

Time filed: 17:07, 23 August 2020 (UTC)

Link(s): [30] [31]

Comments: Changed Sam Bradford GA nomination by user Lucky7jrk to Eagles247 (I didn't nominate it) in the first diff, and in the second diff attributes a new AFC submission to me again when instead it was nominated by Theviking87. Eagles 24/7 (C) 17:07, 23 August 2020 (UTC)

TfD entry not showing at WP:Baseball's alerts

  New bug

Filled by: NatureBoyMD (talk · contribs)

Time filed: 13:39, 3 October 2020 (UTC)

Link(s):https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2020_September_29&oldid=981012030

Comments: Ten templates were added to TFD in a single entry, but they did not show up on Wikipedia:WikiProject Baseball/Article alerts‎ despite being tagged with {{WikiProject Baseball}}.

Hi! Yes, sorry about the issue. I'm afraid TfD is broken at the moment. See also Wikipedia_talk:Article_alerts#Templates_for_discussion. I'm afraid I haven't had any time to work on this as this appears to be something I can only fix by changing the underlying intricate parsing system. —  HELLKNOWZ   ▎TALK 16:53, 3 October 2020 (UTC)

Not working

Hi, recently I added a shortcut template in WP:LPL/AA. However after adding it, the bot stopped to update the alerts. Then I reverted my edit to make it run but still it is not working. Please make it run. Thank you. Empire AS ^Talk! 08:01, 29 December 2020 (UTC)

Hi. What entry are you expecting to be added/changed/removed in the report? The bot doesn't update pages if there's no changes. It will also simply overwrite your changes if you break the page layout and record this in the logs. There's no errors that I see. No updates after your edit seems to just be a coincidence. —  HELLKNOWZ   ▎TALK 12:40, 29 December 2020 (UTC)

No that's not a coincidence. 5 templates of this project were TfD on 22 December. See Template:Jaffna Stallions roster. But the bot still hasn't updated it. There seems to be an error. Empire AS ^Talk! 12:57, 29 December 2020 (UTC)

Here's Wikipedia:Templates_for_discussion/Log/2020_December_22#Template:Colombo_Kings_roster the link. It's showing there TfD alert. Empire AS ^Talk! 13:01, 29 December 2020 (UTC)

Templates don't work right (see above). So the bot doesn't see those as changes. —  HELLKNOWZ   ▎TALK 13:16, 29 December 2020 (UTC)

Oh that's a problem. However, I do want to ask you that can you fix this problem of bot or it would remain as it is? Thank you. Empire AS ^Talk! 18:59, 29 December 2020 (UTC)

Silvio Meier

Hiya at Wikipedia:WikiProject Squatting/Article alerts the DYK for Silvio Meier is still showing as nominated on 25 November but in actual fact it's already been approved and mainpaged on 11 December. Not a biggie but I thought I'd flag it up since I can't work out why it's happening. Thanks and best wishes for 2021! Mujinga (talk) 22:23, 1 January 2021 (UTC)

It's now no longer present, so RESOLVED Mujinga (talk) 11:06, 4 January 2021 (UTC)

Hi! Sorry for not replying earlier. I was looking at it before but couldn't see anything obviously wrong. It must have been some caching issue somewhere. —  HELLKNOWZ   ▎TALK 11:09, 4 January 2021 (UTC)

Strange! Thanks for the answer, I wasn't sure if an action had been taken or not. Anyway I'm happy it's resolved. Mujinga (talk) 13:40, 4 January 2021 (UTC)

AfC drafts incorrectly listed as undated

  Bug fixed

  New bug

Filled by: The Earwig (talk · contribs)

Time filed: 23:10, 20 January 2021 (UTC)

Link(s): Special:Permalink/1001592825#AFC

Comments: As reported here, many AfC drafts are being marked as undated, but as far as I can tell, they are timestamped and categorized correctly. For example, Draft:Rob Tasker is in Category:AfC submissions by date/23 December 2020 but is listed as undated at Wikipedia:WikiProject Film/Article alerts#AFC. — The Earwig ^talk 23:10, 20 January 2021 (UTC)

The bot doesn't use the category, it uses the actual submission template because it also parses the submitter and decliner and other stuff. It took me a minute to see the difference, but this is because {{AFC submission}} was moved to {{AfC submission}} [32] by Primefac. New drafts now have the "AfD" one so the bot doesn't recognize it. I adjusted the bot to use the renamed template from now on.

There's also seems to be some other bug with what I think is multiple submission templates, which is a bigger issue and I will look into it at some point. Newly submitted AfCs should mostly be ok although regetting old ones with the new template broke a bunch of stuff. —  HELLKNOWZ   ▎TALK 11:36, 21 January 2021 (UTC)