This is an archive of past discussions with User:RMCD bot. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Has been created and deleted ten times by this bot and its "relatives". Now salted, but thought you should know anyway.Beeblebrox (talk) 00:23, 30 August 2012 (UTC)
This ought to have come up a number of times. There seems to be a bug whereby newlines in the rationale are just stripped out, causing sentences to be run together. This affected my recent nomination of Susanne Courtney. If it's going to run it into one paragraph, it should at least put a space where the newline was. — Smjg (talk) 21:51, 20 September 2012 (UTC)
As the page edit notice says, Your edits will be overwritten.—the bot runs every 15 minutes. Looks like you found a work-around by appending spaces to the end of the first paragraph. I believe that it's a design feature that Wikipedia:Requested moves/Current discussions consolidates the "reason why" text into a single paragraph, reserving the use of white space for separating requests. But you're right that there should still be a space after the period. Now I have two items on my bot-fix to-do list. Thanks, Wbm1058 (talk) 10:58, 21 September 2012 (UTC)
Done Two spaces now replace each newline character in reason messages, effective with this bot edit. Once I got to looking for this in the bot's program, it wasn't that hard to find and fix. So, sorry for the long delay in getting to this. About time I worked off the back end of the to-do list Wbm1058 (talk) 16:19, 26 September 2014 (UTC)
Yes, odd indeed. Something hiccuped, it seems. The alt version was wiped too, but then restored with the next update. First time I've seen this happen. Wbm1058 (talk) 01:03, 27 November 2012 (UTC)
Fixed I installed a new version that loops up to 5 times until transclusions successfully retrieved. Normally they're retrieved first time, every time. But if there's a temporary problem (e.g., the function to retrieve transclusions times out?) then RMCD bot will abandon the update, wait 15 minutes, and then try again. Wbm1058 (talk) 14:29, 22 February 2013 (UTC)
This issue was misdiagnosed, sorry. Per template:Move-multi/doc, there was a problem with user attempts to specify the now-deprecated parameter current1, because of a MediaWiki bug, in the above reported multi-move request involving AT&T. Someone decided that ampersands needed to be escaped as & – perhaps that escape syntax is something the bot can't handle, but there is no problem processing straight-up "&" characters that I see, per my tests: this test request produced this bot-page line-item. Looks OK to me. – Wbm1058 (talk) 22:14, 15 October 2014 (UTC)
Bot issue?
Hi, Not sure if this is a bot issue or If I'm simply missing something here -
On both the B & M and A & M talkpages the bot's saying "There is a move discussion in progress on Talk:C&A which affects this page. Please participate on that page and not in this talk page section. Thank you" but A. There is no discussion on any of the 3 tps, and B. All 3 pages aren't related to each other?
Thanks. Regards, –Davey2010 • (talk)23:02, 15 October 2014 (UTC)
Oops, I was just testing something. I'll revert those edits; I should have realized I'd need to do that. Thanks. Wbm1058 (talk) 23:32, 15 October 2014 (UTC)
O, I forgot to write the major problem. I don't know why the page did not appear in the WP:requested moves page, or it was there but removed unsolved after 7 days? How to relist it if it is operated by a bot? Matthew_hktc19:15, 22 December 2012 (UTC)
* ''([[Talk:Talk That Talk#Requested move |Discuss]])'' – '''[[: That]] → {{no redirect|Talk That Talk (Rihanna album)}}''' – Yes, I know this is more popular than the jazz album, but that album was released first. [[User:Billboard Man|Billboard Man]] ([[User talk:Billboard Man|talk]]) 22:49, 7 June 2013 (UTC)
Yikes, it looks like any title that begins with "Talk" may have this problem. The code is pattern-matching "talk" as in "Talk:" namespace and is neglecting the possibility that a title could begin with that string, is my initial diagnosis. Another item for my growing to-do bug-fix list, thanks. Wbm1058 (talk) 13:27, 8 June 2013 (UTC)
This is normally easily fixed by adding a missing character.[1] but right now the BOT appears to have stopped - and has made no edits since 00:00, 20 November 2012. Apteva (talk) 23:02, 20 November 2012 (UTC)
Bug report (round bracket trouble)
At Talk:R. G. Ritson#Move? is a move request "{{Requested move/dated|Ralph Gerald Ritson}}
[[R. G. Ritson]] → {{no redirect|Ralph Gerald Ritson}} – per bulk of references [[User:Richard Arthur Norton (1958- )]] 19:22, 19 November 2012 (UTC)" which duly ends in a signature ending in a time and date duly ending in '(UTC)'. But RMCD bot keeps putting it in 'Time could not be ascertained' :: has RMCD bot been confused by the round-bracketed substring inside the user's name? Anthony Appleyard (talk) 09:11, 21 November 2012 (UTC)
In this diff, you can see the bot assigning times to two previously untimestamped posts. However, the bot also posted the first vote for each move proposal, and used that timestamp instead. Is this something the bot will resolve itself, or require manual intervention (by someone familiar with the bot)? Dralwik|Have a Chat02:52, 17 May 2014 (UTC)
Fixed – The problem started with these controversial requests being submitted as technical requests. This way they bypass {{subst:Move}} which ensures the proper formatting for the bot. Because the signatures were manually cut-pasted from diffs, they include 3 invisible characters in the dates. The fix is easy if you know what to do... just retype the dates and Show changes should confirm the fix if you see the change there – it just won't look like anything changed. Some day maybe we will have a better way to convert technical requests. Wbm1058 (talk) 05:27, 17 May 2014 (UTC)
At this point, I'm going to archive these, as I believe the issues causing the problem reports have been mostly addressed. Start a new report if there are still issues in this area. Wbm1058 (talk) 19:15, 13 December 2014 (UTC)
RMCD bot alert
Hey Wbm1058. First let me just tell you, belatedly, thanks for taking over the bot! Doing what it does by hand was a real pain in the ass. Anyway, this is a minor error, maybe nothing needs to be done—especially if a fix would require a lot of coding—but I thought I'd just alert you to a bot issue so you'd know about it.
I closed the move discussion at Talk:Zanzibar House of Representatives. I'm not quite sure why but the bot listed the page both under September 11, and under "time could not be ascertained" (seeing this, I had supposed there must have been first a malformed request and then a change to it, so it listed and then listed again, but I couldn't find any such malformed initial request in the page history). In any event somewhere along the line, the bot listed it twice and didn't remove the first listing when it listed it again. Furthermore, after I closed the discussion, the bot removed the listing at WP:RM from September 11, but left it listed under "time could not be ascertained". I manually removed it. I tracked down the first listing to this diff but I'm not sure when it listed it the second time. Best regards--Fuhghettaboutit (talk) 23:00, 18 September 2013 (UTC)
Thanks Fuhghettaboutit. This is a glitch I'm aware of, but have put a low priority on fixing, because it's a transitory problem that fixes itself. The bot's update (22:31) was coincidentally processing at the same time as you closed the RM (22:30). As I mentioned in Wikipedia:Requested moves/Closing instructions#Bot considerations, A request will be listed in a special section titled "Time could not be ascertained" on Wikipedia:Requested moves if the listing bot cannot ascertain the date on which the request was made. This may be because:
The move request was closed while a bot update was in progress. This should resolve itself with the next bot update.
The bot runs on the quarter-hour, so if you had closed the RM a minute or two later the bug would have been avoided. Maybe I should put a higher priority on fixing that. I'll get to it eventually. Wbm1058 (talk) 03:35, 19 September 2013 (UTC)
If it would have been taken care of by the bot if I had just waited then it's rather innocuous, so, yeah, put it at the low end of the triage pile:-)--Fuhghettaboutit (talk) 22:01, 19 September 2013 (UTC)
No, I don't see anything you did wrong. You just happened to move the article and close the RM while a bot update was in progress. Actually it appears the sequence was:
Bot update started
You moved the article
Bot update completed (the bad bot edit)
You closed the RM on the talk page (steps 1–4 completed within 2 or 3 minutes)
The next bot edit fixed it (15 minutes later)
Unfortunately the bot doesn't handle this situation as gracefully as it could. The problem corrected itself 15 mins. later, with the next bot update. I'm not sure on the timing as my computer's clock may vary from Wikipedia's by a minute or so sometimes. Sometime I'll look closer at this and see if I can't make it work more robustly. Thanks for the report. Wbm1058 (talk) 20:32, 23 April 2014 (UTC)
I'm not sure whether you noticed, but this happened once yesterday, too. I figured the problem was not on the bot's side, but thought the extra example might help now in case you are working on something. Dekimasuよ!18:21, 12 December 2014 (UTC)
Yes, indeed I am working on improving the bot's robustness. I have identified a place where error checking wasn't being done, and am in the process of making it report malformed requests. Thanks for pointing that out, I hadn't noticed that glitch. That's another issue where I have an idea of what the problem is and how to address it, so I'll make a code enhancement there too. Wbm1058 (talk) 18:39, 12 December 2014 (UTC)
For the malformed requests language, "Did you submit your request by using subst:requested move?" can be read to imply either that the request is malformed because the request has not been submitted using subst:requested move, or that the error was caused by using subst:requested move. Can we try a different wording, e.g. "Did you remember to submit your request by..." or something like that? Dekimasuよ!21:13, 12 December 2014 (UTC)
A proposed move that uses ref tags is confusing the RMCD bot
See this issue about red error messages at the bottom of WP:RM. When I view WP:Requested moves/Current discussions and click the the 'Discuss' link for this move (search for 'Anna Pou' to find the move entry) it gives a link to the talk page but no section. Normally there is a section link. This leads me to think that the refs are confusing the RMCD bot. Thanks, EdJohnston (talk) 20:02, 26 February 2014 (UTC)
Two issues here. The logic for linking to sections is not as robust as it could be, and my limited experience with regular expressions (regex) has kept that a longer-term issue. One of these days I hope to find a solution. The other issue regarding the missing reflist I think I can solve. This is the first time that I've seen Template:Reflist-talk, that's nice to have an alternative for talk pages. I'll see what I can do. Wbm1058 (talk) 20:09, 26 February 2014 (UTC)
One of the proposals in the Help desk discussion was to change WP:RM to bracket the transclusion of Current discussions like so: <noinclude> {{/Current discussions}} </noinclude> . See a comment by User:Fuhghettaboutit. When I tried this in the edit buffer, it did get rid of the red error messages in the full RM listing. I didn't save my change since I don't want to break the world. What do you think? EdJohnston (talk) 03:28, 27 February 2014 (UTC)
I think Fuhghettaboutit did get a workable solution implemented, where the noinclude tags sandwiched the references only, on the talk page for the specific Katrina/hospital deaths incident. My head can sometimes get spinning with all the transclusions, but I think if you put noincludes on the RM page itself you would effectively block transclusion of the whole subpage – Wbm1058 (talk) 04:07, 27 February 2014 (UTC)
Fixed
Bot version 4.08 (9 May 2014) added a references section
This version of Talk:Memorial Medical Center and Hurricane Katrina (the 'Anna Pou' entry) had an extra line with a space in it between the section header and the {{Requested move/dated}} template, which prevented the bot's pattern-matching (regex) from finding the section header. Bot version 4.15 (13 December 2014) now reports entries as "malformed requests" when it cannot locate the section header. No text can be entered between the section header and the {{Requested move/dated}} template. Now, perhaps more sophisticated pattern-matching could allow that, but I need to become more proficient with regular expressions to implement that. So, for now, reporting the issue for correction will have to suffice.
Sorry about that. A quick look at my console output shows that the regex matching isn't working, I see It's NULL!! in the output. You can see where the code echos that here. If any regex experts can help me with a suggested fix, that would be appreciated. Otherwise, I'll try to look at this more closely and figure it out, hopefully before this RM closes. Wbm1058 (talk) 14:04, 7 February 2014 (UTC)
No action What I see at Talk:Marek Židlický is an earlier move transcluding {{movereq old|Marek Zidlicky}} which is what I suspect caused the diacritics "mask" problem. There are several issues with transcluding that template, and I believe that substituting it will resolve this. Likewise, at Talk:Callosa d'en Sarrià I see an earlier requested move which is muddying the diagnosis. I ran a test here to see if there were any issues with processing the character à, and the bot handled it fine. So I'm going to assume that there are no problems specifically related to handling certain Unicode or diacritics, but rather these are symptoms of multiple RMs on a single page. Wbm1058 (talk) 05:53, 15 February 2015 (UTC)
Hi. Despite being removed twice, the bot keeps adding an unnecessary and potentially confusing message to Talk:Plymouth: [2][3][4]. I've moved the latest copy out of the way above the current discussion for now, but this sounds like a bug that needs fixing. Shouldn't the message have been posted to Talk:Plymouth (disambiguation)? - another user has copied it there now: [5]. —SMALLJIM17:32, 24 February 2014 (UTC)
Well duh. Look closely at the request that was made:
So unsurprisingly the bot was confused. Perhaps it could be made intelligent enough to report the editor error. But sorry, I'm putting that toward the back of my priority list.
Hmm. Simple sanity check, I'd have thought: don't put a message on the same page as the one that's listed in the message. Anyway, should it really keep adding it once it's been removed? That's a job for AV patrollers etc. —SMALLJIM20:18, 24 February 2014 (UTC)
Problem that the bot/template combination has created
There is a requested move at Talk:Severodonetsk#Requested move 4 February 2015. This was created with the template in the usual way. The problem is that the template assumes that the talk page and the article page have the same name; they do not.
I was able to correct this on the move request on the article talk page, so that it shows the move request to be Sievierodonetsk → Severodonetsk.
The limit was last raised from 150 to 200. I just bumped it to 300, for the update which will run in a couple of minutes... Wbm1058 (talk) 16:42, 22 April 2015 (UTC)
Hmm. This bot's last successful update was at 06:18, 12 June 2015. Per Wikipedia:Village pump (technical)/Archive 137 § Forced HTTPS, "At some point between 07:38 and 10:00, 12 June 2015 (UTC), the user preference "Always use a secure connection when logged in" lost its effect, and regardless of its setting, Wikipedia became HTTPS only." The bot was still able to login under http, but couldn't do anything after that. I changed the http to https, and it doesn't even successfully login. Go figure. Total breakdown of communication. I don't know how to fix this, and am feeling rather angry at the WMF right now. Going to pack it in for the night and watch a movie. Wbm1058 (talk) 21:03, 13 June 2015 (UTC)
You are receiving this message because a technical change may affect a bot, gadget, or user script you have been using. The breaking change involves API calls. This change has been planned for two years. The WMF will start making this change on 30 June 2015. A partial list of affected bots can be seen here: https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/081931.html This includes all bots that are using pywikibot compat. Some of these bots have already been fixed. However, if you write user scripts or operate a bot that uses the API, then you should check your code, to make sure that it will not break.
What, exactly, is breaking? The "default continuation mode" for action=query requests to api.php will be changing to be easier for new coders to use correctly. To find out whether your script or bot may be affected, then search the source code (including any frameworks or libraries) for the string "query-continue". If that is not present, then the script or bot is not affected. In a few cases, the code will be present but not used. In that case, the script or bot will continue working.
This change will be part of 1.26wmf12. It will be deployed to test wikis (including mediawiki.org) on 30 June, to non-Wikipedias (such as Wiktionary) on 1 July, and to all Wikipedias on 2 July 2015.
Are you using someone else's gadgets or user scripts? Most scripts are not affected. To find out if a script you use needs to be updated, then post a note at the discussion page for the gadget or the talk page of the user who originally made the script. Whatamidoing (WMF) (talk) 19:04, 17 June 2015 (UTC)
Moves to overwrite an existing non-redirect page, and automated notices
I've noticed several cases where a move is suggested to overwrite an existing non-redirect page (such as currently found at Talk:Mavia (queen)). Shouldn't the bot inform the talk page of the non-redirect target that is being suggested to be overwritten? (in this case Talk:Mavia) -- 65.92.180.137 (talk) 05:43, 31 March 2013 (UTC)
The issue with Pan-African University was a result of an editor error, which I corrected. This is one of several issues for which I expect to work on better bot solutions eventually. Wbm1058 (talk) 15:50, 31 May 2013 (UTC)
Done by bot version 5.20 — re: destinations that are redirects... see the next section. I'll look into it. wbm1058 (talk) 12:49, 23 June 2016 (UTC)
Moves to overwrite a redirect that points elsewhere, and automated notices
Per the recent Talk:Gabz (singer) filing, can the bot post a notice to a redirect's target's talk page? (in this case, Gabz, the target of the move request, redirects to Gaborone, so the bot could post a notice to talk:Gaborone, indicating that a redirect to the article is under discussion) -- 65.94.79.6 (talk) 23:13, 21 June 2013 (UTC)
Not sure on this one. Will need to follow each redirect and somehow analyze the content at the destination of the redirect. Needs more study. In the meantime, a note like the one you placed at Talk:Gaborone § "Gabz" should cover it. – wbm1058 (talk) 11:02, 23 June 2016 (UTC)
Request for an idea to improve this bot's functionality
@Wbm1058: While seeing an issue that resulted in me moving a discussion from WP:RFD to WP:RM (the discussion was to retarget the ambiguous term to the disambiguation page), I thought of something that honestly may have been considered before, but would probably be rather helpful; is it possible for RMCD bot to put the automated message that is usually place on pages' talk pages that are part of a multimove request ... onto the requested move targets as well? I'm wondering if this is possible since in my example (moving a discussion from Turner to Turner (disambiguation)), it would be helpful for those who are watching Turner to know about the move discussion on Talk:Turner (disambiguation), especially since the state of Turner will change if the move occurs. Steel1943 (talk) 21:28, 8 October 2014 (UTC)
This person prefers a signature after original signature, not before. It confuses him. I bet the RFC thing doesn't bode well with him either. --George Ho (talk) 00:42, 17 July 2015 (UTC)
I see, you're referring to Talk:Eastern Railway (Western Australia). If he's confused by that, he will really be confused by the regular expression needed to figure out which signature and time stamp to use for the date of the listing. When I first took over the bot in August 2012, I made this change to address an issue. Looks like the bot was just always picking up the first date it found in the rationale. That would explain the convention of putting the most recent relist date first. I patched it so that when there was no relisting it used the last date in the rationale. The code would actually be simpler if we just always used the timestamp at the end of the string – and put relists there. I suppose we just need to give a heads-up to the editors who relist, so they switch to the new convention. Wbm1058 (talk) 03:10, 17 July 2015 (UTC)
Attitude check needed
To find and insert an editors signature inside the signature of blocked sock is outright stupidity.
Also you need to re-read where you have an editor says another editor is a blocked sock, and you actually ping that blocked sock. JarrahTree13:30, 17 July 2015 (UTC)
See this edit where I needed to insert a linefeed before a </small> tag so that the bot would pick up the signature at end of the line. I should fix it to work with this tag, as relists are often put in small text. Wbm1058 (talk) 14:22, 17 July 2015 (UTC)
Per WP:RM: "To relist a move request discussion, simply type <small>'''Relisted'''. ~~~~</small>before the initial requester's first timestamp (see this diff for an example). This can also be done by using {{subst:Relisting}}, which signs the relisting automatically. The RMCD bot uses the new timestamp to relist the entry on this page." (italics added for emphasis). Your recent changes on a few Talk pages are contrary to this advice. —BarrelProof (talk) 17:19, 31 July 2015 (UTC)
Oh, I found some Talk page discussion about that from your edit history. I see that the convention is under discussion, and won't revert those changes. But eventually we need to make sure the instructions are aligned with the way the bot operates (and with what we're doing in practice). —BarrelProof (talk) 17:27, 31 July 2015 (UTC)
Finally, merely invoking a guideline like USPLACE does not refute an IAR argument to ignore that guideline, especially one based on such very good reasons. --Born2cycle (talk) 22:06, 23 September 2012 (UTC)
Here is the diff showing the issue. Hmm, most links do work, but maybe the problem is with handling piped links like [[WP:PRIMARYTOPIC|primary]]. – Wbm1058 (talk) 18:08, 26 September 2014 (UTC)
OK, I've got the bot screening for and removing the html tags for <p> (paragraph), <ol> (ordered list), <ul> (unordered list) and <li> (list). In the spirit of keeping the reason summaries on the bot's page down to single paragraphs (i.e., reasonably short) I don't think we should let editors bypass that spirit by using html paragraph and list tags. Unless a consensus forms that says otherwise.
But it turns out that still wasn't the issue that caused me to put this on my list. I finally identified the problem: use of the "arrow character", i.e., San Francisco, California → San Francisco. That arrow is a special character the bot's pattern-matching looks for. A work-around is to change it to the old-fashioned ASCII keyboard way of doing arrows: San Francisco, California -> San Francisco. I'm tempted to tag this as a {{Won't fix}} since it's a self-reported problem, but ignoring the issue doesn't feel right; it's not the professional thing to do. – Wbm1058 (talk) 00:37, 27 September 2014 (UTC)
Words missing from description in current discussions
Fixed – An easy fix once you know what you're doing. I was trying to find a regex solution, when adding a fourth argument to preg_replace was the simple way to limit to just replacing the first match. wbm1058 (talk) 23:18, 21 October 2016 (UTC)
Thanks for the notice, Jenks24. There indeed was a problem. The bot re-started its updates with this edit. Total downtime 41⁄2 hours. I was "out of the office" for a while this morning, and still a bit groggy when I fixed it. The problem was caused by this new request. The bot has trouble reading through all that and finding the requestor's signature at the end. There is no en dash before the start of the rationale, so that tells me they used {{requested move/dated}} directly, as {{requested move}} always puts the en dash in the expected place. Unfortunately the bot did not flag that as a malformed request, rather it simply aborted all processing after it hit that. This edit fixed it, and also kept that lengthy rationale from being copied in its entirely to the RM page. I'll copy this section to the bot's talk page to get it on my to-do list for fixing exploits that could stop the bot's updates. Wbm1058 (talk) 23:53, 15 July 2015 (UTC)
Thanks for the detailed response! By the way, I couldn't help but notice someone a few sections above suggesting RfA. I think you'd make a great admin, you'll have a support from me when you run Jenks24 (talk) 05:19, 16 July 2015 (UTC)
Fixed – it appears that the bot program crash was caused by a bug in PHP. After I upgraded to the latest version of PHP (7.0.12) the program didn't crash in a call to the preg_replace function. Version 6.14 of RMCD bot now reports requests like this as malformed, after the parsed description is found to be blank (the description is what follows the en dash, so if there is no en dash then there is no description of (rationale for) the request. – wbm1058 (talk) 12:46, 26 October 2016 (UTC)
Thanks for the report. It's choking on Talk:Maryada Purushottam Siya Ke Ram. I'll take a look to see why, and see if I can fix the code to close that "backdoor means of blocking the bot".
Note the line in User:RMCD bot/requestedmoves.php: die("Error 2");. That's what I saw on the console: Error 2. That bot starts by getting an array of all the pages that transclude {{Requested move/dated}}. Then it cycles through them and reads the contents of the page. It died on that page because the read-contents attempt failed. Normally I would assume that this was because my Internet connection was down, or something like that. Wouldn't expect a page to still be transcluding a template six hours after it was blanked. This seems like new behavior of the MediaWiki system. Wbm1058 (talk) 14:00, 18 November 2015 (UTC)
Jenks24, it seems that there was some sort of "solar storm" on November 18 that made some new transclusions invisible to "what transcludes this template" requests. See your earlier reported #Bot down? above. Happened on the same day. I would just relist that so it goes back to the top of the list. – Wbm1058 (talk) 14:39, 29 January 2016 (UTC)
The new section Ellapsed listings is great, and the shortcut from WP:RME works well... could we add a {{shortcut|WP:RME}} template after the heading, similar to the one for WP:RMB after the Backlog heading? No great hurry or importance, it's fairly intuitive for old hands, but it just looks like something that should be done (and should be quick and neat and easy to do). Andrewa (talk) 09:11, 21 June 2016 (UTC)
I see that this change was discussed by a few editors at Wikipedia talk:Requested moves#Automatic bot notifications without notifying the relevant Wikiprojects. This seems like bad form, and I've blocked the bot to make the posts stop. In the case of the Military History Wikiproject, if there's a desire by project members to have a regularly updated list of moves it would probably belong somewhere like Wikipedia:WikiProject Deletion sorting/Military rather than on the busy project talk page. Ditto WP:AUSTRALIA. The suggestion made by the IP editor to consolidate these messages also seems like a good idea to me. Obviously this is a temporary block to be in place only until the bot returns to its previous settings and/or a broader consensus for this function is obtained (which should involve inviting members of the targeted Wikiprojects to comment, and probably to also opt-in). Nick-D (talk) 10:02, 29 May 2015 (UTC)
I broadly think the bots notifying WikiProjects of RM discussions is a good idea, but it can lead to filling Talk pages more than need be. On WikiProject China the bot added six new sections in a row—often a few minutes apart. Slightly fewer on Hong Kong, while MilHist got twelve. Could the bot combine multiple notifications, within say a 48/72 hour period, into one section on WikiProj. Talk pages? Each one could be added with a bullet point inside that section. –146.199.151.33 (talk) 09:11, 29 May 2015 (UTC)
Could we do away with the Wikiproject notifications for now so the bot can be unblocked so it can continue to update WP:RMCD and related pages? CalidumT|C02:01, 30 May 2015 (UTC)
Hi. A bunch of recent move requests (e.g. at Tagalog language) were never posted by RMCD bot at WP:LANG, and we now have a mess with one that passed without commentary from members of the wikiproject. Just wondering if RMCD bot will be there in the future?
@Kwamikagami: I had backed off my beta version of the bot which was updating the WikiProject talk pages, pending resolution of the changes discussed in the prior two sections above. I've just reinstalled that beta version, and will shortly declare it to be the official new production version.
Note however that because Wikipedia:WikiProject Languages/Article alerts exists, RMCD bot did not post a notice to Wikipedia talk:WikiProject Languages. You'll find the RM notices transcluded to WP:LANG § Alerts. But now I see that the open RM at Talk:Tagalog § Requested move 25 July 2015 isn't listed in the article alerts. I'll look at the AA setup to see why it's not there. The reason I don't notify projects using WP:Article alerts is that my bot was blocked for spamming one such project with too many notices. If your project wants to take advantage of both AA and RMCD bot notices, then I suppose an update to the bot to support overrides by transcluding {{bots|allow=all}} is something I could do (provided there was no other bot the project wanted to deny). Wbm1058 (talk) 18:03, 26 July 2015 (UTC)
Thanks. There have never been enough notices to swamp the project. There would have been a lot recently, but that would have told us something odd was going on. If there are other bots we want to block, could we use {{bots|allow=RMCD}}? (Probably not necessary.)
Bot notifying WikiProject on talk page of page move when proposed page for moving is the WikiProject page
Hey Wbm1058: Is there any way that RMCD bot can stop posting notifications such as this one in the future? I recall the consensus to notify WikiProjects that pages tagged with their banner are moved, but is it really necessary to post a redundant notice directly under the discussion when the WikiProject's page that is suggested to be moved is ... the WikiProject's page itself? Steel1943 (talk) 21:01, 28 July 2015 (UTC)
No, this is a different issue. The alerts were not actually posted directly to that talk page, but rather to Template:WikiProject Event Venues, which is transcluded on that talk page. I'll look into why it's doing that. Thanks for the notice, this is the first time I've seen this scenario. I'll scan the bot's edit history to look for other cases of posting notices to a template. Wbm1058 (talk) 21:39, 12 August 2015 (UTC)
This is only "relatively harmless" if nobody else notices it. As admins are taking time to delete these pages, I'll bump this up on my priority list and get to work on it today. Thanks, Wbm1058 (talk) 11:45, 29 September 2015 (UTC)
Thanks. I didn't realize that these were getting salted, but that actually makes it easier for me to debug. I see that one's still active on my bot's output console, and am working on this now, while the RM at Talk:See, Amid the Winter's Snow is still open, and to avoid the potential embarrassment of getting reported to the bot operator's noticeboard ;) Wbm1058 (talk) 13:33, 9 October 2015 (UTC)
I saw that when I got an alert from the notifications system. I see multiple curveballs are getting tossed at the bot here. I'll start with this one, since it's still active, and then work back through the others. The title "Template:WikiProjectBannerShell" isn't a problem in itself since it doesn't violate my assumed naming convention that all templates titled "WikiProject " are for actual WikiProjects, but five redirects to that template do violate that naming convention, including {{WikiProject Banner Shell}}, which is in Talk:See, Amid the Winter's Snow. I suppose that this hasn't been seen before now because relatively few talk pages transclude that redirect, but I see that actually 1100 pages do, so I'm kind of surprised that this one hasn't come up before. I'll update the bot's code to skip this when encountered. Wbm1058 (talk) 15:05, 9 October 2015 (UTC)
Neither of these are salted, because they weren't deleted until after the discussions had closed. So, not bad, only two of these in four months, AFAIK. Cases where the PROJECT name differs from the template name seem to be minimal.
So I've been writing & tweaking a script to analyze the problem here and design a robust solution. Found one extreme example showing how convoluted things can become:
Which is the non-standard name of the WikiProject (albeit a special kind of WikiProject – one centered around "galleries, libraries, archives, and museums"). I successfully find it by following the redirect.
Hi Cordless Larry, There are three WikiProject templates on that talk page. Notification of each is skipped because the project subscribes to Article Alerts:
The bot checks for those because when I first implemented it, it was temporarily blocked for spamming some WikiProjects with redundant notices.
Feel free to manually add redundant notices if you want; hopefully none of the project members will have a problem with that. – Wbm1058 (talk) 20:14, 10 November 2015 (UTC)
The problem here is that the bot assumes that any template beginning {{WikiProject is the template of a WikiProject. But of course there is no {{WP:WikiProject banner shell}}, so I need to hard-code a work-around into my PHP program. It would have made things a lot easier from a programming standpoint if the name of this template did not violate the naming convention for WikiProjects. If I had been aware of this conversation, I would have recommended a move to Template:WPBS or Template:Bannershell, or, if that's not a valid compound word, Template:Banner shell. There is no "Banner shell" WikiProject dedicated to maintaining and improving banner shells! – wbm1058 (talk) 15:34, 18 October 2016 (UTC)
Done – I've got a patch that skips any {{WikiProject template that has the string "banner" in its title. Of course this will skip any legitimate WikiProjects that are dedicated to "banners" of some sort, but I'm not aware that any such WikiProjects exist. wbm1058 (talk) 20:57, 18 October 2016 (UTC)
I've protected the latter page, which was being repeatedly recreated. The easy fix to at least stop the most annoying behavior is to have the bot check for deletion log entries and skip the notification if one exists and the edit would be a page creation. ~ Rob13Talk15:20, 22 December 2016 (UTC)
Fixed by bot version 6.21 -- BU Rob13, thanks. I realized my previous patches for this type of issue were kludges. Your suggestion led me to finally implement a more robust fix. I just don't post notices to blank or non-existent WikiProject talk pages. Duh. I should have implemented that patch sooner. wbm1058 (talk) 15:40, 23 December 2016 (UTC)
After further consideration of this, I've concluded that any bot-placed article-space notices will need to be monitored and controlled by the bot to ensure that editors don't initiate move discussions by placing such a template on articles without initiating a corresponding formal requested move discussion on the talk page. The bot would automatically place the notice, if it wasn't already there, at the top of articles as part of its normal processing loop, in similar fashion to the way notices are placed on the talk pages of other articles involved in multi-move requests. Then after completing the regular processing loop, a new lookup of all articles transcluding the bot-placed article-space template would be made, followed by looping through all of them to check for the corresponding {{requested move/dated}} template on the talk page. Upon failure to find the corresponding {{requested move/dated}} template, the article-space template would be removed. This would take care of both closed RMs where the closing admin neglected to remove the template as part of their closing procedure, and templates which, as inevitably will happen, were placed out-of-process as part of a malformed request.
Article page notification templates and lack of notification on multimove involved pages
Currently the bot tags an article with the move notification template. But in the case of multimove requests, the bot does not seem to notify all the pages involved, only the subjectpage of the talkpage where the discussion is taking place (or I assume, whatever is registered as "current1" if it is some other page)l Shouldn't the bot equally tag all pages involved in a multimove? -- 65.94.171.217 (talk) 05:22, 27 September 2016 (UTC)
Now on my to-do list: check if a page exists before notifying it of a move discussion. Don't create pages in subject-space. – wbm1058 (talk) 03:29, 1 November 2016 (UTC)
Bot version 6.16 is a patch to ensure that edit histories such as this one that I split to User talk:RMCD bot/KNPG-LD don't happen again. This is the patch I was installing when the clocks in the eastern US turned back an hour. That was just coincidental to the "oops" that was reported here, but the time change made things more interesting. I try to make my code updates fly under the radar, but wasn't quite successful this time. wbm1058 (talk) 15:35, 6 November 2016 (UTC)
You may want to consider using the Article Wizard to help you create articles.
A tag has been placed on Hawaii Five-0 (season 8), requesting that it be speedily deleted from Wikipedia. This has been done under section G4 of the criteria for speedy deletion, because the page appears to be a repost of material that was previously deleted following a deletion debate, such as at articles for deletion. Under the specified criteria, where a page has substantially identical content to that of a page deleted after debate, and any changes in the content do not address the reasons for which the material was previously deleted, it may be deleted at any time.
If you think this page should not be deleted for this reason, you may contest the nomination by visiting the page and clicking the button labelled "Contest this speedy deletion". This will give you the opportunity to explain why you believe the page should not be deleted. However, be aware that once a page is tagged for speedy deletion, it may be removed without delay. Please do not remove the speedy deletion tag from the page yourself, but do not hesitate to add information in line with Wikipedia's policies and guidelines. If the page is deleted, and you wish to retrieve the deleted material for future reference or improvement, then please contact the deleting administrator, or if you have already done so, you can place a request here. TonyBallioni (talk) 01:19, 27 November 2016 (UTC)
Sorry for the notification here. The bot recreated a page that had been deleted at AfD a bit earlier because it was involved in a rename discussion. I saw it was bot recreated, but forgot to disable the Twinkle notification when tagging. TonyBallioni (talk) 01:25, 27 November 2016 (UTC)
No problem, and thanks for the note. Still on my to-do list: check if a page exists before notifying it of a move discussion. Don't create pages in subject-space. See #Menisci (liquid) above. – wbm1058 (talk) 23:11, 28 November 2016 (UTC)
Wbm1058 Why does your bot persist in making edits like this? It should follow the redirect; which should not be posted to because it leads to the very place that the discussion is taking place. Also, having been reverted once, it should not make the same edit again; doing so three times is tantamount to WP:EW. --Redrose64 (talk) 21:01, 26 December 2016 (UTC)
Fixed in bot version 6.22. The curve thrown at the bot here is that Template:Rfc bottom is not a redirect, but Template talk:Rfc bottom is a redirect. "Shared talk pages" are very rare or non-existent for articles, and even for templates they are not the norm. This is a scenario I hadn't considered in the initial implementation of extended notifications, and hadn't seen in practice until now. There is no code in the bot's framework that I'm aware of that checks page histories for prior reversions, so the way to stop the bot from "edit warring" is to either use {{nobots}} or to admin-protect the page. I've held off on requesting admin privileges for the bot, which leaves the second option open, but that also means the bot cannot post RM notices on fully-protected pages. When I run across such a request, I post the notice manually myself. I recognize that there have been several fixes needed since the initial implementations of extended notices, but hopefully by now most of the unusual and unanticipated scenarios have been accounted for and fixed. Sorry for the inconvenience. wbm1058 (talk) 20:53, 27 December 2016 (UTC)
Thank you There are several template talk pages that redirect even though the template is not a redir - AnomieBOT creates them frequently. It's not just done for subpages like /doc /sandbox and /testcases, but also when two or more main templates for a group. --Redrose64 (talk) 21:28, 27 December 2016 (UTC)
All, are we sure this is the best resolution? So, if the talk page redirects to a talk page that is neither the talk page of the redirect or its move destination, that's okay? See this. I'm just wondering since following the talk page redirect could result in unintentional WP:CANVASSING. Steel1943 (talk) 20:08, 29 December 2016 (UTC)
I don't have a problem with that; this additional notification was something that was requested. Since Bieber redirects to Justin, it's appropriate to place a notice on Talk:Justin Bieber, lest we pull Justin off of PT status without giving adequate notice to his fans so that they could participate in the discussion. – wbm1058 (talk) 20:59, 29 December 2016 (UTC)
Yeah, didn't mean that was an example of the issue, but rather what issue the change may cause in the event of a poorly-redirected talk page... Steel1943 (talk) 22:53, 29 December 2016 (UTC)
Get the contents of Talk:Camille (album) (as of 04:00, 17 April 2017). Nothing there; this is a red link:
14:20, 22 February 2008 Luk deleted page Talk:Camille (album) (Speedy deleted per (CSD G8), was a talk page whose corresponding page does not exist. using TW)
Is Camille (album) a redirect, as of 04:00, 17 April 2017? Yes: #REDIRECT [[Camille (unreleased Prince album)]] (this is currently deleted page history, so only admins can see it)
07:29, 17 April 2017 . . Xqbot m (36 bytes) (Bot: Fixing double redirect to Camille (Prince album))
The style guide MOS:HEADINGS says: The heading must be on its own line, with one blank line just before it; a blank line just after is optional and ignored (but do not use two blank lines, before or after, because that will add unwanted visible space). Spaces around the Title (e.g. ==Title==) are optional and ignored.
On the one hand, you are right. As far as easily viewing a page, however, that is where these spaces and whitelines come in handy. You may also have noticed that the default of Wikipedia is to have them (just create a talkpage discussion, and see for yourself). In other words, it is indeed not mandatory, but it is good for clear layout. Debresser (talk) 18:45, 26 February 2017 (UTC)
@No such user: Fixed in version 6.41 – thanks for reporting this. I'm not sure whether the hyphen/en dash thing has anything to do with this, or that was just a coincidence, but the patch was similar to others I've made elsewhere in code. – wbm1058 (talk) 19:31, 18 May 2017 (UTC)
RMCD Bot bug again
It is again insisting on putting a notice on the very page where the RM request is located. When I removed the spurious notice, it put another one there. Please see Talk:Warner Bros. —BarrelProof (talk) 04:35, 3 June 2017 (UTC)
I don't know where to submit a bug report. So, I'm putting this report here. The problem is at the page Talk:Quasi-category. After I made a move request, the bot keeps putting a notice that there is a move discussion in the same talkpage (which is pointless of course). This is a bug. -- Taku (talk) 23:07, 10 June 2017 (UTC)
This is the best place to submit bug reports. Silly bot. It thought that [[quasi-category]] was a "different" page than [[Quasi-category]]. This edit stopped the notice from being posted. Fixing this to upper-case the first letter before comparing page names is on my to-do list now, along with replacing underscores with spaces. Thanks for reporting this issue. wbm1058 (talk) 03:05, 11 June 2017 (UTC)
Fixed in v 6.47 – the curve-ball here was the #Disappearance section link. Ironically that section doesn't exist anymore, not that it matters. One more "gotcha" gotten, thanks for the report. wbm1058 (talk) 17:57, 6 September 2017 (UTC)
RM bug?
@Wbm1058: Pinging you to bring this edit by RMCD bot to your attention. Long story short, since then it did not insert a line break after the use of the {{Search for}} template, it caused the rest of the nomination statement to display in boxed code (as if the line started with a space. I am aware this is human error since line breaks used in nomination statements prior to the nonimator's signature time stamp have the potential to mess up how RMCD bot displays nominations, but ... this is essentially a "FYI", but if it can be fixed, more power to ya. Steel1943 (talk) 18:02, 7 September 2017 (UTC)
@Wbm1058: See this diff. The section above this edit on the respective talk page seems to be the move request the bot refers to. My only assumption is that the RMCD bot thought this talk page was a different page due to the use of {{Lowercase title}} on the talk page. I could be way off on that thought, but I am not seeing any pages recently moved which relate to the move request, thus I'm not sure why the bot posted the notification. Steel1943 (talk) 02:53, 8 September 2017 (UTC)
@Steel1943: Fixed in version 6.49. You weren't way off, just slightly off. The issue was with the redirect Noindexing. The source wikitext is #REDIRECT [[noindex]]. I just tweaked the code to uppercase the first letter of that before comparing names, as technically [[noindex]] and [[Noindex]] are the same page. – wbm1058 (talk) 15:28, 8 September 2017 (UTC)
ArbCom 2017 election voter message
Hello, RMCD bot. Voting in the 2017 Arbitration Committee elections is now open until 23.59 on Sunday, 10 December. All users who registered an account before Saturday, 28 October 2017, made at least 150 mainspace edits before Wednesday, 1 November 2017 and are not currently blocked are eligible to vote. Users with alternate accounts may only vote once.
The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.
LOL. Where are MediaWiki message delivery's requests for approval? But I understand the rationale for bypassing that process as the election would likely be over before the bot was eventually approved. This reminds me of the time my Merge bot was invited to the Teahouse, by a user mistakenly believing that bots were powered by tea, rather than hot gear oil. In any event, a competent bot operator would have to be crazy not to ignore these notices. wbm1058 (talk) 15:29, 5 December 2017 (UTC)
The subject notice template should be placed underneath disambiguation hatnotes
As a maintenance tag, the subject notice template should be placed after disambiguation hatnotes, per Wikipedia:Manual of Style/Layout. The bot should be able to detect the presence of hatnote templates at the top of the page and place its notice accordingly. --Paul_012 (talk) 13:00, 28 June 2017 (UTC)
All contextual tags should be placed below hatnotes for articles ({{redirect}}, {{for}} and the likes) but the bot currently prepends the page move discussion tag to the article text instead. Please fix, thank you. --QEDK (愛 • 海)14:36, 25 September 2017 (UTC)
I'm looking for the source code that handles the MoveMaintenanceTags function, to help me fix my bot to comply with MOS:ORDER. It was requested that I do this on my bot's talk page: User talk:RMCD bot#The subject notice template should be placed underneath disambiguation hatnotes. While my bot is written in PHP, I'd like to match the AWB algorithm for this as best as I can (how to recognize all the various hatnotes and not miss any). So hoping I can translate the needed code to PHP. A lot of files to search through here. Can you point me to the right one? Thanks, wbm1058 (talk) 01:10, 22 September 2017 (UTC)
@Wbm1058: It is in MetaDataSorter.cs (Dablinks above maintance tags per [[WP:LAYOUT]]). The list of templates is in WikiRegexes.cs (public static readonly Regex Dablinks). Tools.cs has many supporting items. — JJMC89 (T·C) 23:55, 22 September 2017 (UTC)
Thanks, wow it's more complicated than I expected. NestedTemplateRegex supports nested templates and comments at end of template name. Would be nice if there was a library function I could just pass in the entire page contents and get back the properly sorted page. User:RMCD bot/botclasses.php doesn't have anything that fancy. A complete "general fixes" function even. Then my bot could apply all general fixes at the same time it posted its requested-page-move notice. Including putting the hatnotes above the bot's notice. wbm1058 (talk) 13:57, 23 September 2017 (UTC)
@Wbm1058: This is my first thought in the manner, though I am sure you have probably thought of this already: On pages with (a) hatnote(s) in the page's lead section, is it possible to program RMCD bot to place the template under the bottom-most transclusion of templates that invoke Module:Hatnote, provided the final template occurs before any level-2 (or greater) section headers to avoid false positives? (I seriously believe you have already thought of this, but that's my two cents.) Steel1943 (talk) 15:40, 25 September 2017 (UTC)
@Steel1943: No, the bot doesn't look under the hood to see what module is driving the hatnotes; it just parses the source code of each page. See the hats constant near the top of the source code. Every time an editor creates a new disambiguation hatnote or redirect to a disambiguation hatnote, that new page name needs to be added to this list for the bot's hatnote placement to work. By default, anything not on that list will still come after the bot's notice. – wbm1058 (talk) 17:15, 17 November 2017 (UTC)
Ahhh, I see. I was pretty sure you'd have it marked up somewhere since it's a small issue afterall. I'm glad you're looking into it. Generally, a regex replace pulls it off but here's complications. --QEDK (愛 • 海)18:10, 25 September 2017 (UTC)
I've been working on this, and am in process of debugging. The strategy is to place the bot-notice immediately after any disambiguation hatnotes that are already at the top of the page. If a hatnote isn't at the top of the page, I'm not fixing it. Need to avoid false-positive hits on hatnotes placed at the top of sections because of section-link redirects.
@QEDK and Paul 012: OK, this is Mostly Done now. Let me know if you see any pages where the bot's notice is not properly positioned. There is one loose end that I'm still looking at. I've run across pages where the templates {{italic title}}, {{pp}}, or {{Use mdy dates}}, or variants of those, are placed before the hatnote(s). I've coded workarounds that allow those to be treated as "part of the first hatnote". See the bot's edits to Yellow Dog Updater, Modified (that one just had a blank line above the hatnote), and Otogizōshi (italic title). Prague school had an {{Expand Czech}} template above its {{about}} template, so the bot only properly placed the template after I moved {{Expand Czech}} below {{about}}. Richard B. Spencer has a {{pp-vandalism}} template which the bot left in place "as part of the first hatnote", but maybe per MOS:ORDER the bot should move the pp template below the hatnote. The bot was still able to edit that page because it's just semi-protected; it couldn't edit Baked Alaska (entertainer) because that's fully protected. I sometimes manually post the notices on fully-protected pages. Just an aside, Wikipedia:Facto Post mailing list is a special page that the bot can't edit either. I expect I'll make some more tweaks to handle cases like these. – wbm1058 (talk) 17:15, 17 November 2017 (UTC)
It just occurs to me that I could just code this so that, from the bot's perspective, these italic title/use mdy dates/page protection/featured article templates were all just "pseudo-hatnote" templates! wbm1058 (talk) 04:11, 18 November 2017 (UTC)
Just reiterating but as stated, a handy way is to see if the Hatnote module is invoked, then if absent, you can go on to prepending and if present, identify the template call and appending, maybe save some processing time in the process too. (edit: holy shit, that was unintentional) --QEDK (愛 • 海)17:49, 18 November 2017 (UTC)
Fixed in v. 6.53 – I've enhanced it to allow placement of the most common aliases of the italic title, page-protection, use dmy/mdy, and featured/good article templates ahead of the navigation hatnotes. – wbm1058 (talk) 01:19, 1 December 2017 (UTC)
Resolved
