Wikipedia

Wikipedia talk:Page mover/Archive 4

< Wikipedia talk:Page mover
Latest comment: 1 year ago by Jessamyn in topic Why am I not seeing "suppress redirect" checkbox?
Archive 1Archive 2Archive 3Archive 4Archive 5

Talk page redirects

Latest comment: 5 years ago49 comments13 people in discussion

There have been (at least) two recent moves in which a page mover has suppressed redirect creation and the result has been that valid talk page links have become redlinks.

See User talk:Iffy#Move of Capitol Limited (Amtrak train) for the first of these that I noticed, and the discussion that followed.

More recently, Talk:Phenomenological sociology has become a redlink following this move: 

21:30, 17 October 2018‎ Dreamy Jazz (talk | contribs | block)‎ m . . (10,164 bytes) (0)‎ . . (Dreamy Jazz moved page Talk:Phenomenological sociology to Talk:Phenomenology (sociology) without leaving a redirect: Move per WP:RM discussion on the talk page)

I think that the documentation on this page needs an update in order to make it clear that such redlinks need to be tidied up after a move. Andrewa (talk) 22:44, 17 October 2018 (UTC)

The truth is, nobody cares. I consider myself a particularly anal diligent mover, but talk page redlinks are pretty high on my "least concerns" list; I usually bother to resolve self-links, but I'm completely oblivious to redlinks. We have the duty to the mainspace, and it sometimes gets real hard work to redirect or disambiguate incoming links, but talk space is really not of immediate concern. No such user (talk) 21:05, 25 October 2018 (UTC)
You appear to be right. But the practice and policy do not match, and should... otherwise, why have the policy? Andrewa (talk) 01:21, 8 November 2018 (UTC)
I personally think it's a page mover's responsibility to do proper clean up after a page move. We have a whole detailed section on what needs to be done. I don't believe we can expect all page movers to know all the trivia here, (for example, moving, or requesting to move, editnotices that would have been attached to previous titles), but some basic actions like correcting talk page redirects, checking subpages, creating newly red-linked talk pages (especially with incoming links) is standard imo. — Andy W. (talk) 18:22, 20 December 2018 (UTC)

Another case

17:28, 4 November 2018‎ Flooded with them hundreds (talk | contribs | block)‎ m . . (12,254 bytes) (0)‎ . . (Flooded with them hundreds moved page Talk:AdWords to Talk:Google Ads without leaving a redirect: discussion at Talk:Google Ads/Archives/2018#Requested_move_08_October_2018)

More than 30 pages currently link to the now nonexistent talk page Talk:AdWords, including for example this recent contribution which is what brought it to my attention. And there may also be incoming external links of course, which we can neither change or even for the most part detect.

And again it was a round-robin move:

I think we need to fix this. Andrewa (talk) 01:21, 8 November 2018 (UTC)

  • Page movers suppressing redirects that should not be suppressed should be cause for removal of the pagemover right. --SmokeyJoe (talk) 01:28, 8 November 2018 (UTC)
    • Agree but this is not that simple. The suppression is valid in order to do the round-robin move. The problem is, the process should then be to restore the talk page redirect, not just the article space redirect. And the documentation doesn't say this... or, perhaps commonsense indicates that it does, but the letter of the instructions isn't clear on this, and as we've seen above, there's not even a consensus here that the talk page redirect should be restored. Andrewa (talk) 05:17, 8 November 2018 (UTC)
      • People requesting advanced permissions should carry the onus of responsibility in using it. If consensus is lacking, don’t use the advanced permission. —SmokeyJoe (talk) 02:47, 10 November 2018 (UTC)
        • Agree. But it's a bit unfair to expect them to follow commonsense and preserve talk page links when the procedures don't require it, and we don't even have consensus that it's the right thing to do. I'm working here on building that consensus. It is the right thing to do, and we waste everyone's time by not documenting that in the procedures. Andrewa (talk) 12:00, 18 December 2018 (UTC)
  • This is a side effect of the page swapping script, which does not automatically modify the redirect, so editors usually correct the mainspace redirect manually, but sometimes neglect to do the same for the talk page redirect, which now points to itself. That is bad form by page movers, but honestly they may be fooled by the apparent simplicity of executing a script-assisted swap. Perhaps that tool could be made a little smarter? @Andy M. Wang: can you help? — JFG talk 20:23, 20 December 2018 (UTC)
    • @JFG: As I've already pointed out here and here, here, here, here, etc, the script is just a move-assisting tool, and wasn't designed to correct, or edit, mainspace/talk/subpage redirects. The intent was to alleviate the need to issue 3 Special:MovePage requests, but step 4 and the potentially massive post-move cleanup yielded too many nuances and corner cases to consider at the time the tool was made. I'm now looking back at the tool and am unimpressed and think that if I were to consider feature suggestions, I'd want to do a bit of an overhaul in the design itself. I do think it's a good habit (and responsible) to do "Step 4" and "post-move cleanup" — Andy W. (talk) 20:48, 20 December 2018 (UTC)
A generalized post-move cleanup would certainly be out of scope and too complex to automate; the burden is clearly on page movers to examine in detail what needs to be fixed. However, the most common case requiring the page swap tool does leave a redirect to self, and I have a feeling this could be corrected automatically without much fuss. Happy to discuss further, and possibly help with the MVP specs, if you feel like giving it a try. — JFG talk 21:06, 20 December 2018 (UTC)
Not asking for help for now, but just putting some cases out there: if one swaps A with B. Should a self-redirect at either A or B be corrected? If, post-move, A redirects to A, but Talk:B redirects to Talk:B, what should the script do then? Should it correct the mainspace or talk? Or should it point A to B and Talk:B to Talk:A? Or, if A redirects to A, Talk:A redirects to Talk:A, but Talk:A/sub doesn't redirect, and Talk:B/sub2 redirects to Talk:B/sub2, what gets corrected then? Does the tool account for the potentially several dozen subpage redirects or self-redirects? Maybe the MVP is just to correct mainspace, but there are reasonable counter-arguments as soon as redirect correction/creation come into play.... I'll try to think this over... real-life says I probably can't in a reasonable amount of time (I'm not really that quick). With due respect to all page movers, I think the burden to check for self-redirects is on them for now. I'm totally okay if someone else wanted to look into some basic handling and improve the tool separately — Andy W. (talk) 21:36, 20 December 2018 (UTC)
Is there a talk page for your script where we could move this conversation? — JFG talk 21:41, 20 December 2018 (UTC)

Just a thought

Regarding the deletion of talk page redirects as a result of round-robin moves: I know this isn’t documented, but whenever I perform a round-robin move that results in a talk page redirect being deleted, I recreate the page as a redirect to its new talk page target and tag it as {{R from move}}. What Andrewa states above does happen, and I do care and think that it is common sense, so I do this to fix any possible damage. Steel1943 (talk) 17:15, 17 December 2018 (UTC)

Thanks Steel1943. That is IMO of course the correct course of action exactly, and IMO that should be uncontroversial... as you say, to me it is pure common sense. But evidently not so common, and so sometimes it's not being done, and when I ask why not I'm told (correctly) that the procedures don't require it. So at the risk of instruction creep I think we need to document it as a requirement. Andrewa (talk) 21:00, 17 December 2018 (UTC)
@Andrewa: I think that’s probably a good course of action at this point. It may need a discussion though since it seems actually doing it is controversial; but then again, that’s what this section is here for, so I’m 50/50 on which course of action to take. Steel1943 (talk) 15:11, 18 December 2018 (UTC)
It's common practice to create redirects from redlinks after completing a round-robin move, and the script that most of use for this purpose already instructs the user to check their contributions for redlinks after performing the move. I'm sure this is an oversight on the part of the movers. Regardless, the redlinks can easily be created by any other editor who comes along, so it's no big deal.
If any other page movers are reading this section, consider this a reminder to properly clean up your round-robin moves. Bradv🍁 15:50, 18 December 2018 (UTC)
It is common practice, but it's not universal, and it's not even universally agreed that it is the right thing to do... not sure I can be bothered finding the diffs of page movers who have protested to me that they have followed the swap procedure and have no intention of ever going to the trouble of fixing the broken redirect. But there have now been several. Yes, it's easily fixed, just as soon as someone who knows how to fix it (and cares enough to do so) notices the redlink, but meantime links are needlessly broken. I think we have consensus here that it should not be necessary for someone else to fix them. Andrewa (talk) 20:02, 18 December 2018 (UTC)
Andrewa, I would say that's an accurate summary of existing consensus, and I would point anyone who fails to clean up after their round-robin moves to the instructions at WP:ROBIN. Bradv🍁 20:09, 18 December 2018 (UTC)
OK, just to clarify... I've given above two examples of page movers not IMO cleaning up adequately. Are you saying that one or both of these clearly violated WP:ROBIN? If they both did then you're right, no need to modify the instructions, and I might even gently take it up on the talk pages of the page movers involved to avoid any repetitions. Andrewa (talk) 14:31, 19 December 2018 (UTC)
Andrewa, yes, both of the moves you listed above were round-robin moves, and the talk page redirects should have been created as part of the cleanup. I wouldn't say "violated", as the cleanup procedures are not policy, but yes, the page movers missed this. Bradv🍁 15:06, 19 December 2018 (UTC)
Yes, I guess that is a bit strong, and violates the spirit and letter of wp:NPA as it was originally intended (but that was long ago). But someone should gently bring it to the attention of the page movers involved, don't you think? Andrewa (talk) 21:05, 19 December 2018 (UTC)
Including the recreation of the talk page redirect in the script (ping Andy M. Wang) would probably fix the issue. Though, TBH, it has never been much of a problem for me to recreate the redirect and I always do so. Galobtter (pingó mió) 16:59, 18 December 2018 (UTC)
Andy is now less active, may not respond here. Automatic recreation of the redirects was intentionally not included because of potential drawbacks, see this talkpage archives 1, 2. It's quite easier for human to figure out correctly where the redirect should go. May be because I usually do it, I don't see this as an issue, and a bit surprised it's being discussed. –Ammarpad (talk) 04:45, 19 December 2018 (UTC)
It could be an checkbox option when performing the move, though I do know there are more complex cases where one doesn't want to create the redirect. Galobtter (pingó mió) 04:49, 19 December 2018 (UTC)
  • Another alternative is to not use page swaps in the first place. In the majority of cases these aren't really needed: if you can think of a plausible redirect that doesn't exist yet then it's simpler to use that as the destination of the blocking redirect: the sequences of moves B -> C, A -> B is simpler than the page swap process B -> X, A -> B, X -> A. – Uanfala (talk) 18:03, 18 December 2018 (UTC)
    • ...Which is impossible for a page mover to do in cases where "C" already exists if it is not targeting "B" already and/or has more than one edit in its history. This problem comes up frequently with disambiguation pages since their only community-accepted titles are either the ambiguous title or the ambiguous title (disambiguation). Steel1943 (talk) 04:19, 19 December 2018 (UTC)
      • But that's not the scenario. The scenario is that C does not exist; It's the plausible redirect that doesn't already exist, and is created in this process, also preserving the page history of one of the two pages. Neat. Or am I missing something?
      • And it's not generally true of disambiguation pages that their only community-accepted titles are either the ambiguous title or the ambiguous title (disambiguation). See yesterday (song)f or example. Or again, am I missing something? Andrewa (talk) 06:23, 19 December 2018 (UTC)
        • @Andrewa: Yesterday (song) is a {{R from incomplete disambiguation}} redirect that tells our readers that the disambiguator "(song)" is ambiguous and could refer to multiple existing Wikipedia subjects; it wouldn’t be the name of the disambiguation page itself. Steel1943 (talk) 12:21, 19 December 2018 (UTC)
          • All true, but we seem to be at cross purposes. The point is just that it's a plausible redirect and if it didn't exist it could provide an alternative to the relative complexity of a round-robin move. Andrewa (talk) 14:31, 19 December 2018 (UTC)
            • Right, and I understand that and even take such action myself in the event of moving edit histories. And I was stating that this will not always be an option. For this I think we are both agreeing about the same thing at this point. However, for what you are saying for this part: I do not believe that trying I avoid round-robin moves in this manner should be enforced since that would also require that the page mover be familiar with useful redirect titles that would basically be able to survive a WP:RFD without page history, which is currently not a requirement for getting the page mover right and in my opinion shouldn’t be. Now that ... I would call unnecessary instruction creep. Steel1943 (talk) 20:34, 19 December 2018 (UTC)
        • ... And I’m saying there will not always be cases where there is a valid nonexistent "C" to move the edit history, given that moving edit history to a title that is not a useful search term as a redirect is, in my opinion, problematic and creates a new problem after solving another. Steel1943 (talk) 12:28, 19 December 2018 (UTC)
          • Agree that there will not always be cases where there is a valid nonexistent "C" to move the edit history and that moving edit history to a title that is not a useful search term as a redirect is... problematic.... All I am saying is, if such a term does exist (and that means it is a useful search term, otherwise it's not a plausible redirect at all), then this seems a very neat alternative to a round robin, and creates no new problem at all. I'm not sure how common these scenarios will be, and think that we should wait for a concrete example before deciding that. Andrewa (talk) 14:31, 19 December 2018 (UTC)
            • (I think I may have also answered this in my other response during this edit, but if I did not, please point it out to me as I’m not sure how to respond to this inquiry separately.) Steel1943 (talk) 20:34, 19 December 2018 (UTC)
            • The only new problem that I would see is that non-admin page moves are supposed to be easily reversible in the case of misuse, and the original page histories easy to locate. If a requested move discussion requested that two pages swap locations (for example, swapping a primary topic with a disambiguation page), then it's expected that the histories of both of those pages will be in those locations, rather than in some third location. The round-robin procedure makes that straightforward, and a reversal of the round-robin consists of exactly the same steps in the same order. Bradv🍁 20:37, 19 December 2018 (UTC)
              • Agree. But you and I see any broken link, even a talk page link, as important. I'm afraid many do not! See above and many other discussions, and maybe even User:Andrewa/Incoming links. Andrewa (talk) 21:00, 19 December 2018 (UTC)
              • I'm a bit lost now. Could someone give an example of a situation where a page swap is the actual intended outcome of an RM? If it's dab page vs. primary topic scenarios, I can only think of two at the moment: either Foo -> Foo (disambiguation) and Foo (bar) -> Foo, or Foo -> Foo (bar) and Foo (disambiguation) -> Foo. – Uanfala (talk) 22:15, 19 December 2018 (UTC)
                • @Uanfala: As far as I’ve seen, there is never a reason to swap two pages with content (neither one are redirects.) However, a few hours ago, I closed a move discussion and performed a move that requested moving a page with content to a title that was blocked by a redirect with more than one edit, and had to perform a round-robin move: Talk:Apostolic administration#Requested move 29 November 2018. (I think you are referring to the first sentence of my statement, but I’m providing an example of a round-robin move just in case.) Steel1943 (talk) 22:42, 19 December 2018 (UTC)
                • There may be scenarios in which content needs to be swapped but they are rare. What is common however is needing to move a page where both the new and old page titles each have significant page history that relates to the content of one of them. All of this history needs to be preserved (and presumably, reasonably and logically accessible) under our copyleft requirements. Any talk page contents are best kept with the page to which they refer, obviously, and we don't want to break links (and again would in some circumstances break our copyleft obligations if we were to do so, notably if there's been page merge or split activity in the past). It's a rather subtle requirement in some ways, and perhaps page movers should not be doing it at all. Andrewa (talk) 03:17, 20 December 2018 (UTC)

Another and not a round robin this time

I'm not quite sure how this happened, but I have just recreated Talk:Spiral Scratch (EP) thus restoring four broken wikilinks and any (undetectable) incoming external links. And again the closer was a non-admin page mover. Andrewa (talk) 23:56, 26 December 2018 (UTC)

Bot

I think it's best to just have a bot that recreates these talk pages according to the accompanying main page. Because a lot of the times, especially if a page mover is doing a batch move, it's just messy and that's besides tedious. --QEDK (後 ☕ 桜) 18:03, 27 December 2018 (UTC)

A bot could work. PageSwap can be a pain but it's the best way to do it, I'm not sure why it deletes the "source" talk pages but anything to remove a step from the cleanup would be appreciated! SITH (talk) 14:34, 29 December 2018 (UTC)
Since we want to swap the talk pages as well, it takes the history of the new talk redirect (none) with the one we want to swap (the talk to be moved), essentially deleting it. The pageswap tool could potentially also include a feature to redirect the swapped pages automatically after it's done but the tool creator is not active as of now, so a new maintainer could possibly achieve the same, I'll put a VPT thread. I'll tag @Andy M. Wang: for now. --QEDK (後 ☕ 桜) 16:41, 29 December 2018 (UTC)
QEDK, good idea, see my proposal for script modification below SITH (talk) 18:18, 14 January 2019 (UTC)
@StraussInTheHouse: Just for reference to future readers of this thread, my fork of PageSwap does prompt to create talk redirects in these situations. --Ahecht (TALK
PAGE) 19:26, 16 October 2019 (UTC)

A case of unnecessary round robin

I did a round robin because the target page already existed I couldn't move over it, even if the history was insignificant. I use the PageSwap script for moves which have extant targets and its default setting is a round robin move.

It is agreed I think that in this case there was no need to preserve the page history (in fact IMO it would even have been better not to in this particular case). See User talk:StraussInTheHouse#Akhil Bharatiya Hindu Mahasabha for the discussion if curious, but my point here is just that perhaps it would be good to give page movers better tools and/or instructions. And if we did, maybe the other (perceived?) problem(s?) would just go away. Andrewa (talk) 17:09, 29 December 2018 (UTC)

Andrewa, I've just finished closing a mammoth RM where most of them required pageswap (link). I wouldn't mind so much if the script didn't either delete the talk page redirect or just leave both the page and the talk page as redirects to themselves. Surely there's a way to amend the script to pull out the variable of "target page" and make it edit the original page and its talk page to make the post move cleanup less of a hassle? I mean, we can archive talk pages with one click so it can't be too difficult to do this. Otherwise, admins could just delete the insignificant redirects to make way for a move but that would be as easy because page movers would be constantly needing help. SITH (talk) 18:17, 14 January 2019 (UTC)

Issue with Move to Draft

Latest comment: 5 years ago4 comments3 people in discussion

Hi. At some point today, the "move to draft" option on my TW drop down menu went away. And apparently this is happening to other editor as well. Anyone know what is going on? Onel5969 TT me 23:12, 21 October 2019 (UTC)

It's still there for me onel5969, so unsure — IVORK Talk 00:42, 22 October 2019 (UTC)
@Onel5969: It was gone, now the script was fixed DannyS712 (talk) 01:57, 22 October 2019 (UTC)
Thanks.Onel5969 TT me 02:18, 22 October 2019 (UTC)

RfC: Should Page Movers be permitted to move move-protected pages?

Latest comment: 5 years ago62 comments26 people in discussion
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Withdrawn due to heavy downfall of snow — IVORK Talk 01:01, 7 November 2019 (UTC)

Howdy fellow Wikipedians, thought to float the idea of page-movers getting access to move WP:GREENLOCKed pages.
Just to make the process easier with WP:RM/WP:RM/TR and the likes. In my opinion it seems a logical inclusion to the permission, with the 6mo/3000edit requirements and only ~291 of us mere mortals, I don't see this as being particularly risky. — IVORK Discuss 23:36, 15 October 2019 (UTC)

Survey

  • Support in principle, but one solution would be for admins to stop regularly using indefinite full move protection (and for all current indefinite full move protections to be reviewed and changed to either indefinite ECP, time limited full protection or unprotected altogether), when this practice is already strongly discouraged for edit protection. Iffy★Chat -- 12:26, 16 October 2019 (UTC) Update: I'd also support Hut 8.5's alternative proposal. Iffy★Chat -- 10:32, 17 October 2019 (UTC)
    There are some cases where indefinite and strong protection is a good idea; for example, when it comes to high-use templates, the move protection is typically at least templateeditor and above. Sceptre (talk) 18:05, 16 October 2019 (UTC)
    I was primarily thinking of articles (not templates) when I suggested that admins stop using indefinite full move protection. Iffy★Chat -- 10:32, 17 October 2019 (UTC)
  • Support; as I've mentioned in the below section, it's something that would make sense to have and be nice to have. It's not urgent, but it would allow for page movers to work through the backlog a lot easier. My preference for the technical aspect would be by splitting the editprotected right into editprotected and moveprotected. Sceptre (talk) 19:05, 16 October 2019 (UTC)
  • I'd be happier with creating a new protected level of "admins and pagemovers only" and using that as the standard for preventing page move vandalism. I strongly suspect there will be some cases where we do want to prevent non-admins from moving a page. Hut 8.5 21:47, 16 October 2019 (UTC)
  • Support as nom? Hut 8.5 That is fair, but I feel that the majority of those cases would also have full edit-protect on. Additionally page movers would still be required to only make changes they deem uncontroversial/that reached consensus. Per below, the intent is that anything not full-edit protected but full-move protected would automatically become "admins and pagemovers only" if this is successful. — IVORK Discuss 04:00, 17 October 2019 (UTC)
  • Conditional Support I still have similar concerns as during the RfC that created the page mover right. Assuming that the technical and overhead concerns can be dealt with I support otherwise oppose. While a new level made sense for TE, I don't think it is the right solution for page mover as the amount of work from handling the new levels seems like it would override the amount saved by not having to ask admins to assist when moving a protected page. I also worry about accidentally protecting pages during moves that might not be easily reversible by the page mover. Any solution should not make it easy for a page mover to back themselves into a corner that they need admin assistance to undo. See also Overriding sysop move protection from the same RfC. Unless these concerns can be addressed though consider this an oppose but only for technical reasons. PaleAqua (talk) 04:17, 17 October 2019 (UTC)
  • Oppose as proposed but support Hut 8.5's suggestion about a new lower level of move protection. - Tom | Thomas.W talk 09:21, 17 October 2019 (UTC)
  • Oppose as proposed for lack of technical feasibility. Neutral on the lower level of protection proposed above. * Pppery * it has begun... 11:43, 17 October 2019 (UTC)
  • Oppose as proposed. There is no way to determine which pages the protecting admin thought okay for page movers to move and which not. Adding a new lower protection level as Hut 8.5 suggests would be okay, because then it would only apply to newly protected pages and thus be clearly what the protecting admin wanted. That said, is this really something that happens sufficiently often that we need more people able to do it (and possibly create a new protection level)? Regards SoWhy 13:37, 17 October 2019 (UTC)
  • Oppose. "only ~291" page movers? That's not a small number, it's about the number of successful requests for adminship in the last ten years. Round-robin moves are an inferior kluge, something the community reluctantly settled on due to the shortage of administrators. Page-movers shouldn't be viewed as permanent second-class administrators; rather this position should be a stepping stone. Any page mover with a decent track record (minimum questioning of your closes) should make the step up and please, run for administrator. We should stilll have enough admins to deal with complex and controversial moves, including from protected pages. – wbm1058 (talk) 22:38, 17 October 2019 (UTC)
  • Oppose No reason to give essentially bureaucrats (appointed by admins) permission to deal with pages restricted to users trusted by the community. If a page is full protected, the admins should already have noticed the problem. From AnUnnamedUser (open talk page) 23:25, 17 October 2019 (UTC)
  • Oppose. A permission granted based on the discretion of one administrator should not be allowed to deal with fully-protected page titles. I know I myself am a non-admin page mover and would benefit from this provision, but I've seen too many cases of users making major mistakes after being granted the page mover right, and also that the right may be granted too leniently. For example, sockpuppet account Frayae was once granted this right. feminist (talk) 02:50, 18 October 2019 (UTC)
  • Oppose This seems too much like partial-adminning, which doesn't work; to paraphrase the section of PEREN, if an editor can't be trusted with a fully-protected page (as evidenced by their being an admin), they shouldn't be changing it, period. Having said that, I would support Hut 8.5's proposal. – John M Wolfson (talk • contribs) 05:19, 18 October 2019 (UTC)
  • Oppose – I really think that anyone who consistently runs into this problem should consider running for adminship. We always need more admins, and experienced page movers tend to do well at RfA. With respect to the move-protected pages, I suspect most of those could have their protection lowered, especially the ones which aren't edit-protected. – bradv🍁 01:37, 20 October 2019 (UTC)
    +1 Steel1943 (talk) 17:09, 29 October 2019 (UTC)
    Steel1943 and Bradv, don't you think there are likely many non-admins who could be trusted with this user right but couldn't pass RfA? --valereee (talk) 13:51, 30 October 2019 (UTC)
    I'm not sure what this question is attempting to accomplish: There's always a chance of that happening since passing RFAs is never 100% guaranteed even with the best odds. Steel1943 (talk) 16:42, 30 October 2019 (UTC)
  • Oppose. On those extremely rare situations where a pagemover wants to move a fully moved-protected page, they can ask for assistance. Notwithstanding the report that Danny712 has generated below, there are only a tiny number of pages in Article and Article talk space that are fully move protected. There are only about 2500 protected pages in article/article talk space that are fully move protected, and almost every one of them would warrant a full and proper discussion before contemplating a move. I don't see any good rationale for pagemovers to move the fully move protected pages outside of mainspace; a lot of them are in userspace, and many are "special" pages for which there is almost no reasonably foreseeable reason to move them. It is possible to consider dropping the move protection down to "extended confirmed user" level for many of the article space pages, but realistically these are pages that aren't going to be moved. Risker (talk) 04:30, 20 October 2019 (UTC)
  • This seems to be a solution in search of a problem. If feasible, protection should be lowered, which also requires administrator eyes. If lowering protection isn't feasible, then having an administrator close the discussion is probably advisable in most cases. Not because page movers would be unqualified, but because of WP:NACPIT/WP:BADNAC (e.g. "The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial"). Dekimasuよ! 09:28, 20 October 2019 (UTC)
  • OpposeI'm unconvinced there's a problem here that needs solving, and I also oppose yet another kind of protection. In my opinion we already have to many kinds of protection and too many levels of user rights, we should only be adding more when there is a demonstrable, serious problem that can't be resolved with the current tools at our disposal. Beeblebrox (talk) 20:14, 23 October 2019 (UTC)
  • Oppose per Beeblebrox. This is a solution in search of a problem. Kudpung กุดผึ้ง (talk) 00:05, 26 October 2019 (UTC)
  • Oppose proposal for new level of protection since that seems like unnecessary bureaucracy and is unlikely to get wide enough use for it to be useful, unlike template protection. Neutral on the original proposal. Steel1943 (talk) 17:08, 29 October 2019 (UTC)

Non-Technical Discussion

  • @IVORK: Question on goal: if a page is edit-protected past the current users ability to edit, and fully page-protected, would you be thinking "page movers" should still be able to move it? — xaosflux Talk 20:00, 16 October 2019 (UTC)
    @Xaosflux: (this is technical, but) MovePage::checkPermissions requires that the user be able to edit both the source and target for them to be able to move the page; this would allow protection of (in the form of edit/move): 'none/moveprotected', 'semi/moveprotected', 'ecp/moveprotected', or 'template/moveprotected' (though its unlikely that a page would be template-protected for editing but moveprotected (or whatever the new level is) for moving. DannyS712 (talk) 01:31, 17 October 2019 (UTC)
    I feel it is fine working within the above restriction as it exists. EC or Template edit protected max depending what the mover has. — IVORK Discuss 03:43, 17 October 2019 (UTC)
  • Is this a real problem? I honestly have no idea, are there regular RM backlogs due to move protection? Beeblebrox (talk) 23:27, 16 October 2019 (UTC)
    At the moment, most of the closures at RM seem to be done by non-admin page movers. Sometimes, RMs come from move-warring and act as an ersatz dispute resolution, so those pages are often move-protected as a result of move-warring. Sceptre (talk) 00:54, 17 October 2019 (UTC)
    So if the dispute is settled, shouldn't the protection get lifted? — xaosflux Talk 01:44, 17 October 2019 (UTC)
    While that is ideal, it is often not the case, e.g. recent cases like this. While the page may still need protection so auto-confirmed can't just push their wishes, it would allow for it to be moved without hassle only once a consensus has been achieved. Ultimately it would only lessen the tasks sysops need to do if it passes. And as others have said below, not an urgent task, but something that seems logical to a few of us here. — IVORK Discuss 03:43, 17 October 2019 (UTC)
  • Use case: There are currently (05:22, 17 October 2019 (UTC)) 9248 pages that are fully protected for moving, but not for editing. See table at Special:Permalink/921678062 - gives full move protection expiry, namespace, title, if it is a redirect, the edit protection level, and the edit protection expiry. I count just over 2300 pages in the main namespace (articles). Hope this helps --DannyS712 (talk) 05:22, 17 October 2019 (UTC)
    @DannyS712: thanks for the dump - sounds like a good place to have an admin cleanup drive to remove no longer needed full protections. — xaosflux Talk 11:39, 17 October 2019 (UTC)
  • @IVORK: as far as I can tell this change would effectively allow page movers to replace a fully protected page with new content: they could move it to a new title, suppress the redirect, and then recreate the page with something else. Not being able to edit the original page wouldn't help because everybody looking for the page would see the recreated version and not the original. For sensitive pages (such as highly used templates) this could be a serious concern. I'm sure page movers can be trusted to abide by consensus but that doesn't necessarily help if, say, someone's account is compromised. Hut 8.5 17:41, 17 October 2019 (UTC)
@Hut 8.5: There has been discussion either way on the possibilities, I was basing it off the fact that implementing something like this would only enable page movers to ignore move perms and not be able to move if the page is edit-protected to a level above them, be it template or sysop. If this cannot be achieved then I definitely see that this issue could cause more issues that it would fix. — IVORK Discuss 00:10, 18 October 2019 (UTC)

Technical discussion

  • I'm not sure this is technically possible? It's my understanding from mw:Manual:User_rights#List_of_permissions that in order to move a page, one must have the ability to edit a page, and so we would have to give pagemovers the ability to edit full protected pages if we wanted to allow them to move greenlocked pages. @Xaosflux: do you know more about this? Wug·a·po·des​ 00:32, 16 October 2019 (UTC)
    @Wugapodes: so not quite - we certainly can have pages that are editable but not movable, which is the special condition that I assume IVORK is presenting here. From Special:ProtectedPages, User talk:Fuzheado is an example right on top of the list. There is no permission that exists that can be assigned to groups that would enable this without also enabling editing of protected pages (it is in "protect"). As this is such a niche case, I can't see mediawiki developers spending time to work on it (it being the entire system that checks permissions during moves) either. Practically, this would create new situation that may need to be dealt with: If Page xxx is move only protected, but needs to be moved anyway - why? Should it just be unprotected? If not, what is the expectation, that the resultant page would still be move protected? What about the prior name, is it just a normal page now? Are there some practical examples of when these moves are needed, and what the expecting results would be? — xaosflux Talk 00:44, 16 October 2019 (UTC)
    There's a bunch of requested moves right now that rely on WP:NCC, and a good few of those are move-protected (Hawkeye (comics) (edit | talk | history | protect | delete | links | watch | logs | views) → Hawkeye (Clint Barton) (edit | talk | history | protect | delete | links | watch | logs | views)). Like the option to move articles over existing articles without a round-robin, it's something that would make sense for page movers to have and would indeed be nice to have, but it's something that isn't urgent to have. Personally, I'm much more concerned with the side-effect of RCAT being that moves over redirects have to be done via round robin. Sceptre (talk) 02:16, 16 October 2019 (UTC)
    @Sceptre: so for your example at Hawkeye (comics), the move protection has been in place for 6 years, supposedly per Wikipedia_talk:WikiProject_Comics/Archive_46#Marvel_Heroes_-_Voice_Actors. Is this protection really even needed anymore? We should be removing protection that isn't actively needed. As far as the question I had above, what would you expect the end result of this will be? Should anything still be protected? — xaosflux Talk 02:43, 16 October 2019 (UTC)
    Like I said, it's a thing that I think would make sense to have, but isn't an urgent thing to address, IMO. There are some pages – mostly templates – that should be move-protected because they're in high use, but there can be a consensus to move them at some point and technical restrictions make backlog maintenance difficult; {{Infobox hurricane}} is another example from today. For what it's worth, as someone who keeps an eye on edit protected requests (i.e. template/semi/500-30), indefinite full protections makes WP:RCAT-work more annoying than it should be, and, philosophically, is an argument for devolving more of the admin suite, but that's beside the topic. Sceptre (talk) 02:56, 16 October 2019 (UTC)
    @Sceptre: so I'm still a bit lost, so let's assume that Template:Infobox hurricane was able to be moved right now by "page movers" (via an imaginary permission that overrides full-move-protection), after the moving was done which pages should still have which protections applied at the end of the work? — xaosflux Talk 03:19, 16 October 2019 (UTC)
    Oh, in that case: the same as would happen if an admin were to move the article; basically, it would be splitting editprotected into two rights, editprotected and moveprotected. Sceptre (talk) 03:36, 16 October 2019 (UTC)
    @Sceptre: ideally, what would happen is an admin would review the protection levels and decide if they are still warranted then adjust or remove the protection levels as appropriate. The default is to "move the protection" with the page, but the protection policy says we should only protect pages that have a reason to be protected. — xaosflux Talk 11:04, 16 October 2019 (UTC)
  • like Xaosflux is saying, there are too many technical things here to be discussed/thought about. Like what happens to the newly moved page, would it still remain move protected? The logical solution is to keep it protected. What happens to the leftover redirect?
    In the past, I've come across a few pages that I had to move, but couldn't. Most of them were from RM. I can't recall any of their names, but currently, assassination of JFK is editable, but move protected. I had also thought the same. But in practice, instances of moving the move-protected pages are very low. And after all, the protection is/was placed there for a reason. I think it is better to contact an admin or RM/TM rather than making changes in the software. —usernamekiran(talk) 03:48, 16 October 2019 (UTC)
  • @Xaosflux and Sceptre: (edit conflict) As for whether this is possible:
    1. create a new protection level, eg moveprotected
    2. Grant the moveprotected right to administrators and page movers
    3. When admins protect pages, rather than, eg semi-protection for editing but full protection for moving (or template/full, etc) protect with autoconfirmed for editing (semi-protected) and moveprotected for moving
    While the protection options would exist for both editing and moving, it should be clear that administrators should not use moveprotected for editing protection. If this RfC passes, I can add a patch on gerrit (its literally 3 lines of code, and 14 lines of new system messages, that are changed). Hope this helps --DannyS712 (talk) 03:50, 16 October 2019 (UTC)
    Creating an entire new protection level just for this small edge condition seems like bad idea for me, and requires that all administrator comply with a new process and re-review every existing protection. Overall, I think creating new permissions for moveprotected and editprotected are a good idea though, but have them work with the existing protection levels. — xaosflux Talk 10:59, 16 October 2019 (UTC)
  • Question would page-movers be able to move-protected pages that have also have higher protections on them, like template protection, without having access to those rights? Headbomb {t · c · p · b} 18:28, 16 October 2019 (UTC)
    @Headbomb: No. If either the current "editprotected" is split into "editprotected" and "moveprotected", or a new protection level is added, page movers will only be able to move pages that are fully protected (first option) or specifically have a move protection of "moveprotected" (second option) --DannyS712 (talk) 18:44, 16 October 2019 (UTC)
  • Technical question (xaosflux?), when you move protected pages, don't the protection settings get replicated? –xenotalk 18:30, 16 October 2019 (UTC)
    @Xeno: when you move a page, current protection and pending-changes protections are moved to the destination page. — xaosflux Talk 18:38, 16 October 2019 (UTC)
    The redirect left behind is unprotected? –xenotalk 18:40, 16 October 2019 (UTC)
    From a non-technical perspective, when a fully protected page is being moved, it is certainly a good time to review and make any protection adjustments appropriate on the new page, and/or the old title/redirect. — xaosflux Talk 18:38, 16 October 2019 (UTC)
    @Xeno: no, the protection is copied, and remains with both the old redirect and the new page (if a redirect if left behind). However, if a redirect is suppressed, anyone will be able to recreate the page in terms of protection; nothing is left behind (though title black list and abuse filter still matter). Hope this helps --DannyS712 (talk) 18:54, 16 October 2019 (UTC)
    Yes, I didn't specify that this was only "if a redirect is left behind". — xaosflux Talk 19:58, 16 October 2019 (UTC)
    Thank you DannyS712, it does. So if implemented there would need to be a guidelines advising Page Movers not to take a protected page on a walkabout to apply protections to unrelated locations. –xenotalk 19:12, 16 October 2019 (UTC)
  • See brief, recent discussion at Wikipedia:Village_pump_(policy)/Archive_153#Changing/Adding_restriction_on_moving_pages_to_allow_"Pagemovers"_to_move_pagers_where_right_now_only_admins_can_do_so. ~ Amory (u • t • c) 19:46, 16 October 2019 (UTC)
  • There's a very similar discussion going on here about giving main page regulars this permission so they can help out more at the main page. One of the issues we're discussing is the fact that this permission also enables editng/moving through protection on other pages and changing levels of protection, so our rights request proposal addresses that by specifying that the Main page editor userright cannot be used to edit through protection/change protection levels on other pages and that making those kinds of edits would be considered inappropriate uses and grounds for removal of the right. The right would be a new right, so we wouldn't have the problem of a group who had been given the right under lesser requirements. Maybe you can solve your problem similarly by making this an additional right rather than adding it to the current right, then having people apply for this additional right? Protected mover or something? --valereee (talk) 10:21, 17 October 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Addition of PMRC#10

Latest comment: 5 years ago2 comments2 people in discussion

Since this cannot be adequately explained in an edit summary, I'm laying out the reason for the change here. For file movers who are also page movers, since 2010 the edit notice when moving files has directed them to suppress redirects when moving little used files. The addition of PMRC#10 is intended to document that existing norm so that it is available somewhere other than the wikicode of an obscure page in the MediaWiki namespace. While not explicitly stated in the mediawiki edit notice, I've asserted that this falls under WP:CSD#G6 like orphaned templates or moving edit-notices (PMRC#8). Wug·a·po·des​ 01:15, 22 November 2019 (UTC)

@Wugapodes: I've tweaked it to also allow updating the file names after, rather than before DannyS712 (talk) 01:54, 22 November 2019 (UTC)

"Wikipedia:ROBIN" listed at Redirects for discussion

Latest comment: 4 years ago1 comment1 person in discussion
 

An editor has asked for a discussion to address the redirect Wikipedia:ROBIN. Please participate in the redirect discussion if you wish to do so. 1234qwer1234qwer4 (talk) 11:12, 9 April 2020 (UTC)

New user right allowing editors to move pages over one-revision pages that redirect to anywhere

Latest comment: 4 years ago14 comments5 people in discussion
Tracked in Phabricator
Task T239277

As announced in the latest tech news:

Normally pages can be moved to a title that has no existing page yet or to a page that has only one revision, which is a redirect to the page to be moved. A new user right delete-redirect allows editors to move pages over one-revision pages that redirect to anywhere.

I imagine that assigning this right to page movers will be SNOW popular as it will reduce the need for round-robins a bit. Do we need an RfC for this? wbm1058 (talk) 14:20, 13 September 2020 (UTC)

Likely, but Wugapodes is suggesting giving it to everyone, so if there's to be an RFC it should be "AC or PM?" Primefac (talk) 14:25, 13 September 2020 (UTC)
I think autoconfirmed is too low of a bar given that, as I understand it, there is no record left in the logs indicating where the page formerly redirected to. That may not be easy to figure out, so there is some potential for disruption. It could be a way for someone who didn't get their way at WP:Redirects for discussion to try to circumvent process. – wbm1058 (talk) 14:40, 13 September 2020 (UTC)
Agree that this shouldn't go to autoconfirmed; granting it to autoconfirmed users would render the page mover right effectively meaningless. * Pppery * it has begun... 14:44, 13 September 2020 (UTC)
render the page mover right effectively meaningless - how so? All it's doing is changing "move over redirect that points here (with one edit)" to "move over redirect (with one edit)". That's not a huge change. Primefac (talk) 14:48, 13 September 2020 (UTC)
It is a huge change: moving a page over a redirect that points elsewhere is a change of WP:PRIMARYREDIRECT. People who do that need to know how primary topics work, and they need to take care to ensure the old target is still accessible after the move (say, via a hatnote). – Uanfala (talk) 15:01, 13 September 2020 (UTC)
Okay, I'll grant you it's a significant change, but it's not as bad as pppery's (in my opinion hyperbolic) statement. Primefac (talk) 15:20, 13 September 2020 (UTC)
As I wrote in phab:T232940#5550018:

The ability to move pages over redirects to other pages, however, is not a good idea. For one thing, it renders the page mover right effectively meaningless by granting everyone the ability to do an almost-round-robin move (move a preexisting page to another title, possibly in one's userspace so one can U1 the result, then move a second unrelated page over the redirect created by the first move, then move the first page over the redirect created by the second move, then tag the leftover redirect from the third move as G7 or U1).

* Pppery * it has begun... 15:10, 13 September 2020 (UTC)
And as I said in a similar discussion at WT:CSD, an admin who is blindly deleting pages without at the very least looking at the history (especially if it's a G7 on a recently-created redirect) shouldn't be an admin. You make some good points, and I won't be surprised if the initial post of "snowing for giving this to PMs" turns out to be true, but a point was raised at the phab ticket (not even by me!) and I felt it was appropriate to mention it above; it wasn't necessarily meant as an endorsement. Users (regardless of where this right ends up being granted) who abuse this right will be appropriately blocked, so I'm not really sure where the doom and gloom of "suddenly it will be anarchy and being a page mover will mean nothing" (emphasis added) comes from. Primefac (talk) 15:20, 13 September 2020 (UTC)
That's a cool new feature! I really don't see how this could be made available to autoconfirmed users: erasing a redirect at the target shouldn't involve any less responsibility than erasing a redirect at the source (which is essentially what page movers can do), and may even involve more. I don't see any potential for RfD-related disruption (if a user wants a redirect deleted it's because of the title, not the history of that redirect; if it's an issue then it's an issue for page movers, who can currently delete redirects by moving them around, not for people with the new right who won't be able to do so). Though there's definitely potential for disruption and that's when people move a page and don't notice that the target is a redirect (or notice that but don't realise the significance of the fact). – Uanfala (talk) 14:49, 13 September 2020 (UTC)
It's probably best to start with just admins and page movers when releasing this into the wild, and then after we see how it works in practice, the possibility of extending it could be considered. – wbm1058 (talk) 14:58, 13 September 2020 (UTC)
I suggested we consider an AC grant because even if we reject it, we should always have a good reason for restricting permissions. I would expect questions about why this went to PMs and not AC, and so having an answer to that from the start would be useful. AC permissions should generally be easily reversible by other AC holders, but page moves using this tool could only be reversed by sysops since the original redirect target would be hidden as deleted material. If we logged the deleted redirect's target along with the source and destination pages, it would expand the number of people who could help cleanup after tool misuse and I would feel better about granting to AC editors. But while this still requires a sysop to cleanup after, I think restricting to PMs is the best choice. — Wug·a·po·des​ 19:21, 14 September 2020 (UTC)

Allow automatic deletion during page move of redirect pages with multiple redirect-only revisions

Tracked in Phabricator
Task T232940

@Pppery: Why did you close T232940 as a duplicate of T239277? It is not a duplicate; this first task is only to allow deletions of one-revision pages, while this allows for deletion of multiple-revision pages if they are all redirects. I think, if the implementation of the delete-redirect right works well, then this second task should be reopened. In my view, anything that reduces the number of unnecessary page swaps is good. – wbm1058 (talk) 15:58, 13 September 2020 (UTC)

I closed that as a duplicate because it had already been closed as declined in favor of T239277 by a developer, and I felt "duplicate" was a clearer way of expressing that than "declined". * Pppery * it has begun... 16:04, 13 September 2020 (UTC)

Discussion on WT:CSD that would affect those with the page-mover right

Latest comment: 4 years ago1 comment1 person in discussion

See Wikipedia talk:Criteria for speedy deletion#Explicitly recommending that page movers to do some types of "deletion via move" to avoid delays (permalink). davidwr/(talk)/(contribs) 16:55, 19 September 2020 (UTC)

Page swaps with one talk page

Latest comment: 4 years ago6 comments4 people in discussion

I've seen a bunch of page moves lately where redirects were improperly suppressed. I found a pattern in them: it universally happens when someone does a round-robin page swap of two pages, of which one has a talk page and the other doesn't. It seems like step 4 of the process here already explains that you're supposed to manually create the redirect in these cases. I'm not sure why it's so common that this step gets overlooked. Does anyone have ideas on how we can fix this? Jackmcbarn (talk) 06:47, 4 October 2020 (UTC)

I would guess it's because no one remembers/thinks to check whether the talk pages actually exist. Primefac (talk) 14:40, 4 October 2020 (UTC)
I also wonder if some of it is from using the script and not remembering that it doesn't automate the entire process just the first three steps. PaleAqua (talk) 15:02, 5 October 2020 (UTC)
The update in the page swap script creates a talk page redirect automatically, it’s part of the semi-step four. Megan☺️ Talk to the monster 07:19, 6 October 2020 (UTC)
You're correct, just checked the source. Reverted my change. PaleAqua (talk) 23:23, 6 October 2020 (UTC)
@Synoman Barris and PaleAqua: Note that only Ahecht's script does that; Andy M. Wang's does not. Jackmcbarn (talk) 03:45, 7 October 2020 (UTC)

Moving categories

Latest comment: 4 years ago2 comments2 people in discussion

Just curious, PM has the "move-categorypages" right, although there seems to be no guidance on when PM can use it, at least not on this page or in the archives. Is it solely only allowed to be used to implement things at Wikipedia:Categories_for_discussion#Speedy_criteria, or is it allowed for obvious non-controversial usages (eg changing a tracking category's letter casing)? By extension, can one request from any PM faster technical category moves vs waiting the 48+ hours at CfD's speedy process, for technical changes to maintenance categories? ProcrastinatingReader (talk) 22:28, 12 October 2020 (UTC)

Notified: Wikipedia talk:Categories for discussion. * Pppery * it has begun... 00:36, 13 October 2020 (UTC)

More than 2000 subpages

Latest comment: 4 years ago4 comments3 people in discussion

How would a page mover move an article that has a number of 2000 and more subpages to a new title. I'm confused. Technically, while making a move we should be allowed to move all the sub pages that an article has. I don't understand why it is limited to just "up to 100". I recently moved an article in WP space per RM request inadvertently to a title requested. The project page including 100 subpages are moved rightly and "remaining hundreds of subpages are there unmoved". But didn't noticed it had subpages more than "2000". What do I do? ─ The Aafī (talk) 14:56, 21 November 2020 (UTC)

It's a technical limitation. Which page are you referring to TheAafi? Primefac (talk) 20:24, 21 November 2020 (UTC)
Primefac, JJMC89 has moved all the sub pages & can be seen in their contributions. This gave me headache seriously. This thread may be closed anytime however I would like to know if there are any helpful tools. ─ The Aafī on Mobile (talk) 20:27, 21 November 2020 (UTC)
WP:MASSMOVE is the way to do it, but it's only available to admins. There's an incredibly messy and time-consuming way to do it as a non-admin, but to be honest it's not worth explaining so it's better to just let an admin handle it. Primefac (talk) 20:31, 21 November 2020 (UTC)

Editnotices

Latest comment: 3 years ago1 comment1 person in discussion

Although the capsule summary at the top of the page mentions "creation and editing of editnotices", that power is not mentioned anywhere in the body of the page, at least not in a way that a typical user will understand. Zerotalk 01:49, 27 November 2020 (UTC)

Notification of an RFC

Latest comment: 3 years ago1 comment1 person in discussion

Users may be interested in the RFC at Wikipedia talk:Page mover/delete-redirect § RFC on granting delete-redirect to page movers. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Page swaps and primary topics

Latest comment: 2 years ago10 comments5 people in discussion

The section Wikipedia:Page mover#Establishing a primary topic details a series of two page swaps as a way to effect a change of primary topic. In essence, if X is a dab page and X (foo) needs to be moved to the primary topic, then the recommended actions are to first swap X with X (foo) and then swap X (foo) with the redirect X (disambiguation). I see two problems with this method:

1. The history of the dab page will document a series of two bizarre moves, which will likely look puzzling to the uninitiated.
2. The history of the erstwhile redirect to a dab page (X (disambiguation)) will end up under a title that is now a "topical" redirect (X (album)). This dissociates a page from its redirects and makes it more difficult for editors in the future to investigate the history of those redirects.

These two issues will crop up whenever two page swaps are used to change a primary topic. I don't think the cost ( = the convolution of page histories) is worth the benefit ( = the slightly greater ease for page movers). What's more, in the majority of cases such a sequence of swaps isn't even necessary: the above scenario can be dealt with using two straightforward moves: X -> X (disambiguation) (provided this latter redirect doesn't have more than one edit in its history), and then X (foo) -> X, with suppressredirect used for the first step.
Why are we recommending such convoluted measures when the simple steps are usually enough? – Uanfala (talk) 20:10, 1 October 2020 (UTC)

  • I always wondered the same. Also, i think the example page titles there are also a little confusing. —usernamekiran (talk) 21:32, 1 October 2020 (UTC)
    I'm also curious how often such moves happen. I think a visual means of describing the change (like with HISTMERGE) would help ease some of the confusion of three pages with the same base name. Primefac (talk 21:21, 3 October 2020 (UTC)
    My experience is that these happen almost always when a page mover executes a move to or away from a primary topic. – Uanfala (talk) 21:45, 3 October 2020 (UTC)
  • So, I see two options:
    A. Do nothing
    B. Simply remove the section
    C. Remove the section and add an explanation somewhere else to the effect that page swaps should usually only be done between one page and a redirect to it, ideally never across topic boundaries.
  • In my opinion, we should do at least B. I see C as desirable but it would require more discussion. – Uanfala (talk) 21:45, 3 October 2020 (UTC)
  • OK, I've removed this section (option B. above) [1]. I haven't gone as far as explicitly advising against double swaps (option C.), but I've boldly replaced it with a section outlining a different process: a chain of three simple moves, which doesn't lead to the problems associated with doing two swaps. This is a bold addition, so I'd appreciate review and criticism (the section now is Wikipedia:Page mover#Moves involving primary topics). – Uanfala (talk) 12:40, 5 October 2020 (UTC)
@Uanfala: did you see the discussion behind this at Wikipedia talk:Page mover/Archive 3#Page movers implementing a primary topic? That describes the issue that led to the creation of this section. wbm1058 (talk) 19:33, 12 October 2020 (UTC)
Thanks for pointing this out – I admit I had failed in my duty of diligence here. Having had a look at the discussion, I see that the issues I've noted above are similar to the ones you'd raised there about the three-step swap method, and unless I'm fundamentally mistaken, they apply with no lesser force to the two-step method – in both cases, the history of the {{R to dab}} redirect will end up at a title (like X (album)) that's associated with the new primary topic. – Uanfala (talk) 20:31, 12 October 2020 (UTC)
  • By the way, there are actually four equivalent ways of achieving the same result:
    • Swap X (foo) with X (applying the pageswap script on X (foo)), and then swap X (foo) with X (disambiguation) (again, applying the pageswap script on X (foo)).
    • Swap X (foo) with X (disambiguation) (applying the pageswap script on X (foo)), and then swap X with X (disambiguation) (applying the pageswap script on X).
    • Swap X with X (disambiguation) (applying the pageswap script on X), and then swap X (foo) with X (applying the pageswap script on X (foo)).
    • Move X (disambiguation) to a temporary "holding" title, then X to X (disambiguation), X (foo) to X, and finally the temporary "holding" title to X (foo).

The following four tables verify the equivalences:

Method 1 for establishing a primary topic
Step Redirect Disambiguation page "Foo" article
Step 0 X (disambiguation) X X (foo)
Step 1 X (disambiguation) Draft:Move/X (foo) X (foo)
Step 2 X (disambiguation) Draft:Move/X (foo) X
Step 3 X (disambiguation) X (foo) X
Step 4 Draft:Move/X (foo) X (foo) X
Step 5 Draft:Move/X (foo) X (disambiguation) X
Step 6 X (foo) X (disambiguation) X
Method 2 for establishing a primary topic
Step Redirect Disambiguation page "Foo" article
Step 0 X (disambiguation) X X (foo)
Step 1 Draft:Move/X (foo) X X (foo)
Step 2 Draft:Move/X (foo) X X (disambiguation)
Step 3 X (foo) X X (disambiguation)
Step 4 X (foo) X Draft:Move/X
Step 5 X (foo) X (disambiguation) Draft:Move/X
Step 6 X (foo) X (disambiguation) X
Method 3 for establishing a primary topic
Step Redirect Disambiguation page "Foo" article
Step 0 X (disambiguation) X X (foo)
Step 1 Draft:Move/X X X (foo)
Step 2 Draft:Move/X X (disambiguation) X (foo)
Step 3 X X (disambiguation) X (foo)
Step 4 Draft:Move/X (foo) X (disambiguation) X (foo)
Step 5 Draft:Move/X (foo) X (disambiguation) X
Step 6 X (foo) X (disambiguation) X
Method 4 for establishing a primary topic
Step Redirect Disambiguation page "Foo" article
Step 0 X (disambiguation) X X (foo)
Step 1 Draft:Move/X (foo) X X (foo)
Step 2 Draft:Move/X (foo) X (disambiguation) X (foo)
Step 3 Draft:Move/X (foo) X (disambiguation) X
Step 4 X (foo) X (disambiguation) X
  • Clearly, Method 4 requires fewer moves than the other three methods, and so might be the preferred method. Comparing the number of moves applied for each of the three pages in each method, one gets the following table:
Number of moves for the redirect, disambiguation page, and "Foo" article
Method Redirect Disambiguation page "Foo" article
Method 1 2 moves 3 moves 1 move
Method 2 2 moves 1 move 3 moves
Method 3 4 moves 1 move 1 move
Method 4 2 moves 1 move 1 move
  • Note that Methods 3 and 4 are "symmetric", while Methods 1 and 2 are "reverses" of each other. Also, all four methods apply equally well to the disestablishment of primary topics, where one simply switches the order of the last two columns in each of the above five tables, as well as the roles of "X (foo)" and "X (disambiguation)" in the four verification tables. GeoffreyT2000 (talk) 04:15, 15 October 2020 (UTC)

Maybe a suggestion?

Latest comment: 2 years ago2 comments2 people in discussion

I think it would be nice to let Page movers move article that are move protected by an admin to avoid valid requests pending at WP:RM/TR for a long period of time until the few admins patrolling that page notices them. Cheers --Megan B.... It’s all coming to me till the end of time 13:17, 2 February 2022 (UTC)

Looking at Special:ListGroupRights § sysop, I assume that such a change would require a non-trivial technical change, since the ability to move greenlocked pages is under the aegis of editprotected (hopefully a more technically-proficient editor will confirm). As for the merits, I'm not sure. Generally speaking, there's no urgency to move greenlocked pages. Sdrqaz (talk) 15:28, 2 February 2022 (UTC)

Move discussion in progress

Latest comment: 2 years ago1 comment1 person in discussion

There is a move discussion in progress on Wikipedia talk:RR (disambiguation) which affects this page. Please participate on that page and not in this talk page section. Thank you. BilledMammal (talk) 05:50, 29 May 2022 (UTC)

Should there be some variant of this right for new page patrollers?

Latest comment: 2 years ago5 comments3 people in discussion

In new page patrol, I'm moving some articles to Draft. That leaves behind two stubs (article and talk) for speedy deletion. That seems to be a waste of time. Is there some way to enable NPPs to do the whole move without leaving behind the need for CSDs? — rsjaffe 🗣️ 04:39, 2 June 2022 (UTC)

Any reason you can't just request page mover if you have a need? R2 is covered under "Redirect suppression criteria" PaleAqua (talk) 18:40, 3 June 2022 (UTC)
Yes. I could. Believe it or not, I’m not a fan of accumulating “privileges”, but I may apply if I manage to stick with NPP. It’s easy to burn out doing that task. — rsjaffe 🗣️ 19:03, 3 June 2022 (UTC)
While interesting in that extendedmover candidates can be classified into the more "traditional" RM ones and the R2 NPP ones (my own was the latter), I don't really see how this proposal is workable. Once you give someone suppressredirect, dubious uses tend to crop up in WP:PMRC#7 situations. You're using MoveToDraft.js, which automatically tags those cross-namespace redirects. While there may be a case to be made for reducing the workload for administrators, the extra workload for users of that script is rather minimal (for disclosure, I have that script installed but preferred to do mine manually). Sdrqaz (talk) 00:27, 4 June 2022 (UTC)
I’ll just leave things as-is. Sounds like the current situation is good enough. — rsjaffe 🗣️ 01:00, 4 June 2022 (UTC)

Expired

Latest comment: 2 years ago2 comments2 people in discussion

Hello! It seems that I no longer have the page mover right. Is this something that needs to periodically renewed? If yes, could that be done? Thanks. PhotographyEdits (talk) 14:23, 1 July 2022 (UTC)

If you were temporarily granted page mover, you will need to re-apply in the usual place when it expires. Primefac (talk) 14:24, 1 July 2022 (UTC)

Wikidata errors

Latest comment: 1 year ago17 comments8 people in discussion

Hi, there's a conversation over on my user talk page regarding interwiki links that are being broken during page moves. @BrokenSegue left a link to a list of such instances (some of which have since been fixed). I've taken a look at a few (and I plan on looking some more when I have time) and I haven't been able to figure out what is causing the links to not update. It looks like it might be multiple issues affecting them, but I don't fully understand how Wikidata is updated when pages are moved here, so I figured I would ask if any other page movers may have run into such problems in the past or if anyone knows where the right place to ask about this would be? Thanks as always!

In the meantime, I might recommend making a quick check of Wikidata part of your post-move cleanup whenver possible. I used to check these myself but I may have had too much faith in our automatic updates. ASUKITE 17:01, 13 January 2023 (UTC)

I know this is not in the spirit of a collaborative encyclopedia, but I am not going to take extra time out of my day because a different project can't handle something I've done on here. "You moved a page but WikiData didn't follow" is not an issue I can solve, nor one that I want to solve. If someone wants to tag me in a phab task for trying to solve things, that's one thing, but "you need to check WikiData after every page move you make to make sure it updated properly" is not something I will ever do. Primefac (talk) 09:51, 16 January 2023 (UTC)
@Primefac: it literally is an issue you can solve. this isn't just a problem for wikidata. this breaks interwiki links between wikipedias. BrokenSegue 23:20, 17 January 2023 (UTC)
Note that the easiest solution for editors who are only on this project is to manually readd interlanguage links to the article, which will automatically override Wikidata (see Help:Interlanguage links). These interlanguage links in the articles were deprecated because of concerns unrelated to the English Wikipedia, and were deleted en masse by bots, removing them from the scope of things handled in article markup here. As far as I can tell there never would have been a problem had Wikidata not taken over this aspect of the interwiki process in 2013, so I tend to agree with Primefac that the onus for editing non-EN-WP Wikimedia projects has to lie with users active in those projects. Dekimasuよ! 06:03, 18 January 2023 (UTC)
I concur. I find Wikidata counterintuitive and confusing, and I use it as little as I can. If it becomes a requirement for page movers that we have to update Wikidata too, then I'll stop being a page mover. BilCat (talk) 06:28, 18 January 2023 (UTC)
In all fairness, pre-Wikidata we had dozens of bots synchronising the interwiki links, and fixing interwiki errors required editing several foreign Wikipedias. Wikidata usually deals with page moves or deletions well, and better than the old bot system. —Kusma (talk) 06:57, 18 January 2023 (UTC)
If Wikidata works so well, why are we having this discussion at all? BilCat (talk) 07:20, 18 January 2023 (UTC)
What I'm trying to say is that what we had before Wikidata was used for interwikilinks wasn't really any better. Fixing interwiki conflicts was not easy then, and it isn't easy now. I also wouldn't want to require from people to check Wikidata after a move. But if you do notice something is wrong, it is good to try to fix it or at least flag it up (which isn't easy enough on Wikidata). —Kusma (talk) 08:44, 18 January 2023 (UTC)
I find Wikidata hard enough to use as it is. I certainly won't be trying to "flag it up"! BilCat (talk) 09:55, 18 January 2023 (UTC)
isn't there already a bot on wikidata side to update the records postmove? it might be just a tad slower in catching up. – robertsky (talk) 01:19, 18 January 2023 (UTC)
no. there is no way for wikidata to know that a move should be done. the broken state people leave it in is potentially valid. BrokenSegue 03:41, 18 January 2023 (UTC)
Wikidata is in a broken state because it's a poorly designed and managed product. Just look at the Short Descriptions fiasco that we got stuck with. Better to shut it it down if it can't work properly. BilCat (talk) 06:31, 18 January 2023 (UTC)
You are wrong. Wikidata links are automatically updated when a Wikipedia page is moved, and that mechanism works fairly well, even after regular page swaps. However, there is a set of cases where the mechanism fails, and Wikidata needs to be updated manually. It happened that a couple of times, but I cannot exactly tell under which circumstances: I think it will happen when a conflict will occur on Wikidata, i.e. the target title is already used by a different Wikidata item. No such user (talk) 08:57, 18 January 2023 (UTC)
I was not "wrong" - this wasn't explained well enough to understand what exactly what's as happening here. Anyway, I'm glad to hear it works most of the time. I won't be worrying about then. BilCat (talk) 09:53, 18 January 2023 (UTC)
Just to respond to No such user's comment - if there is an action or set of actions that causes the WikiData disconnect (i.e. it happens under certain circumstances) I would be more willing to attempt to remember "when I do X I also need to make sure Y happens". Hell, if someone can pin it down I'll make sure it lands on the admin newsletter. Primefac (talk) 11:58, 18 January 2023 (UTC)
Let's track d:Q5235334 which links to attorney David Iglesias (edit | talk | history | protect | delete | links | watch | logs | views), but states that it's a "Wikipedia disambiguation page". The original dab page at that title was deleted by Tassedethe [2] and David Iglesias (attorney) (edit | talk | history | protect | delete | links | watch | logs | views) moved over. That has caused the latter to end up in Category:Redirects connected to a Wikidata item, namely d:Q5235335. With the dab page deletion, its Wikidata item should have been deleted or at least unlinked so that the bot can catch up with the move, but it was missed.
So, for example, when we get to delete dab pages from Category:Disambiguation pages containing one non-primary topic, there's a lingering chance this will reoccur.
I vaguely remember there's kind of warning about Wikidata items after a move or pageswap, but I don't always pay attention to it. No such user (talk) 13:11, 18 January 2023 (UTC)
Another use case: I recently moved Skryje to Skryje (Rakovník District) (edit | talk | history | protect | delete | links | watch | logs | views) and created a dab page at the base title, now at Skryje (edit | talk | history | protect | delete | links | watch | logs | views). After the move, I had to manually update interwiki links to sync the new dab page with the dab page in other languages (that can be done from en.wiki UI, no need to visit wikidata). But that is not a technical glitch – basically, I created a new page and it was prudent to add interwikis, just as I should if it were a new article. Me being a page mover executing a move via pageswap has nothing to do with such situation. In fact, examining all my Wikidata contribs (and I have both manual and automatic ones), I can't find a single instance where I created a problem there, and I move things a lot. It takes an admin to create a problem, it seems. :) No such user (talk) 13:46, 18 January 2023 (UTC)

Category moves

Latest comment: 1 year ago2 comments2 people in discussion

Hello, I just encountered an editor who was recently granted page mover rights who thought if they moved a category to a different title, some bot would move all of the articles in the category to its new title. But that doesn't happen automatically, an editor has to work through a nomination at CFD or at CFD speedy renames. I came here to see what guidance new page movers are given and the page says that page movers are given the right to move categories! While I guess that is technically true, one doesn't move a category like you'd move an article or draft page, the only situation I can see where it sould be that simple would be if a page mover wanted to move an empty category, like a category redirect, to a new title. But if a category has articles/pages in it, moving the category won't result in recategorization unless it is done through CFD and the CFD bot handles this. Just moving a category without doing further changes to the categoy contents or without leaving a category redirect results them either a) all having red link categories which Wikipedia prohibits (see WP:REDNO) or b) being placed in a category redirect category when a category redirect category is intended to remain empty.

Can this limitation be written into the guidelines? I'd even advocate removing the statement about having "move-categorypages" from the rights given since, if it is done incorrectly, it has the potential to really mess things up. Luckily, in the incidents that just happen, an admin noticed and quickly reverted the category moves. But you can't depend on that happening if new page movers believe they have the ability to move categories like they are ordinary pages. Thank you. Liz Read! Talk! 00:27, 17 February 2023 (UTC)

Agree that this is a good thing to state explicitly. I gave it a shot with this edit; feel free to revise or revert as necessary, although it shouldn't be too controversial since we're basically just restating MediaWiki:Movecategorypage-warning. Extraordinary Writ (talk) 08:05, 18 February 2023 (UTC)

Why am I not seeing "suppress redirect" checkbox?

Latest comment: 1 year ago3 comments2 people in discussion

I am trying to do a round robin move. There is a page I want to update which has two redirects that point to it. One of the redirects should be the canonical name for the page. I looked at instructions here and saw the illustration here. However when I try to follow those instructions I do not see the "suppress redirect" checkbox option and so trying to do this doesn't work. Here are the three pages.

I feel like I know how to do this if I had access to the "suppress redirect" checkbox, but otherwise I am adrift. I tried one move and looked like it was going to make it worse so I stopped and headed over here. I did try changing my theme to see if that mattered and it did not. Thanks for any help. Jessamyn (my talk page) 23:28, 9 June 2023 (UTC)

@Jessamyn Because you do not have the "page mover" (extendedmover) permission, you do not have the suppressredirect right, and the checkbox will not appear. You can request the permission at WP:RFP/PM. — Mdaniels5757 (talk • contribs) 23:56, 9 June 2023 (UTC)
Thank you! I think I thought because I could move pages that I could do all the other things. Appreciate it. Jessamyn (my talk page) 00:08, 10 June 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Page_mover/Archive_4&oldid=1198302377"