Wikipedia:Bots/Requests for approval/Mutleybot
- 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 Withdrawn by operator.
Operator: Mutley1989 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)
Time filed: 13:09, Saturday March 2, 2013 (UTC)
Automatic, Supervised, or Manual: Supervised,
Programming language(s): Python
Source code available: Here + pywikipediabot
Function overview: Add reciprocal merge templates.
Links to relevant discussions (where appropriate): Wikipedia:Bot requests, Template talk:Merge#merge discussions
Edit period(s): One time
Estimated number of pages affected: 5000
Exclusion compliant (Yes/No): Yes.
Already has a bot flag (Yes/No): No.
Function details: For all pages in Category:All articles to be merged, searches for a {{Merge}}
and checks the page(s) that points to. If there isn't a {{Merge}}
there, adds one. Ignores pages not in main namespace, as some talk pages have a reciprocal template on the target article, and some on the talk page. There are only 45, so they can be done manually if needed. It also adds the discuss and date paramaters. Just to confirm, the latter should be the date when the first merge template was added, and not the current date?
Discussion
edit- Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. seems reasonable. ·Add§hore· Talk To Me! 15:53, 3 March 2013 (UTC)[reply]
- Trial complete.
- Issues and bug fixes:
- Added "mergeto" and "mergefrom" (i.e. without the space) to the template names it recognises, and made sure it raises an error if it doesn't recognise it.
- Writes those, redirects and protected pages to log files and skips them.
- I think this should now run fine without causing issues on wikipedia. — Preceding unsigned comment added by Mutley1989 (talk • contribs) 12:06, 4 March 2013
- I would request that the edit summary say something to the effect of "If there is no consensus to merge, remove the merge tag from both articles". My thinking is that this will help quickly cleanup the backlog at Category:Articles to be merged with people removing old and forgotten merge tags. --NickPenguin(contribs) 15:43, 4 March 2013 (UTC)[reply]
- I'm running a test with Merge bot to check for any issues and will report back in about an hour with results. – Wbm1058 (talk) 16:43, 4 March 2013 (UTC)[reply]
- Looks good. Will help the bot I'm working on, which wasn't picking up some of these without the reciprocal templates. The current version of my bot is also picking up the ~40 tags misplaced on talk pages and I've begun cleaning them up. Right, the date parameter is when the template was added (or should have been added). I note that most of the 50 test updates didn't add the discuss parameter, I assume because no discussion was found on either talk page. What is the logic for searching for discussions? If the discuss parameter is added to a page, can you include the link in the edit history so that someone browsing the bot's edit history can easily pick out the ones with discussions? For example, this diff. One issue: the bot's talk link is to #Merger proposal, but on the linked page the discussion is titled #Discussion for Merger. – Wbm1058 (talk) 19:14, 4 March 2013 (UTC)[reply]
- The discuss and date parameters are simply copied from the merge template that it follows to get there. The lack of this parameter doesn't indicate that there isn't a discussion about it, just that the discuss parameter was never added to the original merge template. Mutley1989 (talk) 19:58, 4 March 2013 (UTC)[reply]
- Oh, I see. The original tag had the wrong section title. You're good. possible enhancement (maybe for my bot): flag mislinked discussions Wbm1058 (talk) 20:38, 4 March 2013 (UTC)[reply]
- The discuss and date parameters are simply copied from the merge template that it follows to get there. The lack of this parameter doesn't indicate that there isn't a discussion about it, just that the discuss parameter was never added to the original merge template. Mutley1989 (talk) 19:58, 4 March 2013 (UTC)[reply]
- Looks good. Will help the bot I'm working on, which wasn't picking up some of these without the reciprocal templates. The current version of my bot is also picking up the ~40 tags misplaced on talk pages and I've begun cleaning them up. Right, the date parameter is when the template was added (or should have been added). I note that most of the 50 test updates didn't add the discuss parameter, I assume because no discussion was found on either talk page. What is the logic for searching for discussions? If the discuss parameter is added to a page, can you include the link in the edit history so that someone browsing the bot's edit history can easily pick out the ones with discussions? For example, this diff. One issue: the bot's talk link is to #Merger proposal, but on the linked page the discussion is titled #Discussion for Merger. – Wbm1058 (talk) 19:14, 4 March 2013 (UTC)[reply]
- I think this should now run fine without causing issues on wikipedia. — Preceding unsigned comment added by Mutley1989 (talk • contribs) 12:06, 4 March 2013
- Not that it's going to generate a crisis situation, but in several cases, I can tell this bot will generate many merge tags on a single article. In an extreme example, every single character is proposed to be merged into List of Kinnikuman characters. Can this bot correctly handle multiple mergers to the same article? Also, there are some rare cases where the merge subject has already been redirected. It would be good if the bot could remove the tag in those cases. --NickPenguin(contribs) 19:28, 4 March 2013 (UTC)[reply]
- When an article has a merge template that points to multiple articles, it will add one to each of those articles, like you can see here if you follow the links in that template. In the case of multiple articles having a merge tag that point to the same article, it will never edit a page if any merge tag already exists on that page, I could change it if necessary to add to the current template, i'm not sure how much that complicates it. With regard to redirects, it currently writes the page names to a log file, then ignores it, with the intention of looking at them manually. Can I assume that any merge template that points to a redirect page should be removed? Mutley1989 (talk) 19:58, 4 March 2013 (UTC)[reply]
- So it will also add another article to an existing merge tag, even if it currently only points to one article? Also, I think it would be the case that if the merge template points to a redirect, it should be removed. --NickPenguin(contribs) 20:12, 4 March 2013 (UTC)[reply]
- Currently, it will not touch existing merge tags. Should I make it do that when more than one tag points to the same article, rather than leaving it as is? Mutley1989 (talk) 20:24, 4 March 2013 (UTC)[reply]
- My concerns might not be overly important. I'm just thinking about a scenario like this, with articles A, B C and D. Article A is the merge target for B, C and D, but has no merge tags on it. The bot scans article B, and adds a merge tag to article A. Then it scans article C, and adds a merge tag to article A. Then it scans article D and adds a merge tag to article A. Article A now has 3 new merge tags on it. This kind of scenario also applies to an article with one existing merge tag. I think in these cases the end result should be one merge tag, with each article seperated using the | character. However I don't know if this will cause conflicts on articles with more than one merge tag. --NickPenguin(contribs) 20:38, 4 March 2013 (UTC)[reply]
- As it is currently, my script would leave A with one merge tag, from whichever of B, C or D is encountered first. I will look into modifying it to do what you say. Mutley1989 (talk) 20:54, 4 March 2013 (UTC)[reply]
- After thinking about it for a while, I think the simplest solution would be to simply add another merge tag, rather than try to modify an existing tag. In some cases, the merge proposals will have different dates, so putting them in one tag wouldn't be advised. Also, there will be relatively few of the extreme cases, and these can be dealt with manually after the fact. --NickPenguin(contribs) 15:52, 6 March 2013 (UTC)[reply]
- As it is currently, my script would leave A with one merge tag, from whichever of B, C or D is encountered first. I will look into modifying it to do what you say. Mutley1989 (talk) 20:54, 4 March 2013 (UTC)[reply]
- My concerns might not be overly important. I'm just thinking about a scenario like this, with articles A, B C and D. Article A is the merge target for B, C and D, but has no merge tags on it. The bot scans article B, and adds a merge tag to article A. Then it scans article C, and adds a merge tag to article A. Then it scans article D and adds a merge tag to article A. Article A now has 3 new merge tags on it. This kind of scenario also applies to an article with one existing merge tag. I think in these cases the end result should be one merge tag, with each article seperated using the | character. However I don't know if this will cause conflicts on articles with more than one merge tag. --NickPenguin(contribs) 20:38, 4 March 2013 (UTC)[reply]
- Currently, it will not touch existing merge tags. Should I make it do that when more than one tag points to the same article, rather than leaving it as is? Mutley1989 (talk) 20:24, 4 March 2013 (UTC)[reply]
- So it will also add another article to an existing merge tag, even if it currently only points to one article? Also, I think it would be the case that if the merge template points to a redirect, it should be removed. --NickPenguin(contribs) 20:12, 4 March 2013 (UTC)[reply]
- When an article has a merge template that points to multiple articles, it will add one to each of those articles, like you can see here if you follow the links in that template. In the case of multiple articles having a merge tag that point to the same article, it will never edit a page if any merge tag already exists on that page, I could change it if necessary to add to the current template, i'm not sure how much that complicates it. With regard to redirects, it currently writes the page names to a log file, then ignores it, with the intention of looking at them manually. Can I assume that any merge template that points to a redirect page should be removed? Mutley1989 (talk) 19:58, 4 March 2013 (UTC)[reply]
- Not that it's going to generate a crisis situation, but in several cases, I can tell this bot will generate many merge tags on a single article. In an extreme example, every single character is proposed to be merged into List of Kinnikuman characters. Can this bot correctly handle multiple mergers to the same article? Also, there are some rare cases where the merge subject has already been redirected. It would be good if the bot could remove the tag in those cases. --NickPenguin(contribs) 19:28, 4 March 2013 (UTC)[reply]
- Murphy's law in action – someone actually suggested that an article be merged into itself. Probably an easy fix to test for this and remove the item from the template like this (maybe you're already doing that?). Thanks, Wbm1058 (talk) 17:14, 5 March 2013 (UTC)[reply]
Are all of the fixes and place and ready for another trial?—cyberpower ChatOffline 14:48, 29 March 2013 (UTC)[reply]
- Sorry, I've been busy with other things and haven't got round to doing this. I'm on with it now. Mutley1989 (talk) 19:05, 1 April 2013 (UTC)[reply]
- Ignore my last comment, I doubt I will ever get this done, sorry for wasting anyone's time. Mutley1989 (talk) 05:09, 11 April 2013 (UTC)[reply]
- It's not a waste of time, don't worry about it. Feel free to unarchive if you ever change your mind. MBisanz talk 11:23, 11 April 2013 (UTC)[reply]
- Ignore my last comment, I doubt I will ever get this done, sorry for wasting anyone's time. Mutley1989 (talk) 05:09, 11 April 2013 (UTC)[reply]
- Withdrawn by operator. MBisanz talk 11:23, 11 April 2013 (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.