Wikipedia:Bots/Requests for approval/Citation bot 9
- The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was Approved.
Operator: Smith609 (talk · contribs)
Automatic or Manually assisted: Automatic
Programming language(s): PHP
Source code available: [1]
Function overview: Perform null edits to update category membership
Links to relevant discussions (where appropriate):
Edit period(s): Continuous
Estimated number of pages affected: A few per day
Exclusion compliant (Y/N): Yes
Already has a bot flag (Y/N): Yes
Function details:
- The Citation Bbot acts to create the back-end templates that accompany references made using Template:Cite doi and related templates.
- If the accompanying back-end template does not exist, Template:Cite Doi assigns the page to a maintenance category. The bot then uses this category to work out which back-end templates need creating.
- Once the back-end template has been created, the page containing the
{{cite doi}}
call should be removed from the maintenance category - This is an unusual case that does not seem to have been incorporated in the Wikimedia system for keeping categories up-to-date. Wikimedia assumes that categorization will only change when a page is edited: so the page containing the
{{cite doi}}
template won't be removed from the category until it is edited itself. Wikimedia does not associate the creation of the back-end template with the page affected. Therefore, pages can remain listed in the maintenance category for some weeks after they should have been removed. This causes the bot to run on the page many times, with two down-sides:- Waste of toolserver resources
- The queue is clogged with pages that shouldn't be there, so it takes much longer for the bot to reach pages that do need attention, leading to a poorer user experience
- Once this task is approved, the bot will remove the page from the maintenance category by performing a null edit, which (if done correctly) will be invisible to users.
Discussion
[edit]Non-BAG opinion - Is it necessary to submit a bot request for a bot task that only makes null edits? They're not even entered into the page history or are otherwise detectable at all (as far as I know), so it's not like we'd have any way of confirming that your bot is behaving correctly. As long as the frequency of null edits is reasonable and only when needed, my opinion would be that you don't need a BRFA. —SW— spout 03:24, 6 October 2011 (UTC)[reply]
- I had been operating under that assumption, but User:xeno requested that I sought approval. Martin (Smith609 – Talk) 02:22, 7 October 2011 (UTC)[reply]
- I've tested it, and it certainly is the case that categories controlled by #ifexist are not updated when the target page is created. Has anyone filed a bug on this yet? Anomie⚔ 01:14, 11 October 2011 (UTC)[reply]
- I haven't: I didn't know whether it classed as a bug. Martin (Smith609 – Talk) 14:14, 11 October 2011 (UTC)[reply]
- It may not be possible for the Mediawiki software to practically detect categories controlled by #ifexist. That would mean that every time a page is created, MW software would somehow have to know that there is an #ifexist tag on some other page looking for it, and go update the value of it. But there is no database table for #ifexist links, and they certainly don't show up in "What links here" or anything like that. I could easily be wrong, but I think the only reasonable way to notify the software that it needs to update is to perform a null edit on the template. —SW— confess 14:26, 11 October 2011 (UTC)[reply]
- MediaWiki already tracks the connection between the page using #ifexist and the target page, so it can purge the page when the target page is created or deleted. But updating category membership apparently requires a null edit rather than just a purge. Image links and transclusion records seem to have the same problem. Therein lies the bug. Anomie⚔ 16:06, 11 October 2011 (UTC)[reply]
- Are you saying that for every page, MW keeps a list of all other pages that have an #ifexist call to it? I'm not aware of a database table for that purpose, but again I could be wrong. Without such a database table, MW wouldn't know which pages to purge when a new article is created. For example, if on Template:XYZ I add the following code: {{#ifexist:Foobar123|[[Category:Exists]]|[[Category:Doesn't exist]]}}, then when I save Template:XYZ, it processes the #ifexist and puts the template in the right category. However, if some time later I go and create or delete Foobar123, there is no way for the MW software to know that Template:XYZ has an #ifexist call to Foobar123 (since no database table tracks these connections). Therefore, there is no way for the MW software to know that it needs to recalculate the #ifexist on Template:XYZ. —SW— communicate 18:15, 11 October 2011 (UTC)[reply]
- It uses the pagelinks table. You can see this if you check Special:WhatLinksHere for the target page, or query the API's
prop=links
on the #ifexist-using page. Anomie⚔ 19:06, 11 October 2011 (UTC)[reply]- Ahh, you're right. I never knew that. In that case, it does seem like a bug. —SW— soliloquize 19:11, 11 October 2011 (UTC)[reply]
- It uses the pagelinks table. You can see this if you check Special:WhatLinksHere for the target page, or query the API's
- Are you saying that for every page, MW keeps a list of all other pages that have an #ifexist call to it? I'm not aware of a database table for that purpose, but again I could be wrong. Without such a database table, MW wouldn't know which pages to purge when a new article is created. For example, if on Template:XYZ I add the following code: {{#ifexist:Foobar123|[[Category:Exists]]|[[Category:Doesn't exist]]}}, then when I save Template:XYZ, it processes the #ifexist and puts the template in the right category. However, if some time later I go and create or delete Foobar123, there is no way for the MW software to know that Template:XYZ has an #ifexist call to Foobar123 (since no database table tracks these connections). Therefore, there is no way for the MW software to know that it needs to recalculate the #ifexist on Template:XYZ. —SW— communicate 18:15, 11 October 2011 (UTC)[reply]
- MediaWiki already tracks the connection between the page using #ifexist and the target page, so it can purge the page when the target page is created or deleted. But updating category membership apparently requires a null edit rather than just a purge. Image links and transclusion records seem to have the same problem. Therein lies the bug. Anomie⚔ 16:06, 11 October 2011 (UTC)[reply]
- It may not be possible for the Mediawiki software to practically detect categories controlled by #ifexist. That would mean that every time a page is created, MW software would somehow have to know that there is an #ifexist tag on some other page looking for it, and go update the value of it. But there is no database table for #ifexist links, and they certainly don't show up in "What links here" or anything like that. I could easily be wrong, but I think the only reasonable way to notify the software that it needs to update is to perform a null edit on the template. —SW— confess 14:26, 11 October 2011 (UTC)[reply]
- I haven't: I didn't know whether it classed as a bug. Martin (Smith609 – Talk) 14:14, 11 October 2011 (UTC)[reply]
- I've tested it, and it certainly is the case that categories controlled by #ifexist are not updated when the target page is created. Has anyone filed a bug on this yet? Anomie⚔ 01:14, 11 October 2011 (UTC)[reply]
- Approved. Can't really think of a reason to deny this. It's not a very high workload, so it's hardly something that would make the servers melt. I trust Martin to keep an eye on the first few runs to ensure the bot didn't do silly things like removing all whitespace from an article and make sure the edits are actually null. Headbomb {talk / contribs / physics / books} 20:11, 11 October 2011 (UTC)[reply]
- The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.