Wikipedia talk:Requested moves

This is an old revision of this page, as edited by Hhkohh (talk | contribs) at 06:23, 9 September 2018 (Proposal delay 48h after listing in WP:RM/TR). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Enter the title (or part of a title) to search for after "intitle:", then click "search"
Try other variants (e.g. "move discussion") to broaden or narrow your search

Effect on Page view statistics

I recently initiated two name changes (Brown-tail to Brown-tail moth and Actias luna to Luna moth). I noticed that in both cases there was a loss of prior history of page view statistics. Has this question come up before, and is there any way to resolve it? David notMD (talk) 10:29, 10 August 2018 (UTC)Reply

@David notMD: Page view data is not lost. It is simply not moved with the page. Page views are now split between Brown-tail and Brown-tail moth and Actias luna and Luna moth. — Frayæ (Talk/Spjall) 10:52, 10 August 2018 (UTC)Reply
Nice! For both moths, late spring/early summer peak in interest with the appearance of the winged moths: for Luna, for beauty, and for Brown-tail, for the annoying rash. David notMD (talk) 11:55, 10 August 2018 (UTC)Reply

Arguments to avoid page

Often, people just say "Support" or "Oppose" without giving any rationale whatsoever, such as at Talk:Giant panda#Requested move 15 August 2018. Also, sometimes, people give some vague comments at RMs such as at Talk:Lebanon national basketball team#Requested move 20 August 2018. I have asked for Tbhotch to elaborate his comment to be more specific. I thus propose that we shall create an "arguments to avoid" page for WP:RM at Wikipedia:Arguments to avoid in move discussions similar to the ones we already have for AfDs, deletion reviews, RfAs, etc. GeoffreyT2000 (talk) 01:20, 23 August 2018 (UTC)Reply

New move screen text

There is now quite a bit of additional text on the move screen in the middle of the important buttons, reading If you check this box, the associated talk page will be automatically moved to new title, unless a non-empty talk page already exists there. In this case, you will have to move or merge the page manually if desired. Does anyone know where this text is located, or who I can talk to about this change? 1) The "non-empty talk page" point is either imprecise or incorrect, depending upon one's perspective, so it really needs to be edited for clarity. 2) The talk pages should almost always be moved along with the page being moved, so if desired is not great wording either. 3) Minor point, but the box is checked by default, so "if you check this box" should just be "if this box is checked". Was there discussion of this addition somewhere? Dekimasuよ! 17:33, 24 August 2018 (UTC)Reply

I could not locate the text in the "Move page" box in the MediaWiki namespace, only the header through the "Note to admins and page movers". Dekimasuよ! 17:39, 24 August 2018 (UTC)Reply
Controlled by MediaWiki:Movepagetalktext. Assume was added on Thursday deploy.. Galobtter (pingó mió) 17:44, 24 August 2018 (UTC)Reply
Thanks. So there was something similar until 2015, until it was deleted by MSGJ with the summary: "deleted page MediaWiki:Movepagetalktext (G6: Housekeeping and routine (non-controversial) cleanup: not needed, see talk page)". At that time, it read:
This page has a talk page, which will be automatically moved along with it unless:
A non-empty talk page already exists under the new name, or
You uncheck the box below.
In those cases, you will have to move or merge the page manually if desired. Please request a page move on Wikipedia:Requested moves if you cannot do so, but please do not just copy and paste the contents, as doing that destroys the edit history of the page.
That was marginally better than what we've got now, if this is necessary at all. I note that "moved to new title" sounds strange as well. So there are still some issues: the checkbox is labeled "Move associated talk page", so I really don't think it's necessary to explain that "if you check this box, the associated talk page will be automatically moved" (there's also a logical contradiction here... if you have to check the box, it isn't really automatic). That leaves space for something like If there is edit history at the new location for the talk page other than a redirect to the current location, the talk page must be moved manually. Please be sure to preserve significant talk page history at the target when necessary. as the text. Dekimasuよ! 17:57, 24 August 2018 (UTC)Reply
May just want to remove the notice by creating a blank page there - the number of cases where this is an issue I think isn't much (or at-least I don't think I've ever experienced the issue), because if you can move the article, there either isn't a page at the target (and thus no talk page) or the target redirects toward the article you're moving, where most of the time the talk page will redirect similarly. Where there is a talk page blocking the move I think 99% the target page will have some edit (even rcats) blocking a move. Galobtter (pingó mió) 18:07, 24 August 2018 (UTC)Reply
Thanks for the perspective–as an admin, having to take care of the talk page is a frequent occurrence because usually we're performing moves that do require deletion of the target page (and that often would leave the talk behind, usually just because of an edit history showing various places the talk has redirected over time). But admins should know how to handle this already, so I agree with you that we may want to go back to removing the notice. Dekimasuよ! 18:32, 24 August 2018 (UTC)Reply
AAR people moving pages should generally know these things, and if they don't they should read Help:Moving a page which is linked in the header, but if we are trying to help streamline the process, the best way to go is to get the talk page out of the way first (G6, etc.) and then allow the interface to move the article and talk together "automatically". Dekimasuよ! 18:06, 24 August 2018 (UTC)Reply

THREEOUTCOMES and post move chalenges

The discussion at Talk:Bury#Requested move 11 August 2018 was closed as move after being relisted. However it has been challenged by editors who didn't participate in the discussion, is it usual to reopen the discussion or start a new one. @Amakuru: @Dekimasu: Crouch, Swale (talk) 07:35, 30 August 2018 (UTC)Reply

Proposal to start auto archiving WP:RMT page

Currently editors are simply deleting content from WP:RMT instead of marking as done and archive by bot. This is not normal. Pages like WP:RFPP and WP:PERM etc are archived for historical purposes. Hence I suggest the same should be done here as well. --DBigXray 11:15, 31 August 2018 (UTC)Reply

There is no justifiable reason for AIV to keep archive, the page history is as good as archive, thee is no back and forth discussion. please see my reply below.--DBigXray 15:47, 3 September 2018 (UTC)Reply
  • Oppose - seems like a solution looking for a problem. The two buttons (move and discuss), which are available on the RMT page always generate permalinks in the page history or on the talk page of the article concerned, (i.e. [1] for a move, and [2] for a discussion). This is far more useful than a general archive, since each case is attached to the actual article it concerns rather than a in a generic page.  — Amakuru (talk) 13:59, 3 September 2018 (UTC)Reply
  • Oppose like WP:CFDS, do not archive it Hhkohh (talk) 14:01, 3 September 2018 (UTC)Reply
hi Amakuru, Hhkohh, A user can directly place his move request on WP:RMT instead of posting on Article Talk page. (in fact when I needed such a move i posted on RMT directly) The reasons for move is added by the submitter. that line is useful to other page watchers who would like to know the reason for move. sometimes, the move although on the face of it may looks uncontroversial but later turn out to be in appropriate. In Other cases the request appears to be inappropriate on the face of it and there are further queries and replies by the Mover and the submitter to clarify the validity of the request. example [3] An Archive would help search the entry with time stamp and all. Searching in the page history is applicable to all the pages on wikipedia, yet we have archives. The reason is same. I am not sure as to how an archiving by a bot will be looking for problem ? --DBigXray 15:43, 3 September 2018 (UTC)Reply
But all the information you mention is available in a far more useful format through the permalinks, as I described. Listings on WP:RMT are usually one-liners detailing the proposed move, which are then either enacted or discussed. The entire content of that line is easily brought back any time someone wants it, from the article history or the talk page, by following that permalink. Here is an example of such a permalink: [4]. It serves the purpose of retrieving the listing. Hiving them all off into a separate archive page is completely pointless.  — Amakuru (talk) 15:52, 3 September 2018 (UTC)Reply
And how did you get this Permalink above ? Eg. Lets say I want to find out about RMT for Harchand Singh Longowal using the Page search history [5]. The search for Harchand Singh Longowal turns out irrelevant results. such a search would have been so easy with an Archive. A search for example [6] may also be tricky if i am looking for the thread. --DBigXray 16:05, 3 September 2018 (UTC)Reply
In answer to DBigXray's question, look in the history of Harchand Singh Longowal, where you will find this edit summary. In the summary, click on the 'Requested' link and it brings you to the WP:RMTR request. This convenient system of permalinks was mostly worked out by User:Wbm1058. EdJohnston (talk) 16:31, 3 September 2018 (UTC)Reply
Thanks Ed, this was helpful.--DBigXray 11:53, 4 September 2018 (UTC)Reply
Still no need to archive. If we archive WP:RMTR, so we also need to archive all uncontroversial moves, that is too complex, you can just see Move Log Hhkohh (talk) 21:36, 3 September 2018 (UTC)Reply

Proposal delay 48h after listing in WP:RM/TR

Currently, we can move immediately after someone listed in WP:RM/TR, sometime we cannot easily contest. So I suggest that we should change current policy to Request may take 48 hours to process after listing if there are no objections. in order to reduce move revert after an unconventional move like WP:CFDS Hhkohh (talk) 03:30, 9 September 2018 (UTC)Reply

  • Oppose. Reviewing admins/page movers already open an RM if the request is likely to be controversial. Anyone can request a revert to an undiscussed move, or open a formal RM, with minimal disruption to the project. Without a more thorough rationale, including specific examples of where the current system doesn't work, this appears to be a solution in search of a problem. Bradv 03:41, 9 September 2018 (UTC)Reply
  • Oppose Per above. If an editor finds an issue with a listed request after it's been filed, they can file an RM themselves. Requiring a 48 hour wait is simply going to clog up the requests at RMTR; see how many there are per day. -- AlexTW 03:45, 9 September 2018 (UTC)Reply
And? That's not a reason to create more delays and backlogs. We're trying to minimize those as it is. -- AlexTW 03:57, 9 September 2018 (UTC)Reply