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.
O great RM template guru, I have a request. Would it be possible to edit the standard and multi RM templates to add an optional parameter that would suppress auto-signing? Something like |sign=no? Auto-signing can occasionally cause problems, such as when someone converts another editor's move to a multi-move or simply replaces a malformed request. It's not the end of the world that the current arrangement requires a second edit to remove the extra signature, but would this be a viable option? It's hard to imagine this being abused, and it would be easily remedied (such as with {{unsigned}}) if it were. --BDD (talk) 17:24, 14 June 2013 (UTC)
"template guru". It takes a lot of time & effort to become one. Since you, and another editor, have asked for this before, I'm working on it—and those templates are becoming even more complex. Wbm1058 (talk) 17:14, 16 June 2013 (UTC)
Sorry to keep you waiting, this is still on my to-do list. I started working on it, and while doing that, found other enhancements I felt should be done first. Wbm1058 (talk) 14:51, 10 July 2013 (UTC)
@BDD and Mr. Stradivarius: Well, it's been over a year since BDD made this request on my talk page. I've copied it to here. At the time I was managing two templates which already were a rat's nest of multi-layered logic, so this was tabled for other priorities, like combining the templates and converting them to a single Lua module, where there is now a single line with the four-tilde signature code. So this should be much easier to implement now. I have no problem with it, though with other improvements that have been made, the need for it may be less now. Mr. Stradivarius, can you implement this for me? Thanks, Wbm1058 (talk) 22:37, 1 October 2014 (UTC)
When the RM is cross-namespace, a notification is added. When the ns of origin is mainspace, the text turns out awkward: "This proposal is for a cross-namespace move from to Wikipedia namespace." (Example in case: here[1]). This could also be the case in the reverse direction (target ns is mainspace). -DePiep (talk) 20:59, 9 December 2014 (UTC)
I guess we can take our time with fixing this, until the ball drops in London, to ensure there is a consensus for this – just over a day to go ;) Wbm1058 (talk) 22:36, 30 December 2014 (UTC)
Although that rule may not officially apply in project space, I suggest that using these zero-padded dates is basically ugly and we shouldn't use it in project space for the same reasons it's discouraged in article space – it looks like a format made for computers instead of for people. Moreover, if our automatic tools are doing it in project space, that will encourage the practice to seem more acceptable and to drift haphazardly into article space. —BarrelProof (talk) 23:45, 30 December 2014 (UTC)
{{requested move/dated|NewName}}
[[:OldName]] → {{no redirect|NewName}} – Because of <del>this reason</del> <ins>that reason</ins>. [[User:Username|Username]] ([[User talk:Username|talk]]) 08:58, 11 April 2015 (UTC)
with identical results.
This seems to be a bug with how the software handles the paragraph following a table, but I feel like the documentation here and/or at WP:RM should warn against using such markup in the first paragraph. Or as a workaround, enclosing {{requested move/dated}} in a dummy <div>...</div> element seems to fix things. —174.141.182.82 (talk) 08:58, 11 April 2015 (UTC)
This is really a MediaWiki bug, not a bug in the template. I've started a new section about it at Wikipedia:Village pump (technical)/Archive 136#Obscure parser bug. As a workaround, the neatest solution might be to move the category code inside the |text= field of {{tmbox}} in {{requested move/dated}}. But this bug likely affects more templates than just this one - I suspect it's only not been noticed up to now because not many people use <del>...</del> and <ins>...</ins> tags. It would probably be best to fix the bug in MediaWiki rather than putting workarounds in all of our affected templates. — Mr. Stradivarius♪ talk ♪16:26, 11 April 2015 (UTC)
I know it’s not a bug in the template, but it is a bug that manifests with the template. That’s why I ask for revisionary tags to be discouraged until it’s resolved. —174.141.182.82 (talk) 16:28, 12 April 2015 (UTC)
To be fair, it does look like it might take a long time until this can be resolved in MediaWiki, judging from phab:T95830 and phab:T89331. But seeing as the bug is in MediaWiki, not just this template, you would have to issue the warning for all pages, or if you're feeling conservative, for all templates that use syntax like the output of {{subst:rm}}. That would be a lot of work, and you would have to remove all the warnings again when the bug was resolved. — Mr. Stradivarius♪ talk ♪16:47, 12 April 2015 (UTC)
I think it would only be necessary for templates that include a table (e.g. messageboxes like {{requested move/dated}}) and a paragraph beginning with a wikilink (like move requests). So that’d be all templates with markup equivalent to … |} [[…. Aside from {{rm}} and {{RMtalk}}, what else does this? Unless I’m mistaken, the RM templates are easily the most impacted by this bug. —174.141.182.82 (talk) 17:47, 12 April 2015 (UTC)
Ok, I've updated the template. As for why it works, it's because it puts the category inside the <table>...</table> tags generated by {{tmbox}} rather than outside of them, breaking the fragile chain of circumstances that the bug needs to manifest itself. (As for why the fragile chain of circumstances exists in the first place, apparently it has something to do with HTML Tidy.) — Mr. Stradivarius♪ talk ♪18:51, 12 April 2015 (UTC)
Ohhh… I thought it was the table that did it rather than the category. So disregard those bits in my earlier comments; sorry about that! And thanks for fixing this (or close enough)! —174.141.182.82 (talk) 19:54, 12 April 2015 (UTC)
When I preview a subst of this (standard editor) then the preview for the section title is "Proposed move: 15 November 2015" whereas once saved it is "Requested move: 15 November 2015". A little bug there somewhere, I think. Si Trew (talk) 03:05, 15 November 2015 (UTC)
@SimonTrew: Hmm, I'm not quite sure how this happened. Do you remember the exact template and the exact parameters you used? I see that the default move reason is "Please place your rationale for the proposed move here", but that's the only time that the word "proposed" appears in Module:Requested move. — Mr. Stradivarius♪ talk ♪05:12, 15 November 2015 (UTC)
@Mr. Stradivarius: I used {{move}} (subst'd) which is a redirect to {{Requested move}}. I had already got a section title on the page, obviously it adds its own (which I usually then delete). I'll try to produce it better. Perhaps it probably only happens if I do "Create new section" on the page, it didn't happen when substing that template into this text and previewing it. Sorry for not giving repro steps before, I thought it might just be an obvious little bugette. Si Trew (talk) 05:18, 15 November 2015 (UTC)
@Mr. Stradivarius: Yep, I'm an idiot. It happens just cos when you create a new section for a page, it echos out on the preview pane what you have put in the edit field for the new section's title. Nothing to do with the template. Sorry to bother y'all, what an idiot I am. I don't use these often, and was not aware of the header=no (and sign=no) options. If all else fails, read the documentation... Si Trew (talk) 05:23, 15 November 2015 (UTC)
I haven't yet figured out how to pre-populate the edit summary with the auto-generated section header Requested move 15 November 2015, as /* Requested move 15 November 2015 */
Ah, this looks like the ticket: Generate automatic summary /* blah */ when I manually add a section heading when editing. Right, this would be helpful for anyone manually adding a new section by typing "===" rather than clicking on the "New section" tab. Assigned To: NonePriority: LowBrion VIBBER created this task (Via Legacy) · Aug 19 2009, 5:39 AM. It's been on the wish list for six years. Sigh. Ryan Kaldari (WMF), any chance such an enhancement could be implemented by your group? I suppose I could add it to the growing mountain at m:2015 Community Wishlist Survey. My gut tells me that the right developer should be able to knock this off in no more than a day or two. But usually these kinds of "minor" enhancements only get eventually implemented by volunteers. Wbm1058 (talk) 13:58, 15 November 2015 (UTC)
@Wbm1058: This would definitely fall under the purview of the Editing Team. FWIW, I doubt think it would be a trivial change to implement, but that would largely depend on how you decided to handle the edge cases. I've posted a couple questions on the Phabricator ticket to start discussion on it. Ryan Kaldari (WMF) (talk) 02:59, 17 November 2015 (UTC)
@SimonTrew: Don't worry! Our template system on MediaWiki/Wikipedia is very complicated, so it's very easy to be confused by it. It often confuses me too, and I consider myself an expert in template writing... — Mr. Stradivarius♪ talk ♪13:08, 15 November 2015 (UTC)
I see that in the template you can add "sign=no" if you want to suppress the signature. Is this proper? Does this mean we are not required to sign the RM and it's just an option? Most of the time I see the signatory of the requested move, but I wanted to know if I had to do it. I tried it for an RM and someone else plopped my signature in anyways. Fyunck(click) (talk) 08:41, 17 September 2016 (UTC)
I don't know if it's required or not, but it makes sense for the person proposing the move to sign their proposal so others know who proposed it. However, I can think of at least 2 reasons a person might not want to use the automatic signature. First, they might be proposing it on behalf of someone else, perhaps new user who doesn't know how to propose a move, or did it wrong, and the person is cleaning it up. Second, they might want to add comments after the move proposal box, and then sign those comments, so that there aren't 2 sigs. - BilCat (talk) 09:19, 17 September 2016 (UTC)
Lately when I've tried using this parameter, it's suppressed my name but not the signature, as though it's still supplying a ~~~~~. Is this a feature or a bug? If the former, I supposed I could used to signing with ~~~ instead, though it would seem to defeat the purpose of the parameter.
By the way, for Fyunck(click) or anyone who wonders: why do I like to do this, to the point of requesting the parameter myself? I like to sign with --~~~~. The signature button in the MediaWiki editor supplies this, and it's always been how I prefer to sign my posts. Trivial, sure, but unless those dashes are interfering with something, I don't like the method of my signing interfered with any more than I would appreciate someone else editing my comments. --BDD (talk) 18:53, 3 November 2016 (UTC)
Requested move 27 May 2017
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.
What problem are you trying to solve? Perhaps "dated" isn't the best term to use here, but I don't see a sufficient rationale for compelling two bot operators to change their source code, and requiring documentation updates as well. The action of substituting {{subst:Requested move}} "dates" the RM transaction, though the date is placed outside the Template:Requested move/dated parameters, so that the date of the request is preserved after {{Requested move/dated}} is deleted. – wbm1058 (talk) 14:58, 30 May 2017 (UTC)
I see that /dated is also used for Template:Article for deletion/dated. It's fine for the date parameter to be part of that template, as if the page is deleted, everything is gone, and whether the date is a parameter inside the template or text placed outside the template is irrelevant. RM is a different use case. wbm1058 (talk) 22:45, 31 May 2017 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.
Remove the automated section heading?
Some editors tend to add the title of the request without realizing the automated "Requested move day month year" heading. If removal is not a good option, what else shall we do? --George Ho (talk) 01:44, 20 February 2016 (UTC)
This behavior was implemented in December 2014 per Updating the template to use the "RMtalk" default section header. The rationale was to merge {{RMtalk}}, which automated the section heading, with {{Requested move}}, which did not. The problem is, for every editor who adds a redundant header when the template creates an automated header, there is another editor who neglects to create a header, or doesn't create a unique header, when the template does not create an automated header. It's probably easier to remove redundant headers than to diagnose and fix certain scenarios that may occur when a unique header is not created. I've been hoping that Phabricator T22307 would provide the solution for this, but development and implementation of that has been frustratingly slow. Code fixes were done at a May 2017 hackathon, but it's been stalled since then, still waiting for review. Another possible enhancement, and way to work around this, is to develop an input form for submitting requested moves, so that direct use of {{subst:Requested move}} will no longer be necessary. Editors would simply fill out the form, click Submit and then the form would internally use {{subst:Requested move}} to complete the request. I might look into trying that approach again, to try to reduce the number of malformed requests. – wbm1058 (talk) 15:47, 26 September 2017 (UTC)
Anomalocaris, oh, I see. Sorry. This is a centralized discussion page for both templates, so we can handle it here. I didn't think to look at the "sub-template" since you didn't make the distinction. wbm1058 (talk) 19:37, 29 October 2017 (UTC)
wbm1058: In the past 3 months, I have edited a few templates, but this is way above my pay grade. I assume that when you say "I'm not sure what the problem is," you are acknowledging that template does yield a misnested <small> tag, but like me, you don't know how to fix it. —Anomalocaris (talk) 20:09, 29 October 2017 (UTC)
Anomalocaris, no, I mean that I don't immediately see any obvious problem.
Internally, it uses Template:Tmbox which in turn runs Module:Message box which has <small> tags in it. There could be some interaction there.
Talk:State of Palestine: {{requested move/dated|multiple=yes
|current1=State of Palestine|new1=Palestine|current2=Palestine|new2=Palestine (disambiguation)|current3=Palestinian flag|new3=Flag of Palestine|}}
So it seems you see this with every single transclusion of the template. Is there anything wrong with the visible appearance of the page when you look at it? Templates are above your grade; to some extent html tags are above mine. What exactly do you mean by "misnested"? I use <small>say something!</small> to write small text: say something! "say something!" is nested between the tags, which makes the text small. I assume you're seeing this in the raw html produced by the page. Can you show me the exact syntax issue you see in the raw html? I still don't see it. wbm1058 (talk) 02:43, 30 October 2017 (UTC)
wbm1058: For more on misnested tags, go to Lint errors: Misnested tags and click on "Help" in the upper right corner. In example 4, <small>...</small> tags wrap around multiple bullets. This is not allowed because bullets are coded as <li>...</li>, and <small>...</small> can't wrap that; <small>...</small> has to be inside<li>...</li>. In {{Requested move/dated}}, we had a similar situation with two cases of <small>...<div>...</div></small>. These had to be rewritten as <small>...</small><div><small>...</small></div>. (There are several oversimplifications in this explanation, but it's good enough.)
Thanks. The Linter extension is apparently something added in the past year, that I wasn't aware of (I may have seen a notice, then forgot it). I just added it to my list at Help:SpecialPages. I see these are listed as "medium priority" at Special:LintErrors, and there's only some half-a-million more left to fix. I never noticed any misnested tag warning on pages with open requested moves. – wbm1058 (talk) 12:03, 30 October 2017 (UTC)
wbm1058: If I had a magic wand, I would make it so that "Show preview" and "Save changes" would warn users of lint errors, or at least new lint errors. But that's not how it works now. There are no misnested tag, or any other lint error, warnings to notice, so if you want to find lint errors:
The tools menu on (almost) every page has a "Page information" link, which gives a page that lists, near the bottom, a count of the various lint errors (if there are any), but no further info telling you where to find the them.
User:PerfektesChaos/js/lintHint describes a tool you can install that identifies and localizes lint errors while you are editing.
I am a user of malayalam wikipedia. I would like to know the statements in the module that needs to be changed for displaying the message of requested move in the article page and not in talk page. Adithyak1997 (talk) 03:06, 28 August 2018 (UTC)
@Huon, I have removed lines 213 to 224 of the module from malayalam version but the warning "This template is misplaced. It belongs on the talk page" is shown. How can that be removed?Adithyak1997 (talk) 15:03, 29 August 2018 (UTC)
I don't know Lua in general nor the Wikipedia-specific parameters used in this module and thus have to guess, but I'd try if not title.isArticle then or something like that, something that, instead of checking whether you're off a talk page, checks whether you're off an article. If you can't guess the correct word, you can remove that entire if clause outright, but then your template can be placed anywhere, talk page, article, wherever. You may also want to take a look at the next if clause which makes sure the template appears on the talk page of the article to be moved. To me that one seems as if only the text of the message might need changing; otherwise it also could be removed outright if you don't mind losing a little more functionality. Huon (talk) 18:56, 29 August 2018 (UTC)
If an RM is closed and reopened
If an RM discussion is closed and reopened, will the RMCD bot come back and tag the discussion as an RM again after delisting it? In other words, how do I make the discussion a requested move again? —Wei4Green | 唯绿远大 (talk) 23:57, 27 April 2019 (UTC)
Move links
Rather than the "direct move" link in the box, I would like to have a link to move each article in the list underneath. This would make things easier when multiple pages are to be moved. — Martin (MSGJ · talk) 19:43, 9 May 2019 (UTC)
Martin, the change would need to be made in Template:Requested move/dated, which is still a conventional template. Since Template:Requested move was converted to use Module:Requested move, the former hard-coded limit on the number of moves in a request (20 or 30) was eliminated, and now we sometimes see requests to move over 100 pages. So while I don't think Template:Requested move/dated needs to be entirely converted to Lua, I think a Lua module could be coded as a function or subroutine called by Template:Requested move/dated to generate the "links" portion of that template. I've yet to take a deep-dive into learning more Lua coding to become more proficient with it, but a task like this, which I agree would be very helpful, motivates me more to do it. So if nobody else picks up the ball with this, it's on my radar, and I may get to it eventually. I'm juggling a lot of balls on Wikipedia. wbm1058 (talk) 13:34, 15 May 2019 (UTC)
Thanks for you reply, but I'm not sure you are correct. Requested move/dated produces the tmbox at the top of the move discussion. But it does not produce the list of pages beneath that box. And it is this list that I want to modify. — Martin (MSGJ · talk) 14:08, 15 May 2019 (UTC)
The list beneath the box is the permanent record of the request – anything written there remains after the move is closed. the tmbox holds the temporary part of the request (a move is closed, from the bot's view, when the tmbox is removed). As I don't think any "move" links should remain after a move is formally closed, the move links should all be inside the tmbox. A lot of multi-move requests are for just two pages, e.g. requests to change a primary topic. It shouldn't be hard to add links in the template for a second page into the tmbox to handle these. But the big requests to move more than two, sometimes a lot more than two pages, need some sort of programming to handle. Another approach would be to develop a (Javascript) tool to assist with these moves. All the information needed to produce the move links is contained inside the tmbox, for example:
{{requested move/dated|multiple=yes
|current1=2018 FIBA Europe Under-16 Championship|new1=2018 FIBA U16 European Championship|current2=2018 FIBA Europe Under-18 Championship|new2=2018 FIBA U18 European Championship|current3=2018 FIBA Europe Under-20 Championship|new3=2018 FIBA U20 European Championship|current4=2018 FIBA Europe Under-16 Championship for Women|new4=2018 FIBA U16 Women's European Championship|current5=2018 FIBA Under-18 Women's European Championship|new5=2018 FIBA U18 Women's European Championship|current6=2018 FIBA Europe Under-20 Championship for Women|new6=2018 FIBA U20 Women's European Championship|current7=2017 FIBA Europe Under-16 Championship|new7=2017 FIBA U16 European Championship|current8=2017 FIBA Europe Under-18 Championship|new8=2017 FIBA U18 European Championship|current9=2017 FIBA Europe Under-20 Championship|new9=2017 FIBA U20 European Championship|current10=2017 FIBA Under-16 Women's European Championship|new10=2017 FIBA U16 Women's European Championship|current11=2017 FIBA Europe Under-18 Championship for Women|new11=2017 FIBA U18 Women's European Championship|current12=2017 FIBA Europe Under-20 Championship for Women|new12=2017 FIBA U20 Women's European Championship|current13=2016 FIBA Europe Under-16 Championship|new13=2016 FIBA U16 European Championship|current14=2016 FIBA Europe Under-18 Championship|new14=2016 FIBA U18 European Championship|current15=2016 FIBA Europe Under-20 Championship|new15=2016 FIBA U20 European Championship|current16=2016 FIBA Europe Under-16 Championship for Women|new16=2016 FIBA U16 Women's European Championship|current17=2016 FIBA Europe Under-18 Championship for Women|new17=2016 FIBA U18 Women's European Championship|current18=2016 FIBA Europe Under-20 Championship for Women|new18=2016 FIBA U20 Women's European Championship|}}
Lua modules can use loop coding to check if |current18= and |new18= exist, but it's really a mess to try to hard-code that kind of test into a conventional template.
An issue with the current system design is that the list below the tmbox duplicates the data contained within the tmbox. If an editor decides to change the parameters of a request after-the-fact, they need to make changes in two places – both inside and outside of the tmbox. Often editors change parameters below the tmbox, while neglecting to make the necessary parallel changes inside the tmbox. A possible solution to this might be to only create the "permanent record" at the time the request is formally closed. It's a problem that's been on deep end of my to-do list for a long time. – wbm1058 (talk) 15:36, 15 May 2019 (UTC)
I take your point about the temporary/permanent record. But putting extra links in the box will effectively mean we are showing the list of articles twice when the discussion is open. I also agree that a fundamental rewrite may be in order, and offer the following suggestion. If {{Requested move/dated}} produced the list of articles as well as the tmbox, then when we close a discussion we could just change the /dated to some other subtemplate like /fulfilled, which would keep the list of articles but without the move links. — Martin (MSGJ · talk) 07:35, 16 May 2019 (UTC)
The other piece that may become part of the solution for this is {{Requested move/old}}. That template or its coding, could be part of the system that converted the temporary record to the permanent record at the time the move was closed. Still would need to be converted or partially converted to use Lua. Another consideration is how a move would be re-opened if an appeal was made to the closing admin or that was called for by a move review. Probably just by reverting to an earlier version of the page. wbm1058 (talk) 10:56, 16 May 2019 (UTC)
(Usually) unnecessary leading colon in wikilink for current title
Below the {{requested move/dated}} header, this template generates wikitext like: [[:Foo]] → {{no redirect|Bar}}
I've long been puzzled by that leading colon. After reading WP:COLONTRICK, I'm thinking it's there in the case of articles whose titles begin with a slash? But would it not be possible to conditionally add the colon only if the title actually does begin with a slash? Or are there other scenarios that this guards against?
Pretty trivial, I know, but I think it would be at least a tiny quality of life improvement to exclude it when it's not needed (i.e. the vast majority of cases). When I participated in RMs (before I investigated this), if I copied and pasted the article link from the top of the section, I would go back and remove the colon, just because I was vaguely concerned that using this spooky mysterious syntax feature might have some undesirable effect. Colin M (talk) 17:57, 11 July 2019 (UTC)
The colon is required not only for categories and pages starting with a slash but also for the File namespace. It doesn't affect the appearance, so introducing a code to check whether the colon is necessary seems way more complicated than it needs to be IMHO. Nardog (talk) 12:38, 24 July 2019 (UTC)
error message when dealing archives
I just previewed adding this:
{{subst:move|Talk:2011 Canadian federal election/Archive 1}}
But primary articles do not have archive sub-pages like talk pages do, so I want the move template to display despite the lack of that.
I understand the value of not moving talk pages to nonexistent articles, but we should have a workaround when it's an archive, to recognize the root page does exist. 174.92.134.245 (talk) 19:02, 2 December 2019 (UTC)
@174.92.134.245: It seems like this is a situation to request a technical move, as opposed to this being a controversial move. See WP:RM#TR. There is a different template for requesting a technical move. Looks like you are right that the template does not seem to work on talk pages, and that ought to be documented in the template documentation, but it would be a very rare satiation that the moving of a talk subpage would be controversial or contested. --Bsherr (talk) 13:37, 4 December 2019 (UTC)
Wbm1058 (talk) 00:30, 2 October 2014 (UTC)
Fixed Wbm1058 (talk) 22:09, 9 December 2014 (UTC)
Moved from Module talk:Requested move
Done. I just removed the overlink though. I decided not to boldface it. wbm1058 (talk) 18:56, 25 September 2017 (UTC)
