This is an archive of past discussions about Template:Requested move. 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.
Whoops, I should have paid attention to the history. For the record, I immediately noticed my error (and was going to self-revert), but was beaten to the punch. —Lifeisunfair17:21, 4 October 2005 (UTC)
Using the {pagename} parameter is simply rediculous, since an Wikipedia article can move at any time, and having the {pagename} destroys the usefullnes of this template. Unfortunately every page using this template will have to be fixed before the {pagename} parameter can be removed.--Commander Keane02:46, 14 January 2006 (UTC)
"the issue"...?
<!-- Please do not remove or change this Move Page message until the issue is settled -->
I note the source for this template includes the above comment at its very start; what is "the issue" that needs to be settled, please?
Once this issue is settled, would anyone mind my adding a sentence such as "Please indicate whether you support or oppose this proposal in the discussion below (usually headed "Requested move")."
As no-one has picked up on the above, I have amended the template and removed the unreferenced comment. Hope all acceptable. Regards, David Kernow15:27, 7 March 2006 (UTC)
Vote or not to vote that is the question
I think the "Discussion and voting to support or oppose the move" should be altered to remove the word "voting" from this template what do others think? --Philip Baird Shearer21:58, 8 May 2006 (UTC)
You've based this change upon the premise that "things are not voted on in Wikipedia." This is patently false. Wikipedia is not a democracy, but the word "voting" does not necessarily refer to "majority/plurality voting." In this context, it simply means "expressing one's preference for a proposed resolution of an issue." If you still don't believe me, I once again respectfully request that you consult a dictionary of the English language. —David Levy00:03, 9 May 2006 (UTC)
Technically true, many people are of the same opinion.
My problem is that a lot of people (especially newcomers) get confused by "voting", and we get the famous story of "60% approves that 1+1=3, so it must be true!" ;-) .
Perhaps it's wiser to explicitly state "expressing one's preference for a proposed resolution of an issue."
I oppose the idea of artificially simplifying or complicating wording (in articles and elsewhere). If users don't understand the difference between "voting" and "majority voting," the solution is to explain it to them, not to accommodate their misconception.
Either way, there are going to be instances in which someone challenges the meaning of the word "vote." If we purge all documentary references to the word, the people who continue to use it correctly will be on the receiving end of unfounded criticisms. ("This is a discussion, not a vote!") I've already had this happen, in fact.
Why keep text, that is open to misunderstanding and that appears predominantly on every talk page of an article with a request to to be moved, when it can be rephrased to remove the potential misunderstanding? --Philip Baird Shearer17:07, 9 May 2006 (UTC)
As I mentioned, the misunderstanding will occur either way. I see no valid reason to alter accurate wording, thereby increasing the likelihood of users being chastised for correctly referring to their comments as "votes." Also, I believe that any alternative phrase will fail to convey the process' nature as well as the word "vote" or a derivative thereof. —David Levy17:16, 9 May 2006 (UTC)
"The proposed move should have been noted at Wikipedia:Requested moves.
Discussions and preferences regarding this proposal should appear somewhere on this..." ...?
If you wish to solicit advance feedback, follow the standard WP:RM procedure (using this template). Otherwise, you should be able to simply perform the move. (The MediaWiki software allows this when the target has no history as anything other than a redirect to current title.) —David Levy21:11, 19 May 2006 (UTC)
Feedback wasn't really necessary, as it was pretty open and shut. I did not realize that the software would let me do the move without breaking history... I must have missed that somewhere. Thank you! :) -- Steven Fisher07:17, 20 May 2006 (UTC)
Template for the article page
Is there a related template to put at the top of the actual article page, to let visitors know that a move discussion is going on, on the talk page? --Elonka19:20, 27 June 2006 (UTC)
I don't think so, and nor do I think one should be used. This is an editorial issue not a reader issue. Articles accumulate far too much editorial cruft at the top as it is. Anyone who is interested will watch/look at the talk page. --Philip Baird Shearer20:58, 27 June 2006 (UTC)
Isn't there plenty of precedent for soliciting reader opinions though? For example, merges, deletions, lack of categories, and most other administrative actions are advertised on an article page. Why not move discussions? --Elonka22:02, 27 June 2006 (UTC)
(Update) Though I understand that in some cases it's not advisable to place a "suggested move" template on the main article page, there are some cases where it's still a good idea, for example where there's a very complex move discussion going on, on the talk page, and it's desired to attract as much attention to it as possible. If there's not a standard template for such a thing, I'm prepared to make one, unless someone else wants to give it a shot? --Elonka21:48, 12 July 2006 (UTC)
We should create a similar templete to go on the actaul article page instead of the talk page, so we can alert people that the page is being discussed for a potential move.--Sefringle02:05, 5 February 2007 (UTC)
Is there an appropriate template to declare the intention to move a page,
analagous to {{Split}}? I recently expanded the Split template
and changed the wording to refer to a move, but I'm not sure if that was the best choice? Thanks. jhawkinson02:09, 16 April 2007 (UTC)
Well there is an automatic list available via the 'What links here' feature. So: Special:Whatlinkshere/Template:Move. It's not grouped or sorted in any way though.
Regarding the wording though, I notice that on Wikipedia:Requested moves it says "There is no obligation to list such move requests here; discussions of page moves can always be carried out at the article's talk page without adding an entry". That makes sense to me, but this means the current wording on this template is too strong ("The proposed move should have been noted at Wikipedia:Requested moves"") -- Harry Wood (talk) 10:25, 13 February 2008 (UTC)
parameter two
I think a second parameter should be added to the template, to indicate the section where the requested move discussion is occuring, if it isn't the default "Requested move" t would be easier to set up than "section", if it were "{{{2}}}" instead. 70.55.85.177 (talk) 06:30, 17 April 2008 (UTC)
Yes, discussion is enough if no administrator help is needed... but then why use the template? If {{move}} is used, the proposal needs to be listed at WP:RM. JPG-GR (talk) 16:19, 10 March 2009 (UTC)
Code change
The recent change to check to see if the page has been moved,[1] is not working as intended. It produces confusing messages when the target is equal to the page name. Furthermore, it does not check for capitalization of the first letter of the page name and shows that the page has not been moved even if it has if the target does not capitalize the first letter. It was a nice thought, but produces confusing results, and really serves no purpose. Often during page move discussions, pages are pre-emptively moved, which would produce the message below indicating that the template should be removed, when in fact, it should not, if there was no consensus for the pre-emptive move. 199.125.109.88 (talk) 02:45, 2 May 2009 (UTC)
The proposed move should have been noted at Wikipedia:Requested moves. Discussion to support or oppose the move should be on this talk page, usually under the heading "Requested move". If, after a few days, a clear consensus for the page move is reached, please move the article and remove this notice, or request further assistance.
Maintenance use only: Add to WP:RM {{subst:RMlink|Template:Requested move/Archive 1|Template:Move|REASON|section=Requested move}}
Most editors are accustomed to locating {{move}} at the top of the talk page, so the template that they are supposed to be put there should retain the name "move". The template {{RMtalk}} automagically creates a Requested move section, and adds a location for discussion. It can optionally be used instead of {{movereq}} which should be subst'd, leaving behind a {{moverequested}} template that the bot would look for. 199.125.109.88 (talk) 15:57, 5 June 2009 (UTC)
Inclined to oppose. I think it's unnecessary at this point. People have started to get used to the new setup, and to have the only necessary template be named "move" is simple and intuitive. People who aren't used to the new setup will make mistakes until they're used to it, no matter how much we continue to shuffle the template names around. As an aside, making the template added to the top of the page optional is a real pain for closers. On talk pages with lots of templates, you have to wander through markup and wonder if you've missed it. I'd rather just have the old use of move be subsumed completely. Dekimasuよ!11:04, 6 June 2009 (UTC)
There is support for the moveheader, so if it makes life easier, I can write a script that checks pages for having {{moveheader}} but not {{movereq}}. When that is the case, moveheader gets removed from the page. —harej (talk) 16:29, 6 June 2009 (UTC)
The script has been made. Do not worry about removing moveheaders that do not have accompanying movereqs, since the bot now handles them 5 and 35 minutes past the hour (five minutes after each run the bot has). —harej (talk) 18:58, 6 June 2009 (UTC)
Also, to clarify the language, I would change "Place this template at the top of the move discussion on the talk page of the article." to "Place this template at the beginning of the requested move section on the talk page of the article." Top seems a little out of place for the end of the talk page. 199.125.109.126 (talk) 06:26, 12 June 2009 (UTC)
I would like to add a note to the documentation to let users know they can use {{db-move}} if they are just trying to get a target out of the way for a completely uncontroversial redirect. Does this sound reasonable? ErikHaugen (talk) 21:51, 11 October 2010 (UTC)
Substitution
What is the benefit of substituting this template? For the current template's behaviour it seems there is no advantage at all. The only possible reason is if you wanted to attach a date to the template so that it would be able to display the expiry date of the discussion. This is what Template:Proposed deletion does but it is not used on this template. — Martin (MSGJ · talk) 21:56, 13 August 2010 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I want the part of the template that isn't in a box excised and "It has been requested that ABC be renamed and moved" be changed to "It has been requested that ABC be renamed and moved to XYZ".
90.220.160.179 (talk) 22:06, 12 August 2011 (UTC)
There is a reason why it is done the way it is. While the box is removed when the discussion ends, the textual part below the box remains as a lasting record of the request. The list of transclusions of {{Requested move/dated}}, which contains the box itself, is the basis of the list of move requests. harej12:38, 13 August 2011 (UTC)
Proposed edit
Hello.
I am proposing an edit to show the target name, if it does not have that feature already. I am not sure if I had programmed it correctly, but I believe that the idea is still communicated. Please provide feedback or corrections. Thanks. 75.53.209.6 (talk) 01:09, 15 March 2012 (UTC)
The {{requested move/dated}} template used to behave as you suggest (see this old version), prior to this User:Harejedit. In theory, he's correct in that the new name (target name) in the template is redundant to the below-the-template archived name. In practice, editors sometimes make typos or change their mind on what the new name should be, and are unaware that they need to make the change in two places. They usually find the obvious one, which is displayed on the talk page, but miss the hidden one inside the template, which user:RMCD bot uses for the pages it writes. So, your proposal to make the template name visible again has merit. – Wbm1058 (talk) 21:09, 28 November 2012 (UTC)
This template doesn't work correctly when placed on a Category page. I think it is trying to wikify the category name and ends up categorizing instead of linking. Unfortunately it looks more complex than I want to try to deal with right now. ⇔ ChristTrekker15:50, 12 October 2011 (UTC)
Placement of the template when there is already discussion of the move
The Usage section says "Create a section at the bottom of the talk page..." but when there is already a discussion on the proposed move, it would be easier to follow if it was all together. Is there support for writing something into the documentation that the template should be added to the section with the discussion of the move?--SaskatchewanSenator (talk) 10:06, 5 February 2013 (UTC)
I assume that you're referring to the discussion at Template talk:Cleanup-link rot. In this case, no. If you're picking up on a discussion that's nearly four years old, link back up to it, which was done. On more active talk pages, older discussions are archived. Archives should generally not be edited, but you can link back into an archive too. Now, if there is a recent and ongoing informal conversation about renaming at the bottom, or near the bottom of a talk page, there may be some support for retroactively tacking the appropriate WP:RM/CM template on top of it to make it official. This doesn't happen often though. I would bring this up at WT:Requested moves if you wan to pursue it. Template documentation should be consistent with the instructions at WP:RM/CM – Wbm1058 (talk) 13:19, 6 February 2013 (UTC)
The merge templates already override the default image for |type = move. If we override it for moves as well, then we'll have a default image that's never used.
Or a new image should be uploaded directly to File:Imbox move.png, so that the image propagates to all templates where it is used, including {{old move}}, for example.
Could someone please add a nosign=yes parameter, for cases where a technical request is contested and converted to an RM? Apteva (talk) 16:16, 30 April 2013 (UTC)
An editor following these instructions should still sign their RM, shouldn't they?
I know, in practice other editors convert these on behalf of the original editor who made the technical request. What if the original editor decided that the contesting editor had made a good point, and decided that they did not want to pursue their request any further? What is, or should be, the procedure for making these conversions? I haven't seen any how-to instructions for third-party conversions. Should the third-party converter be required to sign the formal RM, or, as you imply with your request, should there be a way for the third-party converter to avoid signing the request? Wbm1058 (talk) 03:26, 15 May 2013 (UTC)
The key words above are "If your technical request". In this case it is someone else's request. The overwhelming practice is to not sign these conversions. It does not make any sense to have the reason for the request not show up at WP:RM, and all we would see there would be something like "Moved from TR." --sig Apteva (talk) 17:16, 20 May 2013 (UTC)
I see that there is a related discussion at Wikipedia talk:Requested moves/Archive 25#Converting technicals to RMs. That's probably a better place to achieve consensus on this matter. I see several good arguments there, including yours. The one point that I agree to for sure is that the current defacto conversion system isn't ideal and should be improved. I've noted problems in this area before to you personally (User talk:Apteva/Archive 6#Thanks for your help with Requested moves errors), sorry that I haven't yet come up with a better solution for technical request conversions, though it's been on my to-do list. I have a question for you, with regard to the RM at Talk:Jean Gordon (Red Cross Donut Girl). Did you want to personally take a position for or against the proposal, or simply initiate a discussion on a proposal on which you had no opinion, but thought that it was worth further discussion? Also, note that your signature was removed with this edit. Especially if you want to be on record supporting this RM, you should restore your signature there. Wbm1058 (talk) 03:12, 21 May 2013 (UTC)
You didn't give an example, but, with this edit you needed to use |reason= or |2= because there is an equals sign contained in your reason. The template documentation explains that:
If your reason contains an equals sign (often in web links), then, to work around MediaWiki T16235, use parameter reason= or 2= rather than an unnamed parameter.
Can a "reason=" parameter be added, so that the reason is transferred to the RMlink maintenance example, and additionally, the RMtalk template should appear in the maintenance section. 70.51.8.234 (talk) 11:27, 1 July 2008 (UTC)
Other new features include being able to specify the first new page name with either the first positional parameter or the parameter |new1= in both templates. Also, the |current1= parameter has been deprecated, and is now calculated purely based on the title of the subject page.
After adding support for both templates at Wbm1058's suggestion, I have had a further idea. Why not eliminate the need for two templates entirely? With Lua it is possible to detect the number of pages specified to be moved, and use different invocations for {{requested move/dated}} accordingly. This would mean we could redirect move-multi to this template, and simplify the instructions at Wikipedia:Requested moves. The code to do this is already mostly there in the module. What would people say to this idea? — Mr. Stradivarius♪ talk ♪15:58, 18 February 2014 (UTC)
I think you're on the right track. One edit check I never implemented in "multi" was to check if, for example, parameter new4 was specified, that current4 was also specified and a valid page – requests failing that check could report an error like "Must create {{{current4}}} before requesting that it be moved". This might catch a typo error in the page name to be moved. This error check should be much easier to do with Lua.
{{RMtalk}} is already a shell that calls {{requested move}} with certain parameters already specified, and I see no reason why {{move-multi}} couldn't be a shell as well. So a {{move}} request automatically becomes a "multi" request when parameters current2 and new2 are specified.
One more piece to finishing the puzzle. RMtalk has a feature that writes a unique default section header based on the {{subst:CURRENTTIMESTAMP}}. I was planning on eventually incorporating that feature into {{requested move}}. That way, "multi" requests can be able to write default headers as well. I was hoping to get consensus for making the {{RMtalk}} way of doing section headers the default. Wbm1058 (talk) 17:04, 18 February 2014 (UTC)
@Wbm1058: Ok, it is now finished. omitted currentn parameters are now checked for, and requests automatically become multi requests if currentn or newn is specified, where n is greater than 1. Also, the namespace checks now apply to all currentn parameters, not just the first. (And don't worry, if the user specifies the current1 parameter it is overwritten with the subject page name.) I have also added support for the heading, but at the moment you need to specify |heading= or |header= for it to work. If you want to go through the process of getting consensus for it, we could just switch that to including the heading by default. Have a play around with it and see if you spot anything I missed. — Mr. Stradivarius♪ talk ♪08:33, 21 February 2014 (UTC)
Kudos to you, Mr. Stradivarius. I've finished playing with Module:Requested move, and it is a big improvement over the existing template. I just found a couple of issues with it, and am confident that I successfully fixed them myself. I'm ready to give it a beta run. If all goes well with that, I'll update the documentation and redirect {{move-multi}} in a day or two, more or less. I'm still going to use the template for the subst: check, so that subst: {{error}}s are transcluded. But the redundant check in the module shouldn't hurt, and will still be helpful if any editors invoke the module directly. Thanks! Wbm1058 (talk) 22:47, 26 March 2014 (UTC)
I fixed the error check order, as you were trying to check things in the title object before it had been created, which was causing script errors in some circumstances. Other than that, it's all looking good. Thanks for taking a look at it. :) — Mr. Stradivarius♪ talk ♪01:13, 27 March 2014 (UTC)
Very good, I see that I pulled up the namespace checks higher in the code than I needed to. Didn't want it telling editors 'Must create category (file) before requesting that it be moved', only to then tell them "but we don't move categories!" right after they "followed orders" and created the category (file). Wbm1058 (talk) 15:20, 27 March 2014 (UTC)
template:error
Consolidating discussions by continuing the conversation about {{error}} started at Template talk:Move-multi#Current page? here. The problem with the {{error}} template is that many Category:Taxobox templates routinely transclude that template even when there is no real error. I spent some time digging into why they did this some time ago and eventually gave up. See here all the pages transcluding the error template. For example, Albertosaurus transcludes error, but isn't displaying any error message and it's not immediately obvious that there is any problem (probably there is no problem at all). Now if I restrict my search to talk pages, it is a little easier to find pages with real errors, for example here, here, here, here, here, here and here. The taxobox templates are quite complex—maybe the part that spuriously transcludes errors where there are none could be rewritten to not do that? Otherwise, a kludge shell {{real error}} could in turn transclude {{error}} so we can easily find them? I have no idea how many real errors there might be in article space. Wbm1058 (talk) 18:04, 18 February 2014 (UTC)
Template:Automatic taxobox/map gives an overview of the taxobox templates structure. Perhaps that will help in finding where the culprit erroneously transcluding errors is lurking. I'm surprised that none of this has been rewritten in Lua yet. Wbm1058 (talk) 20:24, 18 February 2014 (UTC)
I fixed the taxobox {{error}} transclusion that you found, and now all the articles that were transcluding it have now disappeared from the "what links here" page. There still seem to be quite a few other uses that aren't real errors though; cleaning those up would probably require quite a bit of sleuthing. — Mr. Stradivarius♪ talk ♪01:45, 21 February 2014 (UTC)
Hi could we create a template that can be used on templates please. And can we create a template that we can put on articles to tell readers that this page is being considered for being moved. Paladox2017 (talk) 15:38, 31 March 2014 (UTC)
Hi, Mr. Stradivarius. In case you didn't notice, I redirected template:move-multi to {{requested move}}, so we are now fully live with your module. I've been busy updating redirects and documentation. I just noticed that while you check the currentn parameters and report
errors, you didn't do a similar check on the newn parameters, and the module doesn't handle them gracefully, e.g., John Green (author) → [[:John Gr>een]] in a test I did. I created Module:Requested move/sandbox to work on this, but thought that you could do it in a fraction of the time it would take me. One of these days I'll take some more time to study Lua. Thanks, Wbm1058 (talk) 19:37, 29 April 2014 (UTC)
This wouldn't be hard to do, but there's a hidden penalty. At the moment, I'm checking for invalid titles by creating a title object with mw.title.new. That is an expensive function - every time it is called on a new page, the expensive parser function count is increased. And if the expensive function count for the whole page goes over 500 while the module is running, it will produce a script error. On a blank page, this would give us a limit of 250 pages (250 current + 250 new), and on a page that already contains lots of expensive parser functions, that number will be less. We can use pcall to avoid the script error, but the fallback behaviour would be to treat valid titles as if they were invalid, which is just as bad. This would only be a problem if someone made a move request involving hundreds of pages, though - are you aware of any such requests that have happened in the past?
An alternative would be to not use mw.title.new, but to just check for bad characters in the title. This wouldn't increase the expensive function count, but it also wouldn't catch invalid interwiki prefixes. It would, however, have the advantage that we could tell the user exactly what character was invalid, e.g. 'invalid character ">" found in the "new3" parameter'. We could also check the currentn parameters with this check, as it seems like it might be useful. Do you think this is a good idea, and if so, what wording would you like for the error message? — Mr. Stradivarius♪ talk ♪04:50, 30 April 2014 (UTC)
Recall that we had to hard-code each parameter in move-multi when it was a template, and thus the limit was 30 because that's where we stopped adding parameters. I've seen someone request about 90 moves by putting together three sets of 30-move requests, but don't want to encourage that type of request, which probably is better handled as a proposal to change a naming convention on some guideline's or WikiProject's talk page. I've noticed that the module seems to run a bit slower than the template did, but that trade-off seems worth it compared to the time it takes to manually fix mistakes, and this template isn't used that frequently. Yes, telling the editor which character is invalid seems helpful – 'invalid character ">" found in the "new3" parameter' works for me. I wouldn't worry about the interwiki prefixes as I've never seen anyone request moves for other wikis. Just checking for File: Category: Talk: etc. like we already do is probably enough. Thanks, Wbm1058 (talk) 05:26, 30 April 2014 (UTC)
In that case, we could add both checks. I'll do that in the sandbox so that you can take a look. As for the execution speed, we should be able to improve that by only using arguments from the parent frame instead of from both the current frame and parent frames as we do now. This would mean that {{subst:#invoke:requested move|main|new=Foo}} wouldn't work, but {{subst:requested move|new=Foo}} would still work. That will halve the number of wikitext argument lookups we need to make, which is often a cause of performance bottlenecks in Lua. If the bottleneck is the increased amount of error checking, though, then there's not much we can do, but we won't know which it is without trying it. — Mr. Stradivarius♪ talk ♪05:47, 30 April 2014 (UTC)
What would be an example of an "incorrectly formatted interwiki prefix" that was also an invalid title? Any "invalid namespace" is still a valid title, e.g., I can create User chat:John Green, which is still a valid mainspace title. And if I put an "invalid interwiki prefix" on it, e.g., mega:User chat:John Green, it's still a valid, albeit unlikely, title. Wbm1058 (talk) 17:35, 30 April 2014 (UTC)
I see. Interesting. I just updated Wikipedia:Namespace and Wikipedia:Page name. C: and meatball: still don't throw errors. To get an error you would need to find them on the list at m:Special:Interwiki. Looking at a practical example, Q: Are We Not Men? A: We Are Devo! doesn't give an error either (see Are We Not Men? We Are Devo!). If it isn't easy to check the interwiki table then it's probably not worth the trouble as this scenario is quite rare. Maybe just omit the part about "incorrectly formatted interwiki prefix" as it might just confuse people. Actually with the new check invalidChar = page:match('[#<>%[%]|{}]') I'm wondering what still falls through to get caught by the next check "for invalid titles that aren't covered by the previous check." I haven't found any examples that trigger that error yet. – Wbm1058 (talk) 02:17, 1 May 2014 (UTC)
Ah yes, you're quite right about the interwiki prefixes. That was a bug, as title objects with interwikis are valid, but the page cannot be created on the local wiki. I've added an extra check for interwiki prefixes and altered the error messages, so this should be fixed in the sandbox now. — Mr. Stradivarius♪ talk ♪09:38, 1 May 2014 (UTC)
This move request was submitted as a single move over a disambiguation page. With this edit I converted it to a multi-move request. Just wondering if it might be possible for this module to detect requests to move over disambiguation pages and automatically create a multi-move request that includes the implied move of the dab page, i.e. automatically convert to a multi-move request as I did manually. – Wbm1058 (talk) 02:29, 30 April 2014 (UTC)
That's going to be hard to do. You can grab the page source, but the problem is that you have to then parse the source to find whether it has a disambiguation template in it. You would have to keep an up-to-date list of all disambig templates and their redirects, and you would probably have to keep tabs on the amount of string processing being done if many lengthy pages need to be parsed, so that we can keep execution time down to a reasonable amount. (If we go over 10 seconds in Lua on a given page, we get a script error.) And might there not be situations where you want to move a page over a disambiguation page, but not move the disambiguation page as well? — Mr. Stradivarius♪ talk ♪05:03, 30 April 2014 (UTC)
Right, at Talk:Converge (band)#Requested page move there is a request to move over a 2-item dab Converge, which could possibly be eliminated in favor of hatnotes (if there is a primary topic). Maybe we would limit automatic multi-conversion to dabs with more than two or three items in them. Look at Help:Magic words#Behavior switches:
The check itself would be easier, but again, there's a problem. Often __DISAMBIG__ is inside a template, so detecting it would require us to use frame:preprocess with every page. That involves expanding all the templates and parser functions on the page, and will probably put us over the 10-second limit after just two or three pages, depending on what templates they use. We could reduce the load by using some criteria to decide which part of the page to parse, but deciding which part isn't easy, and it may put us over the limit anyway depending on what we end up processing. — Mr. Stradivarius♪ talk ♪06:00, 30 April 2014 (UTC)
@Mr. Stradivarius: In the Wikipedia:Requested moves/Lead section there is a note[1] that is just distracting to editors trying to learn how to submit move requests. I'd like to move it to Wikipedia:Requested moves/Closing instructions, which may be a better place for its intended audience to read it, but was wondering if you might modify this module to blacklist those three pages. If an editor attempted to use {{requested move}} on a talk page in the blacklist, then give an error:
I've seen comments suggesting that the WP:RM instructions are too long or complicated, and this would be a way to shorten them a bit. Note that there's a template for that: {{IECOLL-talk}} – that's just transcluded on the three banned talk pages. They did have a discussion here as recently as January. Which of course was started on one of the banned talkpages, in spite of that banner ... say what? (sigh) This is what it looked like just before closing (they got inventive to make it work: current1=?|new1=?), and amazingly enough the bot did not choke on that. I've been asked in the past about supporting (multi-)move discussions on WikiProject talk pages. I suppose that wouldn't be too hard to do—I mean to support it in an official and more graceful way. Maybe by setting new1 = talkonly to indicate that there is no desire to move Wikipedia:WikiProject Ireland Collaboration, or something like that. Thanks again, Wbm1058 (talk) 02:13, 2 May 2014 (UTC)
^
Note to closers: according to an ArbCom ruling of June 2009, confirmed in September 2011, discussions relating to the naming of Ireland articles (Ireland, Republic of Ireland, Ireland (disambiguation)) must occur at Wikipedia talk:WikiProject Ireland Collaboration, unless it is agreed there to hold the discussion elsewhere. Any requested move affecting these articles that is opened on the article talk pages or any other venue should be speedily closed, with a pointer to the ArbCom ruling.
@Mr. Stradivarius: Upon further review, I think it best not to put error checks in the module to prevent RMs of the Ireland titles, unless there is a specific consensus for that. Given the caveat "unless it is agreed there to hold the discussion elsewhere", I suppose "elsewhere" could be one of the ArbCom-blocked pages, i.e., there could be a discussion at Talk:Ireland if that is prior agreed to by a consensus at Wikipedia talk:WikiProject Ireland Collaboration. I moved the notice from the WP:RM lead to the closing instructions. Wbm1058 (talk) 17:55, 8 May 2014 (UTC)
Unwanted whitespace when copying code samples from the docs
I just noticed that when I copy and paste the examples from the docs I get unwanted whitespace.
This is the current code being used to produce the code boxes:
This shows up as a blank preformatted text box followed by the normal move request template. This is on my work computer, Win 7 with IE9. I've tried various ways to preserve the current appearance of the code example and still have the code copy and paste correctly, but I haven't had any success so far. The best I've done is to use <pre>...</pre> tags with a style attribute to emulate the box, but with this solution wikicode is not parsed, so the parameter names can't be shown in italics. I think we should switch to using pre tags anyway, as this copy-pasting issue will be a likely source of errors, but what do others think? — Mr. Stradivarius♪ talk ♪00:31, 2 October 2014 (UTC)
I see what you mean. I never noticed the problem using Google Chrome. When I copy&paste, the highlighted area extends outside of the white area, all the way to the edge of the green area, on both the right and left sides. With Internet Explorer, the highlighted area stays inside the white box. About the only time I use IE is when I want to print a hardcopy of something, and want more options for re-sizing it to fit on a piece of paper. I just copy the url I want to print out of Chrome and paste it into IE. But I suppose we should make changes to better support IE if we can. Wbm1058 (talk) 01:52, 2 October 2014 (UTC)
Resolved
Moved from Module talk:Requested move
