Archive 30 Archive 32 Archive 33 Archive 34 Archive 35

Receiving "current page title is invalid" warning

Sorry all, to do this here, but I am unable to place the following move on the main page for some reason. Is anybody able to (i) explain to me my mistake and (ii) carry out the move?

subst:RMassist| Nuala Níc Con Iomaire | Nuala Nic Con Iomaire | reason = incorrect spelling of name as verified by link to Irish Times obituary on page — Preceding unsigned comment added by Jmharve (talkcontribs) 12:18, 15 March 2022 (UTC)

Not sure where exactly you're trying to put this, but it looks like it should work fine, provided it all goes inside ((...)). Primefac (talk) 12:47, 15 March 2022 (UTC)
Huh. It did work fine, yes. I haven't done anything different from what I tried first time round, but it's worked now! Jmharve (talk) 15:04, 16 March 2022 (UTC)

Request 16 march to backlog, why?

Fano (nationalist movement)Fano (militia) this discussion went straight to backlog, why? The request to move via Requested moves was done today. Dawit S Gondaria (talk) 23:45, 16 March 2022 (UTC)

This is because the bot in charge of keeping things updated, doesn't understand the date of adding RM templates. It assumes the last date in the first paragraph under the template to be the RM start date, which in this case is was 3 March and thus shown as backlog. ---CX Zoom(he/him) (let's talk|contribs) 06:04, 17 March 2022 (UTC)
I've relisted it, the bot will now place it in the 17th March section. Cheers! ---CX Zoom(he/him) (let's talk|contribs) 06:06, 17 March 2022 (UTC)

Backlog notice

I see the backlog notice at the top of the page constantly, and with how many page movers help out with the RM process, I feel like it would read better as This page has a backlog which requires the attention of one or more administrators or page movers. Thoughts? Skarmory (talk • contribs) 23:09, 17 March 2022 (UTC)

The notice is from ((backlog)) which I don't believe can be changed. Plus, as a page mover, I'm not sure it would make much of a difference. Generally speaking, we sign up for that user right because we like to close RMs. Calidum 18:34, 18 March 2022 (UTC)
It can be changed; right now the bot is setting the template to the admin version. I’ll look into this through a code change in the bot soon. 🐶 EpicPupper (he/him | talk) 22:12, 18 March 2022 (UTC)
Oh, and by the way, I plan on changing it to just “editors” as non-admins/page movers can close RMs. 🐶 EpicPupper (he/him | talk) 22:18, 18 March 2022 (UTC)
To editor 🐶 EpicPupper: gentle reminder: I would check with editor wbm1058 since that template is drawn by 400+ pages. P.I. Ellsworth - ed. put'r there 19:55, 21 March 2022 (UTC)
Hi @Paine Ellsworth! I was proposing a change to how the template is invoked through the bot, not the actual template code. Does this still apply? Thanks! Sorry for the delay, travelling right now and editing on the smart fridge in the hotel. Cheers! 🐶 EpicPupper (he/him | talk) 04:12, 22 March 2022 (UTC)
Yes, I would think it does apply, 🐶 EpicPupper. First, with respect, I think the admin version should be kept, because certain aspects of page moving are only possible if one has admin or page mover user rights, and for page movers they are actually unbundled admin user rights. While it's true that any editor can close RMs and in some situations can move pages, it is best that these chores be done by experienced editors regardless of their user rights. Secondly, editor wbm1058 is the custodian of the RMCD bot and very likely appreciates it when informed about anything that affects it or is affected by it. Imho, there is nothing broken here; therefore, there is nothing that needs to be "fixed". But that's just me; I could be wrong. P.I. Ellsworth - ed. put'r there 10:15, 22 March 2022 (UTC)
Thanks for the clarification. Your logic seems sound; I'll hold off on the changes. Cheers, 🐶 EpicPupper (he/him | talk) 16:20, 22 March 2022 (UTC)

Page link “move” to correct article title - “The Nymphs” to: “Nymphs (Band)”

Moved to Talk:The Nymphs § Requested move 27 February 2022

13:11, 27 February 2022 (UTC)

Is there an update on this? HandOfKwll (talk) 08:26, 27 March 2022 (UTC)

The RM is still open. Primefac (talk) 08:51, 27 March 2022 (UTC)

Please Rename a Page

Moved to Talk:Orange Romania Communications (diff)

16:34, 29 March 2022 (UTC)

Updating WP:THREEOUTCOMES

Is there any objection to changing "Consensus to not move" under WP:THREEOUTCOMES to "not moved?" The latter is the more commonly used phrasing nowadays and is less of a mouthful. Calidum 23:18, 15 February 2022 (UTC)

Sounds reasonable to me. Colin M (talk) 23:34, 15 February 2022 (UTC)
"Not moved" is ambiguous as it also accurately describes the effect of a "no consensus" closure. How about "consensus against move"? – Uanfala (talk) 23:41, 15 February 2022 (UTC)
I'm not seeing what problem this is solving. "Less of a mouthful" also can mean "less precise". Just plain not-moving-the-article can occur for two pretty different reasons, one being nobody much wanted to move it, the other being because after some vague milling around nobody could decide what to do so nothing was done. I'm not sure that just "not moved" by itself is a sufficiently detailed description for the bolded heading for either case. But maybe I'm wrong, and I'm willing to be convinced. But thanks for asking and bringing it up. It's a reasonable proposition. Herostratus (talk) 02:37, 16 February 2022 (UTC)
I think Calidum's point is that, in practice, when there's consensus against moving, 95% of the time closers summarize this with a bolded "Not moved". It's all well and good to say that what they really should be writing is X, but how are you going to get closers to actually modify their behaviour? It looks like RMCI was edited in 2018 to try to establish "Consensus not to move" as the preferred verbiage over "Not moved", but 4 years later it still doesn't seem to have taken hold. Colin M (talk) 03:30, 16 February 2022 (UTC)
Yes, I would prefer the closing instructions follow what actually happens in practice rather than some theoretically superior wording. Not only is "not moved" the more commonly used term, it's unambiguous in the vast majority of cases. I would also note "not moved" was listed as an alternative to "consensus not to move" until November when it was removed by the one user who seems to raise a stink about this issue [1]. Calidum 16:28, 16 February 2022 (UTC)
Support (with caveat) "Not moved" has been used for a while, and is mostly used to indicate with consensus but can be ambiguous I'd suggest that a some advice be added to strongly suggesting the that closing statement impart if their was a consensus or not. Perhaps adding "The close should make clear if there was a firm consensus or not." before the list of options. Ambiguities in closes for "not moved" have regularly ended up at MR. PaleAqua (talk) 17:58, 16 February 2022 (UTC)
Example good close opening sentences are:
* "The result of the discussion below is consensus to not move".
* "The result of the discussion below is consensus to move to New title".
* "The result of the discussion below is no consensus. <Necessarily explanation>".
also fine is
* "Not moved per consensus garnered below, ..."
The shorthand "not moved" is ambiguous about consensus. It is ambiguous about whether there was consensus or not, and much worse, it is ambiguous about whether the closing of the discussion was an exercise in looking for consensus, as opposed to authoritarian decision making, or vote counting, or some technical detail in the closer's further explanation. All regular editors know closing discussions is about finding consensus, but (sources somewhere we could look) the most important editors for Wikipedia in terms of content added are not regular editors, but IPs and editors who nearly never edit talk pages. This broad group of editors should be accommodated by simple closing statements that can be read at face value, at least in the first sentence of the closing statement.
Title changes are perhaps the most important interactions between encultured Wikipedians and drive-by editors, and I have seen plenty of cases where the drive-by editors are somewhat excluded by the opaque nature of titling policy and RM process. WP:RMCI should never lock in sloppy practice that is convenient for closers at the expense of simple clarity, but should encourage best practice. --SmokeyJoe (talk) 03:37, 17 February 2022 (UTC)
I also wonder whether THREE in THREEOUTCOMES is not quite right, as "consensus to move but WP:NOGOODOPTIONS" might be considered not one of the three. SmokeyJoe (talk) 03:45, 17 February 2022 (UTC)
There are sometimes situations in which the three outcomes are combined into four, five, and so on. Multiple proposals where consensus is to move one or two and not move one or two, NOGOODOPTIONS where consensus is to move but there is no consensus where to move, and so on. KISS, or Keep It Simple SmokeyJoe. P.I. Ellsworth - ed. put'r there 04:13, 17 February 2022 (UTC)
I consider these cases to be bungled bundles. In a bundled multipage RM all the multiple pages are supposed to have all the same story.
I think we might agree, WP:RMCI is in parts overly BOLDly written? SmokeyJoe (talk) 04:51, 17 February 2022 (UTC)
Yes, and one overly bold edit imho was Not moved to Consensus to not move. Overly bold overkill in more ways than one, again imho. P.I. Ellsworth - ed. put'r there 05:10, 17 February 2022 (UTC)
Would you support "Consensus to not move"?
I think "The consensus below is to not move" is better. "Consensus" is found in the discussion; "consensus" is not the declaration of the closer. SmokeyJoe (talk) 05:31, 17 February 2022 (UTC)
For the same reason you suggested we be up front with the page move in the first sentence, e.g. "Moved to new title with no consensus per...", the Moved, Not moved or No consensus should be right up front, the first words in the first sentence. They should be the very first words that readers see. P.I. Ellsworth - ed. put'r there 08:40, 17 February 2022 (UTC)
That's the cake, and everything else is icing. P.I. Ellsworth - ed. put'r there 09:04, 17 February 2022 (UTC)
Stepping back here, we must consider the purpose of this section. It has been suggested that we need to explain to editors closing rationale. I don’t think that is the purpose of RMCI. It’s purpose to guide closers. If there is a compelling need (doubtful) to explain RM closes to editors, then that is the role of a good essay.Mike Cline (talk) 14:26, 18 February 2022 (UTC)
Sure, Mike, always space for good essays. I might try that.
An example will be your recent close at Talk:Persecution of Kashmiri Shias#Requested move 1 February 2022. On examination, it is a perfectly “correct” close, but an effort is necessary to see that. The closing statement language is phrased beginning like a Supervote. It makes no explicit mention of the discussion until the 22-26th words. Many readers have turned off by then. It would be better if the RMCloser assistant scripts were better phrased. Change “The result of the move request” to “The result of the discussion below”. Emphasise in plain and obvious words that the close is a reading of the discussion, not of the closer’s logic. Provide better example to the new editor closers who evidently misread that standard closing phraseology as consistent with supervoting.
—-
SmokeyJoe (talk) 02:57, 20 February 2022 (UTC)
@SmokeyJoe: Phasing a close is indeed not the easiest thing, especially when the discussion whether short or long is full of complexity. BUT, that said the one thing I will disagreed with in your statement above is: “ Many readers have turned off by then.” Attributing generalized behavior to readers in a discussion is pure folly and a pet peeve of mine. Are you psychic?? There are 43M register users on WP. What % of those are “readers” of RMs? (No one knows). What % of the % we don’t know fall into your category of “many”? Devining how “readers” and “users” may or may not behave is a poor argument for any guidance change. Mike Cline (talk) 16:27, 20 February 2022 (UTC)
Mike, there’s quite a body of literature on theories of reading and cognition, and on effective writing, but what I think is relevant here is congruent signage. There is a lot of data on how many words people read before moving on, it’s a very big newspaper and internet science. Long sentences hurt the casual reader. Note that here, by reader, I mean inexperienced editor who might be about to start closing RM discussions. My point is that “The consensus in the discussion below is …” is better phrasing for making it clear what the closer’s role is. SmokeyJoe (talk) 21:52, 20 February 2022 (UTC)
Remember: when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.Neil Gaiman. You should close a dozen or so RMs and show us how it should be done. Mike Cline (talk) 01:05, 21 February 2022 (UTC)
Mike, you are quite justified in noting that I am unqualified and commenting from the peanut gallery.
Do you disagree that closes would be just as easy for the closer, and easier for the beginners, if the scripted default language said, instead of “The result is …” said “The result of the discussion below is …”.
Almost always doesn’t mean always. I never said I know exactly anything. I observe that RM script-assisted phraseology is jargonesque.
I picked your recent example as an excellent close, except solely for the RMhelper scripted language, because it’s form in the opening words match another close being discussed at Wikipedia:Move review#Radio 1 FM (Gambia), a terrible close that begins with the same phrasing. In a sense, the second is like a ridiculous parody of the first. It’s as if the inexperienced closer copies the form of closing by experienced closers, but without enough thought on the need for a close to be a reflection of the discussion they are closing.
If the scripted language made explicit reference, in the opening words, to the discussion below, that alone would prompt new closers to close with a reflection of the discussion below. I think this is a tiny thing that would help some, at least, but the helper script writer is not even in this discussion.
Maybe I can make another formal proposal: The RM closer helper scripts must be listed at THREEOUTCOMES, as an indicator that they have been minimally advertised. Much like is done at WP:DRAFTIFY, at Wikipedia:Drafts#Tools for moving articles to draft space SmokeyJoe (talk) 02:35, 21 February 2022 (UTC)
@SmokeyJoe: - We are at a bit of cross-purposes here. I assumed that the proposal here was about the text of RMCI (the closing guideline), not some scripted tool that helps editors close RMs. Personally, I don’t care what the tool says as long as it is consistent with the RMCI guideline. I don’t use the tool, never have and probably won’t. In fact, I have little confidence that any scripted RM closing tool can deal with the various, and many, permutations of RM closing rationale. Advertising the tool at RMCI is fine, but in IMHO closers, regardless of experience, must be familiar with RMCI and all relevant WP Policies and Guidelines re article titles when making a close. The tool might indeed make things functionally easier, but it is doubtful the tool can be a substitute for RM closing experience and a keen understanding and application of WP Policies and Guidelines.Mike Cline (talk) 10:28, 21 February 2022 (UTC)

Simplifying wikilinks following establishment of a new primary topic

I just closed an RM which established a ptopic for Shillelagh. There are a lot of wikilinks across the project of the form [[Shillelagh (club)|Shillelagh]]. As part of the post-move cleanup, would it be acceptable to do an AWB run to simplify these wikilinks to just [[Shillelagh]]? This seems like an improvement in that it simplifies the page source as well as Special:WhatLinksHere/Shillelagh. But I wanted to confirm, because I know some people can get tetchy about "cosmetic" edits. Colin M (talk) 20:46, 18 April 2022 (UTC)

I will note that WP:NOTBROKEN is a guideline. The WP:COSMETICBOT policy says that While this policy applies only to bots, human editors should also follow this guidance if making such changes in a bot-like manner., which I feel includes AWB runs. 🐶 EpicPupper (he/him | talk) 21:07, 18 April 2022 (UTC)
I don't think these are the sorts of edits WP:NOTBROKEN is trying to discourage. NOTBROKEN advises against replacing [[redirect]] with [[target|redirect]] - i.e. inserting unnecessary pipes which "make the article more difficult to read in page source form" and impede use of the "what links here" tool. The changes I'm describing have precisely the opposite effect. Colin M (talk) 21:11, 18 April 2022 (UTC)
Apart from DAB pages, hatnotes, templates, See also and articles that specifically reference the article title like "Index of X" articles the links should generally not be bypassed. Crouch, Swale (talk) 21:47, 18 April 2022 (UTC)
I would qualify those as cosmetic and unnecessary. I'm not particularly tetchy about "cosmetic" edits, but cleaning up minor pollutions in wikicode is really low on the list of priorities and pollutes other stuff, such as article history and peoples' watchlists. Besides, should we change our mind one day and decide that "Shillelagh" is ambiguous still (e.g. because of a new hot Netflix series with that title), we will have to re-disambiguate links.
Personally, after a move I check and retarget links only for situations outlined in WP:BRINT, particularly #1 (links from navigation templates) and #4 (on dab pages). No such user (talk) 08:15, 20 April 2022 (UTC)
I would think of it this way: those links will never be broken due to being too specific, but a different discussion in the future could decide that there is no primary topic for the term after all. In such a case, the links would all have to be fixed again, manually. In my opinion, that sort of foreseeable outcome is sufficient reason to leave these sorts of links the way they are. Dekimasuよ! 08:52, 20 April 2022 (UTC)

Proposal to modify current practice.

The following discussion 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.


I intend to propose a modification to our current practice regarding the completion of uncontested technical move requests. This will be the WP:RFCBEFORE phase, to determine if interest exists and to gather suggestions for developing a formal RfC in the near future. While any interested editor is welcome, and their participation: appreciated, I am specifically requesting the most active contributors at Wikipedia:Requested moves/Technical requests to please consider the proposal and append their valued insight regarding that consideration. The 25 most active contributors are: Anthony Appleyard, Ammarpad, Lennart97, Crouch, Swale, TheAafi, GeoffreyT2000, Kj cheetham, Frayae, DrVogel, JJMC89, Ahecht, Alex 21, Nnadigoodluck, BarrelProof, Dicklyon, 162 etc., JE98, Station1, Sam Sailor, 2pou. In ictu oculi, Amakuru, Jack Frost, Buidhe, and Richard3120. In a nutshell, I am proposing that we begin to move the completed "uncontroversial requests" to a new section on the newly created moved talk page (for local handling and archival control) instead of just removing them from our project page unto relative obscurity. Such a change better aligns with our current practice regarding contested requests and significantly enhances transparency of the work that we do. While implementing this proposal will not right a longstanding wrong, or inspire utopian ways, it's not pointless change with nothing to solve or unbearable creep in disguise. It is, in my opinion, a simple change adopting a slightly better practice that arguably should have been handled this way all along. And there is a reasonable likelihood of positive collateral benefits in effecting this change as editors begin to see examples of actual "uncontroversial" requests; perhaps gaining knowledge to avoid poor-filings that generate controversy. If there is interest in this proposal, I intend to begin sandbox testing modifications to ((RMassist))'s /core and /preload parameters to automate much of this, like currently is done. Thank you for considering this, best regards and be well.--John Cline (talk) 05:54, 3 April 2022 (UTC)

Opinion survey RM/TR

General discussion RM/TR

As I've summarized on my user page and described in a conversation with Colin M, many requests brought to TR are potentially controversial and should go through the normal RM process. In my view, we need to improve how we identify controversial and potentially controversial requests that appear at TR. Mdewman6 (talk) 01:26, 8 April 2022 (UTC)
Good comments, interesting, valid, and worthwhile points. I'll comment further after work. Thank you and best regards. --John Cline (talk) 10:48, 8 April 2022 (UTC)
I would hope that the philosophy you describe on your user page is more or less the approach most use before fulfilling a TR. I can only speak for myself, but I agree with all of what you listed in the RM/TR bullet point. How is this enforced? I don't think that it's super explicit, but it would seem to be a combination of multiple steps leading to the ability to fulfill requests at the RM/TR page in the first place. Essentially:
  • In order to fulfill the requests, you must be a page mover.
  • To become a page mover, at WP:PERM/PM, the Wikipedia:Page mover#Guidelines for granting are listed as prereqs.
  • experience with moving pages in accordance with guidelines should include WP:MOVE, WP:PCM, and WP:RMCLOSE
  • Per WP:MOVE, WP:BEFOREMOVING should be followed before carrying out the technical request. (This may be the most implicit step.)
    • This includes an evaluation per WP:PCM by 1) taking an impartial view on behalf of others to see if someone may object and 2) checking the move history of each page (current and target) and any RM history that led to the current title.
  • If you are willing to handle a TR, you should also be willing to handle the WP:POSTMOVE cleanup.
I believe that "contesting" a TR, is mainly the page movers or admins believing that one of the check for a WP:PCM has failed or is too close to call and needs discussion. A contestation of a page watcher would in effect be handled by said watcher returning to RM/TR and requesting to revert an undiscussed move. -2pou (talk) 20:10, 8 April 2022 (UTC)
I agree with everything 2pou has replied to you. In furtherance, regarding the mechanism for talk page notifications of impending technical move requests, as stated: it creates a paradox where the self-evident belief that others might wish to contest the technical move request precludes the RM/TR process thereby. For this reason, the RM/TR instructions actually say: "Please do not edit the article's talk page. --John Cline (talk) 11:31, 9 April 2022 (UTC)
I also agree with 2pou. RM/TR has processes beyond blindly moving most things that get requested. I also wanted to add for when mistakes are made, there is the process to revert undiscussed moves. -Kj cheetham (talk) 13:27, 9 April 2022 (UTC)
Thanks all for your responses. It is good to know that there is some expectation that page movers/admins working at TR should be briefly reviewing the requests in light of WP:PCM and not just blindly moving pages. Unfortunately, that has not always been the case in my experience. My pointed views on the matter arise from two occasions where pages were moved at TR even though I had just moved them months prior to bring the pages in line with chemistry naming conventions and per consensus reached at WikiProject Chemicals, with detailed edit summaries to that effect being among the most recent edits of the page. A recent move for a defensible reason would definitely make a new move request 'potentially controversial' and never should have been moved at TR. I put more blame on the page movers in these cases than the mistaken users who requested the move; page movers should know better. I understand you can contest moves after the fact, and in the cases above the pages were swapped back after discussion with the requestor and page mover, but that just creates more work for everyone, messy edit history, and quite a bit of unnecessary commotion involving 3 editors over what started as a well-intentioned but incorrect request. It would be much better if we could stave off inappropriate technical requests before they are executed by sending them over to RM where the best page title can be worked out via discussion prior to any moves. Moves at TR are not simple moves and WP:BRD just can't apply in such cases. If users can't reasonably have a chance at objecting to a request prior to being answered, we must trust the page movers to use discretion when addressing the requests. Mdewman6 (talk) 00:37, 10 April 2022 (UTC)
I admit this immediately made me feel slightly defensive, as someone who has looked at the RM/TR most days in the last couple of years, and it looks like you are blaming people rather than processes for what sounds like anecdotal evidence for isolated incidents, rather than evidence of a more systematic problem. We do not want to introduce additional WP:BURO without good reason. Mistakes happen, and I'd say if the majority of requests processed at RM/TR are ok we're doing a good job. I am sorry to hear you experienced issues regarding two moves, and I hope that doesn't happen again. Most moves at TR are simple moves though, including swaps. My proposal would be to add some text and links for additional guidance on the WP:RM/TR page as part of continious improvement, but nothing further than that. -Kj cheetham (talk) 10:16, 10 April 2022 (UTC) P.S. TRs are not always mainspace article moves, for example sometimes it's a request to move a talk page that got separated from a main article, or to fix a mistake which resulted in a redirect accidently being created and wanting to avoid deleting it via the CSD route which needs an admin. -Kj cheetham (talk) 10:59, 10 April 2022 (UTC)
It was not my intention to offend anyone or come across as having ill will toward those performing moves at TR, so for that I apologize. I just wanted to raise the issue and ensure my expectations were the norm and that the experiences I described were not, and see if there are ways we might improve how TR operates. Mdewman6 (talk) 00:03, 12 April 2022 (UTC)
I agree here firmly with Kj cheetham. No evidence has been provided to indicate a systematic issue here. Polyamorph (talk) 07:34, 22 April 2022 (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.

No one reviewing my request

Kindly review my page move request, I am waiting from 2 days but no one is reviewing it. 103.141.159.74 (talk) 07:48, 26 April 2022 (UTC)

Please be patient. As you can see in the section above this one, there are backlogs that sometimes take time to process. Primefac (talk) 09:44, 26 April 2022 (UTC)

move log

Hello. Currently, if page ABC is moved to XYZ, then no move is shown in the log history of XYZ. It shown in the plain history though. But it gets sort of difficult to find the if the page has big history. Is this some sort of software limitation/issue, or is it intentional? —usernamekiran (talk) 13:47, 13 May 2022 (UTC)

It is a software limitation. It is in the community wishlist (see meta:Community_Wishlist_Survey_2022/Miscellaneous/Enhanced_Move_Logs), so it might get fixed soon. A tip: talk pages in general have fewer edits, so it is easier to find the move entry there. Vpab15 (talk) 16:02, 13 May 2022 (UTC)
I use User:Nardog/MoveHistory to view an article's move history. Ruбlov (talkcontribs) 17:10, 13 May 2022 (UTC)
thanks folks —usernamekiran (talk) 21:47, 15 May 2022 (UTC)

Missing from list?

I've been just a navigator there with no opinion. Talk:Ukrainian Insurgent Army war against Russian occupation#Requested move 30 April 2022 seems to be missing from this list? It's sort of dead/moot (even people who supported it have switched to "oppose" just to get rid of the old RM) and the discussion has successfully progressed elsewhere, but this old open RM is blocking progress. Sincerely, North8000 (talk) 01:29, 19 May 2022 (UTC)

Whether spurred by this comment or not, the discussion was closed about 40 minutes after you posted here. Primefac (talk) 07:27, 19 May 2022 (UTC)

Moratoria

Hey all,

Is there any restriction anywhere on Wikipedia of the ability of a closer to impose a moratorium on future moves? Downsides to moratoria:

  1. Worst case (when imposed in a supervote closing) they transform a mere supervote into a complete lockdown of the ability of the community to move a page, thereby circumventing our best defense against supervotes
  2. They can be inappropriate when names are in the process of changing. If we reject a move request since "sources don't call it that yet" but then sources decisively change shortly thereafter, it can end up being a very bad thing to have a moratorium
  3. In the case of a terrible nomination, moratoria can unintentionally cause essentially a strawman. Take the following example: in April, Alice proposes for car to move to automobile and says "move it because automobile is a fancier name and we're a fancy encyclopedia". The contentious discussion cites no sources and goes nowhere and Bob closes it and places a moratorium on future move requests from car to automobile. In June, Carol notices that Google News results show a clear preference for "automobile" and wants to propose a move based on common name. Why should Alice's terrible move request stop Carol's attempt to help us find the best title?

There are a few situations where I've seen moratoria be good. What are some restrictions or guidelines we can place regarding them? Red Slash 19:34, 18 May 2022 (UTC)

This doesn't seem to be a problem, and we need to be wary of WP:CREEP. Of the three situations mentioned above, all would certainly be bad, but I'm not aware of any of them ever having happened. Any closer can suggest a moratorium but they are rarely invoked because they are rarely useful and never binding. At the same time, there's a general understanding that, absent changing or unusual circumstances, similar RMs should not be re-proposed for at least several months. In unusual cases where that does happen, such RMs are usually shot down fairly quickly anyway. Station1 (talk) 21:07, 18 May 2022 (UTC)
The second one is literally happening right now at Talk:Port Elizabeth. This isn't hypothetical. Red Slash 20:40, 19 May 2022 (UTC)
Yes, that is an unusual case, but it's debatable whether the close of the 30 Sept 2021 RM (not visible on mobile devices) was "imposing a moratorium" or was advice based on the discussion. The closer wrote that "The longer editors wait before trying again, the more likely that they might be successful", which is probably true, and that the wait should be a year or "editors can fully expect that the move request will not be granted", which, as it turns out, might or might not also be valid advice. But even if the close is read as imposing a moratorium, it has been ignored, since a spirited discussion is occurring right now. Should the closer have mentioned anything even hinting that a year should pass, since that is affecting the current discussion to some degree? I don't think you'd find consensus one way or the other on that question, making it difficult to come up with a guideline. Station1 (talk) 07:48, 20 May 2022 (UTC)
I think it was clearly a suggestion and not a definite moratorium. Given that there had been three requested moves (plus a malformed one) within a six-month period, I don't think such a suggestion was out of line although six months may have been a more appropriate suggested waiting period. As for the current RM, any oppose vote citing solely the moratorium (which, again, is not a moratorium) should be discounted by whoever closes it. -- Vaulter 18:44, 20 May 2022 (UTC)
The only time I've imposed a moratorium it was because it had been explicitly discussed and had community consensus. I think it's generally a bad idea to impose one in other circumstances. But even without a moratorium in place, it can be appropriate to speedily close an RM which simply tries to reargue a recent RM, without introducing any new facts or policy arguments. Colin M (talk) 21:35, 18 May 2022 (UTC)

autoconfirmed move request

hi can someone move Jules Mutebusi to Jules Mutebutsi please. The article uses Mutebutsi constantly throughout so the title should reflect that 207.194.236.26 (talk) 15:25, 30 May 2022 (UTC)

 Not done. There's a good case to be made that the article text, not the title, should be changed. Three of the four sources cited use "Mutebusi". In the future, if you believe a move would be uncontroversial, make your request at WP:RM#TR. Controversial requests should use the WP:RM#CM process. Firefangledfeathers (talk / contribs) 15:33, 30 May 2022 (UTC)

Size of RM backlog over time

Number of active RMs over time
The same data, colored by age of discussion.

I've had a vague feeling that the RM backlog has been growing over time, and decided to see if the data would support this hunch. Though the data is spiky, I think the plots on the right show a general trend of an increasing number of active discussions over time. The current record of 299 active discussions was set earlier this month. Eyeballing the second (stacked) chart, it seems to me that the number of old discussions is increasing at a disproportionate rate. For example, let's compare numbers from today with a day 5 years ago:

The cause of this trend isn't obvious to me. Are we being more liberal about relisting? Are there not enough participants in RM discussions recently? Not enough closers? But I thought folks here might be interested in this data. It would be interesting to see how this compares to backlogs at other venues like AfD, if anyone happens to know any stats on that. Colin M (talk) 19:45, 22 April 2022 (UTC)

I think this is (in some part) a result of increased workload. The fact is that the number of RMs less than a week old is more than double than what was 5 years ago (115 vs 54). The number of RMs in 1–2 week bracket doesn't concern me either as it resembles the double workload. But, number of 2+ week RMs is far higher than expected. I think there's an issue, but don't really know where exactly to pinpoint it. CX Zoom[he/him] (let's talkCL) 21:56, 22 April 2022 (UTC)
There are also a lot of RMs for which the discussions are really poorly structured, making them difficult to close. Obvious outcomes get closed quickly, but a discussion with very little input, bad arguments, and/or participants going many different directions, tend to linger. I think we can resolve that with a rule that basically says that unless there is a determination that there is a consensus to move within some "x" period of time (say, within eight days of the last relisting), the discussion will automatically be closed as not moved. Then we set a bot to the task of closing those discussions. BD2412 T 22:44, 22 April 2022 (UTC)
I agree. But when the problem is "participants going many different directions", the closes could sometimes indicate which of the options seem viable. Johnbod (talk) 02:28, 23 April 2022 (UTC)
Change “could” to “should”, even “must”. Anyone might think they can close “no consensus”, but a good close summarises the discussion, no consensus discussions are the hardest to summarise. SmokeyJoe (talk) 04:14, 8 June 2022 (UTC)
While there may be several contributors, I do know that I have seen discussions with 2-3 relists more frequently. -2pou (talk) 02:44, 23 April 2022 (UTC)
The number of relists is way up. There are currently 101 relisted discussions. Two years ago the number of relisted discussions was in the 70s and two years before that it was in the 20s! Calidum 21:28, 23 April 2022 (UTC)
Discussions under 7 days would be better removed from the graphic. All discussions do well to be listed 7 days. Unless the cause of the larger number of old discussions is the larger number of discussions.
Yes, relisting is too liberal. Comment-free relisting does nothing useful, and is a problem because it shuffles the order making systematic review more difficult, and probably stops meaningful relists.
Comment-free relisting should be discouraged. Relists should come with an explanation for why it is being relisted, usually with a re-focusing comment, or pinging earlier participants to let them know about substantive new information or arguments. SmokeyJoe (talk) 01:46, 24 April 2022 (UTC)
Discouraging comment-free relisting would be a good idea. I believe it would also be a good idea to automatically close RM's as "no consensus" if they have been open for more than a month. BilledMammal (talk) 14:45, 25 April 2022 (UTC)
I think a comment-free relist is fine if there's been zero to say three votes, but otherwise it's probably unnecessary. Calidum 14:58, 25 April 2022 (UTC)
I don't think a rule of automatically closing old RMs as No Consensus would be beneficial. Some month-old discussions do have consensus for (or against) a move, but they linger in the backlog because they're cases where assessing and summarizing consensus is difficult, for one of a variety of reasons - for example, it may be a WP:NOGOODOPTIONS scenario, or a case where the side with the stronger policy-based arguments is a numerical minority. Colin M (talk) 15:08, 25 April 2022 (UTC)
Agreed - once you have a backlog, almost by definition quite clear closes can linger on unclosed. Johnbod (talk) 15:13, 25 April 2022 (UTC)
We can add a functionality to ((XfD relist)), so that it also works for RMs. Alternatively, we may fork a new template from it, as I did here, to easily allow adding notes, if desired. Functionality may be added to RMcloser script. Note that, current relisting technique might have to stay parallely, because RMCD bot relies on it. CX Zoom[he/him] (let's talkCL) 15:29, 25 April 2022 (UTC)
Hiya @Colin M! How did you generate these graphs? Cheers, 🐶 EpicPupper (he/him | talk) 16:43, 27 April 2022 (UTC)
@EpicPupper: I wrote a Python script to walk through the revision history of Wikipedia:Requested moves/Current discussions (table) and grab structured data about the size of the backlog at the beginning of each day going back to May 2017. The visualizations are also done in Python. I pushed the code and data to GitHub here if you're interested in playing with it. You should be able to just reuse the data from the included csv file rather than having to rerun the scraping code, unless you want to get more recent data from the last week or two. As a sidenote, if anyone was interested in data from earlier than 2017, the history of WP:RMC goes all the way back to 2009, but parsing out the relevant data is slightly trickier, which is why I used WP:RMTABLE instead. Colin M (talk) 15:19, 2 May 2022 (UTC)
Sometimes I do not understand the obvious hesitance to just close as "no consensus". Take Talk:Discord_(software)#Requested_move_2_March_2022 as an example. It has been relisted effectively three times, and judging by the dates, has been relisted even more times in practice. There is clearly no obvious consensus to move. Is it really that important to finetune the closing argument? Why not simply close as no consensus - I'm sure in a year or two the move will be requested again. (I would do this close myself had I realized how old the discussion was. I didn't, and so I instead offered my not-vote, which makes me ineligible) The argument against automatic non consensus closure after a certain point in time, that it could be that there IS consensus for a move, I find weak. That a move that actually has consensus doesn't get carried out is not the worst thing in the world. A renewed request could later point to the earlier discussion, and get the move carried out expediently. CapnZapp (talk) 05:38, 10 May 2022 (UTC)

In light of my comments (immediately above) I support suggestions that a) limit the number of relists and b) sets up a bot to auto-close as "no consensus" after a given time. It would solve all your backlog woes with nearly no casualties. CapnZapp (talk) 05:40, 10 May 2022 (UTC)

Specifically, even relisting more than once should be discouraged without good reason (and "its just not clear yet" is not a good reason. "Discussion remains vigorous and heated" is just about the only reason to hold off decision-time, and that is almost never the case with relistings in practice), and relisting twice should be the maximum allowed. The suggestion (previously suggested above) to have 30 days as the grace period before a request is automatically closed as "no consensus" feels appropriate, and I see no reason for a longer period (heck even after 14 days a backlogged discussion will exceedingly likely just languish until someone finally has mercy on it). CapnZapp (talk) 05:47, 10 May 2022 (UTC)
Yeah, having been away from RM for a few years I was surprised to see how often things get relisted 2+ times now. No consensus is a perfectly valid close. Galobtter (pingó mió) 20:39, 16 May 2022 (UTC)
Put another way, many discussions would reach a clear outcome more quickly if an additional opinion rather than an additional relisting was added to the discussion. Dekimasuよ! 03:54, 8 June 2022 (UTC)

3 weeks later

Out of curiosity, I reran the numbers just now. The total backlog size has decreased almost monotonically over the last three weeks. We had 277 open discussions when I started this thread, and today we're at 205. Almost all of this is due to a reduction in the number of old discussions - the number of discussions more than 2 weeks old went from 116 down to 58. The average age of an open discussion right now is 10.8 days, which is the lowest it's been in months. Thanks to all the closers who have helped chip away at the backlog! Colin M (talk) 17:55, 15 May 2022 (UTC)

@Colin M: dont mention it :-) I hope I could give more time to RM, but currently mrwiki takes a lot of my time. —usernamekiran (talk) 21:41, 15 May 2022 (UTC) that was supposed to be humour. I closed like 5 to 10 RMs, tops. —usernamekiran (talk) 15:44, 17 May 2022 (UTC)

6(ish) weeks later

And the back log is back. That was fun while it lasted. -- Vaulter 20:39, 11 June 2022 (UTC)

Semi-protected edit request on 25 June 2022

Under Uncontroversial technical requests please add

Thank you. 2001:BB6:4713:4858:55B4:7AF:6396:5B29 (talk) — Preceding undated comment added 10:23, 25 June 2022

 Note: Thanks for pointing that out. No need to add at RMTR as I've already moved. But please note that you can also edit the "Uncontroversial technical requests page" at WP:RM/TR. CX Zoom[he/him] (let's talk • {CX}) 11:52, 25 June 2022 (UTC)

Reinstated close after self-rev

Sorry to create work for someone, but I closed a move request at Talk:Channel 3 (Thai TV channel)#Requested move 28 June 2022 as uncontroversial yesterday. It turned out not to be uncontroversial, so I reverted my close and moved the page back. The original error was mine in interpreting the move as uncontroversial instead of letting discussion proceed, so I apologize for that. However, the editor who requested the move immediately reinstated my close and re-performed the move. I am not able to handle this now, so if someone could evaluate the situation with an eye to letting the discussion proceed as necessary, it would be much appreciated. Dekimasuよ! 02:49, 29 June 2022 (UTC)

Hi @Dekimasu:. I have moved the page back to its original location as a controversial undiscussed move and restored the RM discussion. Cheers Polyamorph (talk) 04:15, 29 June 2022 (UTC)

RM not appearing

I listed History of the Jews in Kingston upon Hull for RM, however it is not appearing on the page. I've never done an RM before, so can someone check that it is listed correctly? JML1148 (talk) 00:15, 2 July 2022 (UTC)

Nevermind, the RM decided to appear - I was being impatient. JML1148 (talk) 00:29, 2 July 2022 (UTC)

No admin instructions?

I don't frequent this page, but I became aware of a requested move that required an administrator, and I completed the move. Being a nice guy, I thought I'd come here and mark the request done so that someone else doesn't waste their time figuring out that I already did it. But, I could find no instructions anywhere on what an admin or pagemover is supposed to do when they've completed a request. Do you add a comment like  Done? Do you just delete the section? What's the norm here? It would help to add some brief instructions at the top of the page. Thanks. (For what it's worth, I just deleted the section for the requested move that I handled; if that wasn't the right thing to do, please let me know.) —⁠ScottyWong⁠— 20:56, 2 July 2022 (UTC)

For technical requests, the usual process is to just remove the section after doing the move, which I think is what you did. I agree it would be good to have some instructions on the page. Vpab15 (talk) 21:30, 2 July 2022 (UTC)
@Scottywong: The instructions are at Wikipedia:Requested moves/Closing instructions and you should be broadly familiar with those instructions before you become active closing requested moves. In the lead it says "Requests listed in the technical requests section can be simply removed after they have been processed." – wbm1058 (talk) 00:51, 3 July 2022 (UTC)
@Wbm1058: Thanks, that helps. It looks like there are some links to those instructions on the page too, I must have missed them. Disregard. —⁠ScottyWong⁠— 02:08, 3 July 2022 (UTC)

Editing that supports or oppose the rationale of a move

I would observe that, in the course of a move cycle, the status quo ante of an article may have direct bearing on the rationale of the move and on the views that might be expressed by editors during the formal phase of an RM. I would propose that during an RM, as a matter of principle, an article should reflect the status quo ante with respect to matters which relate to an RM under discussion (reasonably construed). My rationale is as follows.

These issues became apparent during Talk:Indus Valley civilisation#Requested move 8 June 2022. An RM/TR was made and immediately prior, edits were made that addressed inconsistencies in the article here. Those inconsistencies reasonably instigated the RM/TR. A TR was required. The article was moved, the move was contested as undiscussed and reverted. The RM was then initiated at 15.03 by the proposer. Shortly before, the article was edited by EditorA to restore the proposer's initial edits plus some other inconsistencies. EditorB removed other inconsistencies. The proposer then reverted to the status quo ante before their initial edits. An edit war then ensued.
The edit-warring has been dealt with and my purpose is not to revisit that particular issue but to improve the way we do things. The initial edits by the proposer and, by EditorA and EditorB either directly or closely related to the rationale of the move and were considered in the RM. For myself, I found the state of the article at the time I viewed it inconsistent wrt statements made in the RM and like. It was only by tracing back through the various edits to establish the status quo ante that matters became clear. I believe that WP generally and the RM process specifically would have been better served if EditorA had only restored the status quo ante and EditorB had not made their edit at all. This would have better served editors commenting at the RM and have averted the edit war.

For discussion. Cinderella157 (talk) 12:17, 23 June 2022 (UTC)

Might I suggest that in such cases, a link to the version at the time of the move request (what you call the status quo ante), should be added to the request using the oldid template? That way the perceived reason for the request will be easily accessible. The current version will already be linked. 2001:BB6:4713:4858:55B4:7AF:6396:5B29 (talk) 10:40, 25 June 2022 (UTC)
That could work in some circumstances but it assumes a fore knowledge of the discussion and then, who did what when (before, during or after the fact), who knows what has been done when and ultimately whether everybody is aware of these machinations in the course of the discussion. Sounds a bit like "Who's on third base?" I know, but that is the point. Furthermore, editors should not edit-war over how their preferred version of the article should look and perhaps we should avert that. Cinderella157 (talk) 11:06, 25 June 2022 (UTC)

If I understand the issue correctly, then paraphrased: We should discourage (in some manner) article edits during an RM discussion designed to influence the outcome of the discussion. There is a simple solution to that issue, if indeed it needs one. Simply make it standard practice to apply full edit protection to the article while the RM is open. I am sure the RM bot can do that—add it when the RM is listed and remove it when the RM is closed. Whether that is something the community might want to consider is another thing entirely. Mike Cline (talk) 14:28, 25 June 2022 (UTC)

Sounds like a good idea. There would have to be some kind of provision for implementing critical changes quickly, e.g. if it's a BLP and because of the increased attention it is discovered that there is something inappropriate in the article. Dr. Vogel (talk) 14:55, 25 June 2022 (UTC)
Shouldn’t be an issue as even with Full Protection an Admin can make edits to the article. Mike Cline (talk) 15:36, 25 June 2022 (UTC)
I'm not saying it's an issue, I actually think your idea is great. I just think that, because the protection could last for quite a while, there should be some kind of provision for changes that really can't (or shouldn't) wait. Dr. Vogel (talk) 01:53, 26 June 2022 (UTC)
I think WP:RFPP probably already has the mechanism to request such an edit. All we’d need to do is call attention to it in the RM boilerplate. Mike Cline (talk) 16:01, 26 June 2022 (UTC)
Mike Cline, your paraphrasing would be accurate wrt my intent. At Wikipedia:Requests for comment, I found this statement: Edits to content under RfC discussion may be particularly controversial. Avoid making edits that others may view as unhelpful. Editing after others have raised objections may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RfC is resolved. While WP:3RR is a bright-line, disruptive editing and edit warring is not limited to WP:3RR. I was actually thinking something like a statement: "If you do this you will be considered to be edit warring". Having said that, I put this up to request comments. Full protection could be an issue at very busy topical pages like 2022 Russian invasion of Ukraine‎ is now but it could also be a benefit. Some of these related pages have had multiple and almost frivolous RMs (with several snow closes). Full protection as a consequence of an RM could discourage this. Cinderella157 (talk) 04:09, 26 June 2022 (UTC)
Full protection of a page during the course of an RM? Guys, really? I know it may not be immediately obvious to the handful of us metapedians here, but the vast, vast majority of productive activity on Wikipedia consists in editing articles. To put a stay on that simply because there's a certain type of discussion going on would be immensely counterproductive. Still, making changes to an article in a way that's intended to lend credence to a particular position in that discussion is obviously bad. But it's a blurry area between that and the uncontroversial fixing of the sort of inconsistencies that spring to light in the course of such discussions. Sure, some mention of these considerations can be added to whatever is our ultimate guide to RMs, but I don't think we can realistically expect something above and beyond what we'd normally do in any other similar situation: if you edit an article in a way that may have a bearing on a given talk page discussion (or if you see someone else do that), then just make a note of that in the discussion, and that's it. – Uanfala (talk) 16:55, 26 June 2022 (UTC)
I agree with Uanfala, full protection while RM is ongoing is an overkill. Vpab15 (talk) 21:19, 26 June 2022 (UTC)

OP comment I appreciate the input but the feedback is suggesting that the protection option is overkill. I was actually considering more of an "advice" on the RM page that would identify the expected conduct and which could be cited. At Wikipedia:Requests for comment#Responding to an RfC, we have the following statement:

Edits to content under RfC discussion may be particularly controversial. Avoid making edits that others may view as unhelpful. Editing after others have raised objections may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RfC is resolved.

I would suggest something similar here and perhaps at Wikipedia:Requested moves#Commenting on a requested move.

Edits to content under for an article under an RM discussion may be particularly controversial. Avoid making edits (broadly construed) which tend to either support or oppose the proposed move. In respect to such edits, it is best to return the article to the status quo ante for a move cycle, which may commence before a formal RM is made. Editing to another preferred version may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RM is resolved. This advice does not preclude unrelated edits to improve the article.

I have referred to a move cycle since an RM may commence after a user move or request that has been contested. The status quo ante should be construed to be reasonably proximal to commencing a move cycle. Something similar might also be added to the RM banner that appears on an article page once an RM is initiated; however, I think that adding this at Wikipedia:Requested moves should be sufficient. Cinderella157 (talk) 10:20, 6 July 2022 (UTC)

Anthony Appleyard

I just heard the very sad news that Anthony Appleyard has died. He will be sorely missed by all of us at WP:RM and elsewhere. Please see the entry here: Wikipedia_talk:Deceased_Wikipedians#Anthony_Appleyard Polyamorph (talk) 18:55, 5 July 2022 (UTC)

I feared so. I knew he was in an advanced age, and he stopped editing out of the blue. May he rest in peace. No such user (talk) 06:42, 7 July 2022 (UTC)

How to club RM discussions

I am a regular RM discussions non-admin closer and today I found someone who made 2 related RMs as 2 separate requests even though it would benefit from being made as a grouped request. An example is this and this. These must've been a single grouped request.
How can I group this discussion and request systematically?
After that, I might want to relist the discussion to see new response in context of those 2 moves together. >>> Extorc.talk 09:20, 7 July 2022 (UTC)

See Wikipedia:Requested moves#Requesting multiple page moves. Unless there is new information and you are expecting a new outcome, I wouldn't see a need to relist. —Bagumba (talk) 09:26, 7 July 2022 (UTC)

Table of contents missing?

Is it me, or has the Table of Contents gone missing this past week? I find it convenient to be able to zip straight to Elapsed, Backlog or Uncontroversial RMTRs from the top of the page via the Table of Contents. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 05:09, 11 July 2022 (UTC)

It must have been this edit—I reverted it and the ToC is now back. Extraordinary Writ (talk) 05:26, 11 July 2022 (UTC)

Bot's revert

Why? Dawid2009 (talk) 13:34, 12 July 2022 (UTC)

Because you didn't use ((subst:requested move)) properly when formatting your request, which means the bot fails to see it, and manually editing the /Current discussions page is pointless since the bot will overwrite your edits. I've fixed the move request for you, so the bot should add it (and keep it added) on its next run. * Pppery * it has begun... 13:38, 12 July 2022 (UTC)

Semi-protected edit request on 15 July 2022

Indiantapsa (talk) 21:11, 15 July 2022 (UTC)
 Not done You haven't specified what edit you would like to be made. Polyamorph (talk) 21:14, 15 July 2022 (UTC)

updating links following page move

Hi guys, I dealt with this request, and shortly after I got a couple of messages that sound a bit aggressive. My understanding is the responsibility for updating links following an uncontroversial move request lies with the user who requested the move, not with the page mover. Could you let me know if I've broken any rules? Otherwise I don't understand the tone of the messages I received. Thank you. Dr. Vogel (talk) 09:46, 18 July 2022 (UTC)

To my opinion not aggressive but the truth. Moving an article after a RM is one thing, leaving the fall-out of the move to be dealt with by others is "not nice". The Banner talk 10:52, 18 July 2022 (UTC)
The responsibility for cleaning up after a move lies with the editor performing the move. For moves at RM(T), they're the ones most competent to do it (you can't expect everyone on Wikipedia to know of the some of the intricacies involved) and even when others may eventually notice the move and clean up after it, you wouldn't want to risk leaving the encyclopedia in a mess until that happens. The only exception that I can think of concerns links to disambiguation pages: if a dab page ends up with articles linking to it because of a move, the mover isn't required to fix them all (though they're still expected to e.g. make sure all the redirects point to the right places). – Uanfala (talk) 10:54, 18 July 2022 (UTC)
Yes, that's exactly the case here. The links point to Stuart Wright, which the requester explicitly said he's going to turn into a dabpage. So I don't think it's a good idea to touch it until they've had a chance to do that. But being cautious has resulted in me getting messages containing "you've done half the job" and "now do we?" which are completely uncalled for. I just don't see the point of aggression, whether you're right or wrong. Dr. Vogel (talk) 11:12, 18 July 2022 (UTC)
Leaving it to the proposer to create the dab is fine, of course. But after the rugby player article was moved, the links from navboxes should have been updated: that's done after each move, regardless of what is to become of the old title. Yes, receiving messages with a passive-aggressive tone is really unpleasant, but I hope you might also be able to appreciate that for many volunteers here it can be annoying to see an experienced editor with an advanced user right not cleaning up after their use of that user right. – Uanfala (talk) 11:45, 18 July 2022 (UTC)
I do appreciate that, but there's never an excuse for being unpleasant. The person doing the move is a volunteer too. Anyway, I've gone ahead and created the dabpage myself and I've fixed all the navboxes. Dr. Vogel (talk) 11:50, 18 July 2022 (UTC)
Having to clean up after a move is also unpleasant. I keep tab on "Templates with disambiguation links" and fixing the results of moves is a large part of what I do there. The Banner talk 11:53, 18 July 2022 (UTC)
If you find that task unpleasant, you can do a different task. There are lots of jobs on here so we can all find something that we like. Whether a task is interesting or not is subjective. Being unpleasant to a fellow volunteer, much less so. Dr. Vogel (talk) 12:00, 18 July 2022 (UTC)
Did you notice that you are now displaying the same unpleasant behaviour that you were complaining about? The Banner talk 12:10, 18 July 2022 (UTC)
There is a really wide continuum between fixing everything and just performing a move. In this case, asking for the dab to be created before making the move would be warranted. Since it wasn't done ahead of time, another way to go about this in a pinch might have been to leave the redirect in place until the dab page was created instead of suppressing it. The redirect can always be converted to a dab page afterwards. Dekimasuよ! 12:07, 18 July 2022 (UTC)
I agree. And in this case, the redirect was indeed in place until the dabpage was created. Dr. Vogel (talk) 12:15, 18 July 2022 (UTC)
I noticed that you changed the links manually. If you have to do this job in future, WP:AWB (desktop app) or WP:JWB (Javascript tool) may help save you some time and effort by automating the process. WP:DisamAssist can help when incoming links are to an existing disambiguation page. Make sure that in most cases, link update is not required outside mainspace and template space though. CX Zoom[he/him] (let's talk • {CX}) 12:11, 18 July 2022 (UTC)
Thank you. Template space is relatively easy, because one edit deals with many articles. Mainspace is a lot more complicated. I didn't know JWB existed, I'll have a look. Dr. Vogel (talk) 12:16, 18 July 2022 (UTC)
To the above, I can add three points. First, if someone demands that you fix the dab links that result from the move (apart from navboxes, redirects, free-use rationales and the like), you can point them to WP:FIXDABLINKS, which states that the mover is not required to do that. For many years this guideline used to say that movers were supposed to do that as well, so bear in mind that people may not have caught up with the updates yet and so their expectations may be different. Second, fixing links is much more important in the hopefully rare cases where one primary topic displaces another: these don't end up in the well monitored WP:DPL reports, so you can't rely on anyone dealing with them. If they're too much to do by yourself, you can leave a note about them at WT:BPAT. Third, if fixing any sort of links, semi-automated tools can be useful, but usually in limited circumstances. Whatever the tool used, the context should be examined to make sure the link is correct. The vast majority of bad links I come across in my day-to-day editing are the result of careless dabfixes. – Uanfala (talk) 12:28, 18 July 2022 (UTC)
Thank you, that's extremely useful. Now I'll know exactly what to do, and why and how. Dr. Vogel (talk) 12:33, 18 July 2022 (UTC)
DisamAssist is really good and simple to use; if you haven't used it, it runs from an existing dab page, analyses all incoming links, and offers you to resolve them to a dab page item by presenting a wikitext snippet from the source. Even if you just want to retarget the existing links, you can turn the redirect to a dab page temporarily, do the job, and restore the redirect. No such user (talk) 12:43, 18 July 2022 (UTC)

Talk:List of first-level administrative country subdivisions#Part 2

There is a move discussion in progress at Talk:List of first-level administrative country subdivisions#Part 2. 2600:1700:6180:6290:9513:4BFE:DEB0:3626 (talk) 11:28, 26 July 2022 (UTC)

Personal name Romanization rules

Hi all, I recently saw Talk:Droupadi Murmu#Requested move 24 July 2022, which in turn reminded me of Talk:Volodymyr Zelenskyy/Archive 1#Requested move 7 January 2022. Two presidents of two different countries, both of whom have an ambiguity in the correct Romanization of their names. Reliable sources, sometimes, go against the personal preferences of the subject. While WP:NCPEOPLE directly deals with self-published name changes, there isn't a dedicated policy that deals with self-published Romanised spelling, although a stretched definition of that policy resulted in Zelenskyy's name change. I was wondering if we should make it an explicit part of NCPEOPLE? CX Zoom[he/him] (let's talk • {CX}) 07:15, 31 July 2022 (UTC)

diacritics

Hello. Would it be a good idea to start an RfC to create a guideline/policy to stop using diacritics in article titles of biographies? Basically, we are an English language encyclopaedia, and we should use the names in English form. What are your opinions? —usernamekiran (talk) 13:18, 29 July 2022 (UTC)

The relevant guidelines, for anyone interested, are WP:DIACRITICS, WP:TRANSLITERATE, and WP:COMMONNAME. Currently The use of [diacritics]... in article titles is neither encouraged nor discouraged. Primefac (talk) 14:03, 29 July 2022 (UTC)
Although I personally agree that diacritics are almost never useful in article titles, it is extremely doubtful that you would get consensus for such a change to the current guidelines. Opinion is simply split. So an RfC would likely be a waste of time right now. Station1 (talk) 19:42, 29 July 2022 (UTC)
I think one place to try and find common ground would be a discussion of letters that do not exist in the English alphabet at all, rather than trying to limit diametricdiacritical modifications to existing letters. Recently there have been several moves to add non-English Latin alphabet letters to article titles, e.g. Talk:Səlahət Ağayev#Requested move 18 June 2022 (cf. User talk:Mellohi!#First Japanese Embassy to Europe) and they have generally gone through. In addition, there appears to be a strong tendency among editors participating in such discussions to privilege native spellings. If that does not represent the view of the community as a whole, it should be pointed out. Dekimasuよ! 04:54, 31 July 2022 (UTC)
I recall there were discussions a while back about Azerbaijan-related articles that went the other way. Jabrayil and Charektar comes to mind, but I believe there were others around the same time. Generally, WP:UE applies when English-language sources exist. Station1 (talk) 08:18, 31 July 2022 (UTC)

RfC: Proposed improvements to WP:RM/TR

Due to concerns raised by Onetwothreeip at Talk:Annexation of Crimea by the Russian Federation and Talk:Russo-Ukrainian War that I started the RM "without their permission", I am proposing the following two changes:

  1. Make the "discuss" links at WP:RM/TR visible only to the original requester. This would require adding a new ((CURRENTUSERNAME)) magic word (see T311794).
  2. Add a "notify requester" link to Template:RMassist/core that would either notify the requester that the discussion has been moved to a full RM (if #1 is opposed) or ask them whether they agree to start the RM (if #1 is supported).

Should we implement one or both changes? Please say below whether you support or oppose each change. If you support #2, then please also say whether you support or oppose making notifying the requester mandatory. GeoffreyT2000 (talk) 23:19, 30 June 2022 (UTC)

There is a problem though. When TRs get moved to a full RM, the original comments are copied to a new page. Currently there is a small notice to indicate this is a contested TR but I think it should be made a lot clearer so that there can be no confusion as to who initiated the actual RM. Polyamorph (talk) 15:05, 1 July 2022 (UTC)

Some are SINO some are China? Consensus?

Some articles are "Sino" some are "China"? Shouldn't there be a consensus on format for the multilateral articles.?

Sino
China

CaribDigita (talk) 02:08, 26 July 2022 (UTC)

Wikipedia should not try to fix inconsistency in the real world. Wikipedia should follow the sources. SmokeyJoe (talk) 14:56, 6 August 2022 (UTC)

Why not just abolish RMT?

Don't get me wrong, WP:RMT is a very useful venue and it works great most of the time. But there are issues: from the way contested requests are handled (see just above), to the absence of archiving (discussed in April) to the well-known fact (last briefly noted here) that requests aren't visible from the pages concerned, which occasionally results in controversial moves that take the page watchers by surprise.

I think all of these issues can be addressed in a simple big step that doesn't require significant new machinery. Just handle such requests the same way that other requests for changes to articles are handled: via the edit request system. Someone wants a page moved? They place a request on the page's talk (like that, just using a dedicated template for moves). Someone wants to contest it? Just comment in the talk page section; converting that to a formal RM will involve just slapping on the RM template – and whatever happens afterwards, that initial discussion will remain on the talk page as a visible record. Someone wants to help out with requests? Just go the maintenance category (like this one), which will have a neat sortable bot-maintained table of existing requests.

I can't think of any ways in which this system would be worse than what we have now, and there are several ways in which it will be better. Thoughts? – Uanfala (talk) 16:24, 2 July 2022 (UTC)

That's a really interesting idea. Talk-page watchers likely have a better understanding of what moves are controversial than the non-specialists at RM/TR, and as you say the proposal would deal with some of the recent problems with RM/TR. Edit requests are also probably more intuitive for newer users, many of whom will have used the process before. Certainly an idea worth thinking about. Extraordinary Writ (talk) 18:02, 2 July 2022 (UTC)
That is indeed an interesting idea. Would it be possible to list open move requests so that page movers can still monitor it? There might not be any active talk-page watchers with page mover rights. Polyamorph (talk) 18:14, 2 July 2022 (UTC)
I think the idea is that you'd be able to watchlist a category (like Category:Wikipedia template-protected edit requests) and/or a bot-updated page (like User:AnomieBOT/TPERTable), just like we currently do for regular edit requests. Extraordinary Writ (talk) 19:25, 2 July 2022 (UTC)
Some kind of list of specifically edit requests for page movers would be essential for something like this I think. -Kj cheetham (talk) 19:20, 4 July 2022 (UTC)
I love Uanfala's idea. Dr. Vogel (talk) 20:49, 2 July 2022 (UTC)
Has good merit. Though I can see merit in explicitly closing the TR and the proposer formally opening an RM rather than this automatically moving to RM (all done on the article TP). That was the issue identified by Uanfala in the RfC above (#RfC: Proposed improvements to WP:RM/TR). If the TR is closed as failed I would see three options. The first is no further action. The second would be to reinitiate the TR as an RM without change. The third is to open a RM ab initio. As identified at the RfC, it is reasonable that a TR might be briefly stated and in moving to an RM it would be reasonable to make a case in more detail and/or to refactor the proposal in light of the comments contesting the TR. To summarise, the OPs proposal isn't a solution in itself but part of a total solution. — Preceding unsigned comment added by Cinderella157 (talkcontribs) 02:29, 3 July 2022 (UTC)
I agree with the idea. When an editor attempts to move a page, but they can't because of lack of rights, then they should be asked to use a technical move request system similar to the current edit request system. This will notify the page watchers, who may contest such a move before it is performed. If the move is contested, the TR fails, and a full RM would be required. Page movers will also be able to track changes if a list similar to User:AnomieBOT/TPERTable is maintained. CX Zoom[he/him] (let's talk • {CX}) 09:42, 3 July 2022 (UTC)
I agree, this idea makes a lot of sense. Adumbrativus (talk) 06:51, 6 July 2022 (UTC)
I have a concern that the watchers (and executors) of RMTR are generally page movers and admins with deep knowledge of WP:AT and best RM practices (although they have rarely subject matter knowledge), so requests are executed or disputed with a high degree of consistency. Moving the process to edit request system might result in haphazard and inconsistent decisions by random passers-by who may be versed with the article subject, but not with best AT practices.
However, I also share Uanfala's concerns about the current process from the RfC above. Perhaps we can have the best of both worlds (advertizing move on article talk page and have it displayed at RMTR): let's expand ((Requested move)) so it accepts technical=yes argument (nominator asserting that the move is uncontroversial), and have RMCD bot listing those in WP:RMTR separately from regular RMs, so that RM watcher crew can see it like any other RM. If anyone disputes the move within a reasonable timeframe, they can do so on the article talk page, and the "technical" RM converted to a full RM. Obviously, there are details to work out, but you get the idea. No such user (talk) 07:41, 6 July 2022 (UTC)
The having it in both places makes sense. After all, a dedicated category could be followed on watchlists, or if needed a flag might allow a bot to post them onto an RMT subpage (which could also be watchlisted), much as Legobot does for GANs. CMD (talk) 07:44, 6 July 2022 (UTC)
That sounds like a useful refinement of a good idea. It brings a new process (I'll call it "Tech Move" for now) which is to RM as speedy deletion (SD) is to AfD. Just as a SD normally results in either deletion or an AfD discussion, depending whether a sympathetic admin or an objector gets in first, so Tech Move can result in either a speedy move or a full RM. We could insert a short waiting period like the 48-hour delay at CfD/S, but that's probably unnecessary. Certes (talk) 13:33, 7 August 2022 (UTC)
@Uanfala: I think this proposal has good local consensus. Would you following up on this? It's been about a month. CX Zoom[he/him] (let's talk • {CX}) 07:29, 31 July 2022 (UTC)
I've been a bit busy lately. Anyone interested in taking this up? I'd be delighted if they do! Uanfala (talk) 10:14, 31 July 2022 (UTC)
The 'best of both worlds' proposal by No such user sounds best to me. Polyamorph (talk) 18:37, 31 July 2022 (UTC)
I posted at Wikipedia:Bot requests#Bot_supporting_revised_technical_move_request_process to see if there's interest from those more familiar with bot implementation. Adumbrativus (talk) 00:24, 7 August 2022 (UTC)

Wikipedia:Requested moves/Technical requests/Instructions

Do we need the text "Do not request technical assistance on this page if you can do it yourself." added by User:WhatamIdoing in 2019? In some cases it may be a good idea for moves that could potentially be controversial or questionable but are not clearly controversial or questionable, the user may just want to see if they get contested or another pair of eyes thinks the move is OK? Crouch, Swale (talk) 19:07, 3 August 2022 (UTC)

@Crouch, Swale, you should not ask for specifically technical assistance unless you actually need technical assistance. For potentially controversial or questionable moves, you should use Wikipedia:Requested moves#Requesting controversial and potentially controversial moves.
To put it another way, if the problem is "I'm having software/computer problems with making this good move", then you need to request technical assistance. If the problem is "Maybe people will think this move is a bad idea", then you need to use the "potentially controversial moves" system. If that's not clear from the page, then maybe the PCM section should be moved higher than the technical assistance section. WhatamIdoing (talk) 19:16, 3 August 2022 (UTC)
I concur with WhatamIdoing. -Kj cheetham (talk) 10:29, 14 August 2022 (UTC)

has the bot stopped?

If I am reading this correctly, there have been no new listings for over 14 hours (since 14:12 yesterday); and I know there has been at least one request because I made one at Talk:Wendy Smith-Sly over an hour ago (3:24). Has the bot stopped? Adpete (talk) 04:52, 14 August 2022 (UTC)

The issue was earlier raised at User talk:RMCD bot#Bot not running. The bot operator has let us know that "bot-assisted updates will be limited over the next few days". So, the lists may take more time than usual to receive an update. CX Zoom[he/him] (let's talk • {CX}) 06:39, 14 August 2022 (UTC)
While we wait for the bot to recover, I have been manually updating the list since a couple of hours ago. I have gone through Related changes of the Category:Requested moves category, and have backfill with what I could find and updated the list with new ones as well. If there's any missing, either add them to the list yourself, or let me know if you are unsure of the formatting. – robertsky (talk) 11:19, 14 August 2022 (UTC)

Smethwick Khalsa Football Federation F.C.

Smethwick Khalsa Football Federation F.C., an English football club, has reverted its name back to Smethwick Rangers F.C. As this was a former name of the club and the club's page has been formerly moved from that original name, I am unable to move it back to Smethwick Rangers F.C. COYB01 (talk) 20:14, 14 August 2022 (UTC)

@COYB01: If the move is uncontroversial, you can list it at WP:RMTR. Certes (talk) 21:43, 14 August 2022 (UTC)

The problems with primary topic RMs

For some time now, I've been taking part in RMs that involve primary topic questions. This naturally presupposes that I don't find these discussions to always go well (otherwise, why would I be wasting my time when things would be perfect without me anyway?). Still, I often find them to be disappointing to a greater extent that anything else on this project. From my point of view, there seem to be three main reasons for that:

  1. Varying (mis)conceptions about usage. The guidelines are pretty clear about what "primary topic with respect to usage" means, and it's usually up to common sense whether and how each of the tools listed there could be used in each situation. The trouble is, people will often use those tools regardless of the extent to which they allow any meaningful inferences about usage as defined in the guidelines. For example, it sometimes happens that a direct measure of relevant usage (as available in some of the recently developed tools) is ignored, and instead the emphasis will fall on familiar but very indirect proxies, like pageviews. I think the assumption that people would use common sense is not tenable anymore, and what we'd need to do is spell everything out. Maybe time to make the guidelines even more explicit and also add an explanatory supplement that details how each of the tools can be used in each set of possible circumstances? There's already an essay about pageviews at WP:PPT, and I'm thinking of doing one on the technical aspects of Wikinav, but we need a central document that a) explains everything, b) has community support, and c) can easily be cited in discussions (maybe the very rudimentary WP:PT/U could serve as the starting point for that?).
  2. Inherent bias among participants. Primary topic questions involve deciding whether one topic is more significant/notable than all the other, unrelated, topics with the name. But the way these RMs are advertised, they attract participation from the editors of the (proposed or existing) primary topic article (as well as its wikiprojects), but not from any of the contender topics. If someone has spent a good deal of time contributing to an article on a topic they care about, chances are they wouldn't be very happy at the suggestion that their favourite topic isn't as significant as a bunch of other topics that they don't really give a fig about. I think that's the greatest source of heat in those discussions, and probably the main motivator for people to bend common sense when interpreting #1.
    What can be done about that? Maybe closers need to be aware of this participation bias and try to compensate for it (but that's a tall order). Notify all articles that challenge a primary topic? That's going to increase the heat even more, and there's no reason to suppose that several competing "wrongs" would necessarily cancel out to create something that's "right". A change of format maybe? For proposed primary topics, there's probably no reason to notify the article at all: a title change from "Foo (bar)" to "Foo" reflects broader wikipedian considerations and is just a formality as far as the article itself is concerned. Moves in the other direction – from "Foo" to "Foo (bar)" – will still need to be advertised as now: the editors to an article should obviously still have a say on the choice of disambiguator. But maybe these discussions could go in two phases. First, it gets decided whether there is a primary topic: this can be done at a centralised project page, free from partisan input; once that's decided, then an RM can be started on the article's talk page with the sole aim of agreeing on the best disambiguator.
  3. Closures. In my experience, most closures are good and some closers are consistently excellent, but I feel like there's still a tendency among a subset of experienced closers to preferentially count votes. Such a tendency exists throughout Wikipedia, but I think it leads to worse outcomes for RMs because it amplifies the effects of #1 and #2. If those two get addressed, then this one wouldn't be that much of an issue. But still, what can be done? Encourage other competent editors to start closing? Or change some of the expectations? We could be a bit more tolerant of backlogs so that closers don't feel like they have to close any particular discussion: when there's a mismatch between vote count and strength of arguments, it may for example be more helpful for a potential closer to instead participate in the discussion and so help sway the balance.

Well, this is just me. What are others' observations about problems with this sort of RMs? Thoughts about the suggested solutions? How about other possible ones? Uanfala (talk) 13:04, 6 August 2022 (UTC)

A problem that feeds these problems is the bad old idea and practice of DABNAME and MALPLACED, which means that if there is no PrimaryTopic, the disambiguation page goes at the basename. This is bad because disambiguation pages at basenames cause several problems. To avoid these problems, editor like to overgenerously assign PrimaryTopic to one of the alternatives. In doing so, the PrimaryTopic intent is corrupted, with spin-off problems around.
The solution is to repudiate DABNAME and MALPLACED, and for dab pages like mercury to be at Mercury (disambiguation), with the basename redirecting to it. Then, editors will not need to contrive PrimaryTopic arguments where there is no PrimaryTopic. SmokeyJoe (talk) 14:54, 6 August 2022 (UTC)
What problems are created by having the dab page at the basename? Firefangledfeathers (talk / contribs) 12:56, 11 August 2022 (UTC)
I'm not sure about this, but I suspect that if all dab pages were at Example (disambiguation) (with Example redirecting there when suitable), we might get fewer accidental links to dab pages. WhatamIdoing (talk) 20:49, 15 August 2022 (UTC)
Such links appear when someone writes Mercury is a metal without bothering to check where the link leads. Unfortunately, that will remain true whether Mercury is a dab, a redirect to dab or an article on a "wrong" topic (such as the planet). WP:MALPLACED is also being debated yet again at Wikipedia talk:WikiProject Disambiguation/Malplaced disambiguation pages#The problems with MALPLACED?. Certes (talk) 10:58, 16 August 2022 (UTC)
I don't see these as problems that require changes to the requested move process. 1 can be countered with better usage arguments (assuming that your premise is correct); 2 is unavoidable, all RMs are listed here and if uninvolved editors don't participate, there's little we can do about it; and 3 already has a solution in WP:MRV. IffyChat -- 17:33, 6 August 2022 (UTC)
Uanfala, I do think it would be good to have a centralized discussion on how/when to use pageviews vs. navigation data or Wikinav. This may have happened already and I missed it. I have a barely-informed opinion—having seen your argument presented at a few RMs—that Wikinav is an amazing tool but not one whose existence means we deprecate the use of pageviews. On your point about bias: I think it's a good idea to notify the talk pages of all articles tied to a name when we're having a PTOPIC-based debate. In general, I share your view on the damaging bias that inevitably pops up, but it's a kind of selection bias that affects most discussions on Wikipedia and I don't have great ideas on how to remedy it. Firefangledfeathers (talk / contribs) 12:56, 11 August 2022 (UTC)
Two comments.
  • I see WikiNav and pageview data as examining two different angles of usage, and both have their limitations (many of us struggle with trying to account for so many of WikiNav's omissions and WikiNav also vomits when trying to get results for little-visited pages). Pageviews provide a partial answer to what subject is more popularly known to Wikipedia readers than others, while WikiNav deals with traffic movement.
  • I'd assume the bias problem can be partially relieved by having RMCD bot notify every article disambiguated through a dab page any time a dab page is nominated for moving.
Ceso femmuin mbolgaig mbung, mellohi! (投稿) 19:10, 12 August 2022 (UTC)

Permalinks in prefilled edit summaries

Any ideas about why the permalinks go wrong? I did a move just today and the prefilled edit summary linked a permalink dating back to 9 August 2022. This move that I made two days ago also has a similar problem. I'm sure this is the case with most of the prefilled edit summaries. Any cure to that? ─ The Aafī (talk) 17:05, 18 August 2022 (UTC)

They're broken because Bot1058, which was previously updating Wikipedia:Requested moves/Technical requests/Permalink, went down on August 9, 2022. Not sure how to fix the problem, though. * Pppery * it has begun... 17:08, 18 August 2022 (UTC)
I created a script (User:CX Zoom/scripts/UpdateRMTRpermalink.js), which, if installed, will update the permalink subpage automatically whenever the user goes to Special:BlankPage/UpdateRMTRpermalink. I hope to request at WP:IANB to move it to MW namespace, so that a ?withJS= link can be added in ((RMassist/core)), which will allow page movers to update it without installing it. CX Zoom[he/him] (let's talk • {CX}) 15:36, 19 August 2022 (UTC)
Wait, I see that bot operator is active again, maybe they can fix the bot. pinging @Wbm1058. CX Zoom[he/him] (let's talk • {CX}) 15:56, 19 August 2022 (UTC)
Sorry this bot's down. I don't have a robust backup at the moment. Things should be back to normal within a few days. wbm1058 (talk) 01:31, 21 August 2022 (UTC)

Bot missed a proposed move

I think I correctly proposed a move at Talk:AMG/Parade but the bot doesn't seem to have added it to the main discussion list. It has been more than 12 hours. I am not good at this so please let me know if I am doing it wrong and how to do it better. Is there something more I have to do to get the bot to work? Thank you! 72.66.54.194 (talk) 00:58, 21 August 2022 (UTC)

I wonder if the subpage structure (the slash in the name) is incompatible with the bot. Dicklyon (talk) 01:18, 21 August 2022 (UTC)
Sorry, bot updates will still be limited for a few days more. This one has been processed now. – wbm1058 (talk) 02:27, 21 August 2022 (UTC)
@Dicklyon@Wbm1058Thank you for the help! @DicklyonI replied to your comment on the discussion page!
72.66.54.194 (talk) 04:50, 21 August 2022 (UTC)

change name

Please change name of AlAlamein International University To Alamein International University source:https://aiu.edu.eg/ YoussefBadreldin22 (talk) 14:38, 22 August 2022 (UTC)

 DoneI've boldly moved this, as it seems correct per the organization's own website. - UtherSRG (talk) 14:50, 22 August 2022 (UTC)

Request

Hi. Can you move this article from Ramadan revolution to 8 February coup 1963 John576424 (talk) 17:41, 24 August 2022 (UTC)

 Not done Please see WP:RM#CM to create a move request. I have reverted some of your changes, sice they are controversial and have not been discussed. Please discuss on the article's talk page before making controvserial changes in order to get WP:CONSENSUS from other editors. Vpab15 (talk) 17:52, 24 August 2022 (UTC)

non-controversial non-move request

the TX-0 was an early and influential computer. The page is at the appropriate URL https://en.wikipedia.org/wiki/TX-0 but if you click, when you land on the page the title shows up on the page as TX-o with the lowercase letter-o ; it should be TX-0 with the digit zero. Not precisely a move, but from what I understand, shouldn't this title be coming from the URL-name?

edit: I thought I'd check the history, the page was originally created in 2002 with this same flaw 2603:8001:D300:A631:0:0:0:10D0 (talk) 03:00, 30 August 2022 (UTC)

The issue is the funky fonts used by the default legacy Vector 2010 skin. I created the redirects for the upper-case O TX-O and lower-case o TX-o so you could compare the differences in their appearance. Also note from the TX-1 article how this default font renders numbers smaller-sized than letters in article titles. Try changing to another skin such as Monobook which uses a less-funky font and the title should appear more "correct". – wbm1058 (talk) 14:00, 30 August 2022 (UTC)
It is not a vector legacy issue tbf, renders completely normally on my devices. CX Zoom[he/him] (let's talk • {CX}) 21:06, 30 August 2022 (UTC)
oh, I see, you're right it is a zero, just a short, squat one. FWIW I'm seeing the problem using up-to-date generic both Chrome and Firefox on Fedora Linux. (and I have no idea where skins live in wikipedia, but back in the days of WinAmp I considered the birth of skins to be the death of everything good about computers so I probably won't track them down. However I did use the "view - no style" option in Firefox and the problem goes away in that mode.) Thanks for looking into this. 2603:8001:D300:A631:0:0:0:10D0 (talk) 21:29, 31 August 2022 (UTC)
I don't know what's causing this. When I used vector legacy in desktop mode in android device, it showed "TX-0". On an actual desktop, using the same skin and mode, I also see "TX-o". Although, I don't know what's causing this. CX Zoom[he/him] (let's talk • {CX}) 21:50, 31 August 2022 (UTC)
I submitted it as a move request cuz I sorta thought moving it to something else and moving it back might fix it. But that's just a thought, I have no idea. 2603:8001:D300:A631:0:0:0:10D0 (talk) 09:35, 3 September 2022 (UTC)
Due to the relative height of "0" (zeroes) in Wikipedia article titles in some devices, it may sometimes appear as "o" (lowercase o)
I assume that this is font style issue. On my desktop (above) the zero in the title is smaller than "t" and about half the size of "h" giving the impression that it is lowercase "o", like an optical illusion you may say. Here the number "1" is also the same height as "0", in fact all numerical digits are this height. But it's presence right beside the zero helps the reader understand that it is in fact a zero and not a lowercase "o". In your case, the title TX-0 was devoid of any other similarly small sized digit nearby, leading to the impression that it's a lowercase "o". Using the same skin on other device (below), "10" is actually taller than even "t" and there is no ambiguity. There are other small differences too, like the shape of "s", the ratio of upper and lower halves of "e", etc. indicating that for whatever reason, different devices are displaying the title in different fonts, and that is causing the issue you had seen. CX Zoom[he/him] (let's talk • {CX}) 11:23, 3 September 2022 (UTC)
good call, thanks. 2603:8001:D300:A631:0:0:0:1D29 (talk) 07:18, 4 September 2022 (UTC)
When I log into Wikipedia, I use the MonoBook skin from preferences/appearances and the 0 looks like the same height as some capital letters. While not logging in, the different font makes it look like the 0 is an o, definitely. When pasting the article title, the font is of Georgia type while the MonoBook version uses Helvetica. I can't remember when the font of article titles was changed. Iggy (Swan) (Contribs) 08:50, 4 September 2022 (UTC)

Natatorium

Since the discussion is gone, the AFD entry is here: Wikipedia:Articles for deletion/Natatorium Polyamorph (talk) 17:09, 6 September 2022 (UTC)

Semi-protected edit request on 9 September 2022

On the Sept. 8 section, remove the support comment by User:Jèrriais janne as it has been already properly posted at Talk:Camilla, Queen consort of the United Kingdom#Requested move 8 September 2022 and this is only intended to list discussions. - 2001:4453:54A:CA00:4D65:6655:3B86:9168 (talk) 14:19, 9 September 2022 (UTC)

That section just lists the currently open move requests. The list is automatically maintained. The entry for Camilla will be removed once the move request is closed. Vpab15 (talk) 14:28, 9 September 2022 (UTC)
I have fixed the indentation of Jèrriais's support comment, hopefully the bot will fix it in the list as well. Vpab15 (talk) 14:31, 9 September 2022 (UTC)
Ah, I see, It was due to formatting issues in the source talk page and the bot got confused. Thanks for looking at this. Just to clarify, I am not requesting to remove the nom's remarks but just that stray comment that should stay in the talk page. Thanks! 2001:4453:54A:CA00:4D65:6655:3B86:9168 (talk) 14:36, 9 September 2022 (UTC)
No worries. The bot has now corrected the entry. Thanks for raising the issue. Vpab15 (talk) 15:17, 9 September 2022 (UTC)

Caret: arbitrary and unilateral page move

The following discussion 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.


Steel1943 has unilaterally declared that the (mis)use of the word caret by programmers makes their definition the wp:PRIMARYTOPIC, and has made the following series of moves without any prior warning, discussion or consultation as if it is a trivial technical move:

Meanwhile in the real world, caret is the common name for the insertion symbol U+2038 CARET and is the first experience of most school children. I object to such arbitrary behaviour and request support to reinstate to the status quo ante pending an adult discussion. John Maynard Friedman (talk) 20:16, 15 September 2022 (UTC)

Blame Fgnievinski for changing the primary topic; all Steel1943 did was change from "Caret" redirecting to "Caret (computing)" to the other way around, which was procedurally correct * Pppery * it has begun... 20:24, 15 September 2022 (UTC)
Also see https://en.wikipedia.org/w/index.php?title=Wikipedia:Requested_moves/Technical_requests&oldid=1110467498. -Kj cheetham (talk) 20:26, 15 September 2022 (UTC)
(edit conflict) @John Maynard Friedman: Your assumption couldn't be more wrong. Caret was a redirect towards Caret (computing) for about 6 months. I moved the page in response to a request on WP:RMTR by Kleinpecan (as seen in the very edit history you referenced) after a series of edits was performed by Fgnievinski on 7 March 2022. The move was technical in nature due to Caret being a redirect towards Caret (computing) for 6 months. All edits I did on the disambiguation page were per MOS:DABPRIMARY in regards to the current situation. In other words, next time you point a finger, make sure you are pointing it at the correct editor since the finger should be pointed at Fgnievinski ... well, that, and I agree with you, and would probably support any move request that changes the current status quo. Steel1943 (talk) 20:29, 15 September 2022 (UTC)
@Steel1943: I apologise for questioning your good faith, it is just a pity that you didn't leave an explanatory note that might have saved my blushes. Obviously your procedural move was entirely reasonable in the circumstances. I don't propose to dig myself in any deeper. --John Maynard Friedman (talk) 20:48, 15 September 2022 (UTC)
I responded to this at Talk:Caret#Arbitrary and unilateral page move to avoid repeat discussions. Steel1943 (talk) 20:57, 15 September 2022 (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.

Respecting editors selection of "discuss = no" for technical requests

When an editor selects "discuss = no", that needs to be respected, and if the request is rejected simply removed without action. There have been a few times now that I've made technical requests, deliberately set "discuss = no" as I would want to write a different request if it is rejected, only for other editors to change that to "yes" and open a move request in my name - I would actually consider that to violate WP:TPO, as it results in the meaning of my comment being changed.

I'm not sure where we can clarify this, but it needs to be clarified somewhere. BilledMammal (talk) 00:08, 5 September 2022 (UTC)

Completely agree. The same thing happened to me a while back. Station1 (talk) 05:16, 5 September 2022 (UTC)
I also agree, not sure how best to enhance the wording to support this though. -Kj cheetham (talk) 16:46, 11 September 2022 (UTC)
As you say Kj cheetham, the instructions when posting say "if you do not wish the request to be converted into an RM if contested, then add |discuss=no". This should be respected. I did actually convert a "no" to "yes" one time, purely for ease of creating a RM discussion. But I didn't think about the consequences at the time that this was wrong because it meant I had initiated a discussion on behalf of BilledMammal which they had expressly asked not to. I'm sorry about that BilledMammal, it was a while ago, but it's not something I've done since or would do again. Polyamorph (talk) 19:43, 12 September 2022 (UTC)
Because the instructions are to substitute the template, can the template substitution logic simply be modified to include a commented note, something like | discuss = no <!--This is intentional. Please do not change without requestor's consent per WP:TPO.--> | reason = ... ? -2pou (talk) 20:57, 12 September 2022 (UTC)
If that would work then why not? Polyamorph (talk) 20:21, 18 September 2022 (UTC)

Request

Filmmaker Charlie Lyne now goes by the name Charlie Shackleton, as noted on his Twitter account in 2019.[1] His professional profiles, including website, Sight & Sound[2] author page and IMDb profile,[3] have all been updated to reflect this. The change of name is already reflected in the article. 80.194.19.91 (talk) 09:15, 22 September 2022 (UTC)

References

  1. ^ [hhttps://twitter.com/charlieshack/status/1181943166360047617 "Charlie Shackleton on Twitter: For a long time now, I've regretted a decision I made about 15 years ago, when—in a fit of teenage reinvention—I stopped using my mum's surname, Shackleton, and started using my dad's, Lyne. (My mum raised me after my dad left us when I was a baby.)"]. Twitter. Retrieved 9 September 2016.
  2. ^ "Charlie Shackleton". BFI. Retrieved 22 September 2022.
  3. ^ "Charlie Shackleton". Internet Movie Database. Retrieved 9 September 2016.
Request moved to Talk:Charlie Lyne#Requested move 25 September 2022 for discussion, due to lack of response or action here. CX Zoom[he/him] (let's talk • {CX}) 19:18, 25 September 2022 (UTC)

Moving editnotices alongside the subject page

There is a discussion at Wikipedia:Village pump (technical)#Moving editnotices alongside the subject page that might be of interest to watchers and participants of this page. You are requested to leave a comment, or suggestion there if you would like to. Thank you! CX Zoom[he/him] (let's talk • {CX}) 08:34, 26 September 2022 (UTC)

Relisting comment

Just to note that User:TheTVExpert/rmCloser which I see is the most often used tool for RM closes and relists, has been updated to include a comment box on clicking "Relist". CX Zoom[he/him] (let's talk • {CX}) 17:46, 30 September 2022 (UTC)

Lucas de Bolle

Hi everyone,

I tried to follow the instructions for this page:

https://en.wikipedia.org/wiki/Draft:Lucas_de_Bolle

I got an error message that I've tried to action. I've no idea though if that has worked. Any help would be great.

Thank you. — Preceding unsigned comment added by Bonjofan (talkcontribs) 12:27, 2 October 2022 (UTC)

Change to WP:RMTR template in regards to contested requests

Just wanted to make WP:RMTR regulars aware that I made this edit to the ((RMassist)) template (specifically ((RMassist/preload))) that affects the way a contested discussion is posted on the respective talk page. Further details can be found at Template talk:RMassist#Edit performed on Template:RMassist/preload regarding time stamp, as well as the linked edit's summary. Steel1943 (talk) 20:31, 7 October 2022 (UTC)

Good idea. I just opened one at Talk:Ullibarri-Gamboa#Requested move 7 October 2022—let's see if it works! Extraordinary Writ (talk) 20:37, 7 October 2022 (UTC)
Looks like it worked. Many thanks for taking the time to fix this: I was complaining about it just the other day! Extraordinary Writ (talk) 20:52, 7 October 2022 (UTC)
Time to withdraw your complaint. Thanks a lot Steel1943. CX Zoom[he/him] (let's talk • {CX}) 21:34, 7 October 2022 (UTC)
Thanks! I had no idea this was bothering anyone else! I'm thinking there may still need to be some sort of comment indented one level after the nomination comment to separate any relative RMTR discussion, but since the more pertinent problem is fixed for now, that great! Steel1943 (talk) 01:23, 8 October 2022 (UTC)

Inquiry about Mass move form

Per WP:MASSMOVE multi-page move is limited to 100. There's an ongoing discussion about as many as 1600 pages in one batch. Does one have to manually fill out the form for all 1600+ pages or can it sped up with the use of a bot or some other means? Qwerty284651 (talk) 14:04, 10 October 2022 (UTC)

See User talk:Tol/Archives/2022/10#Article Alerts archive page moves. Hellknowz has already requested that the said pages be moved by TolBot, a bot operated by Tol. The request is currently pending a BRFA. CX Zoom[he/him] (let's talk • {CX}) 15:41, 10 October 2022 (UTC)
Thanks. Qwerty284651 (talk) 17:49, 10 October 2022 (UTC)

Where can I request relist of RM at Gautama Buddha?

Hello, where do I request relist of the RM for Gautama Buddha? It's currently in section WP:RM#October 5, 2022, and due to lapse in a few hours (or maybe already has by the time you read this). The RM discussion is at Talk:Gautama Buddha#Requested move 5 October 2022. Although there are a dozen !votes or so, it seems mostly like a lot of unsupported opinion (on both sides) or evidence-free policy claims, with nothing really solid to base a close on. Votes are still coming in, and I'd like to research some data first, but that will involve a day of investigation, and will put me past the time limit. If we had a week, that would (hopefully) be enough to attract some more voters (either way) who will base their opinion on actual data, and policy. Thanks. (And, where *is* the right place to request relist? Nothing is mentioned at WP:RMRELIST, and I tried editing the October 5 section, but hit edit notice which waved me off—I understand that that is the wrong place, because my comment would get overwritten by the bot. So where, then?) Time-sensitive, so adding @Robertsky and CX Zoom:; thanks, Mathglot (talk) 05:40, 12 October 2022 (UTC)

Thanks for the relisting. Will work on it over the next day or two. Mathglot (talk) 07:22, 12 October 2022 (UTC)
@Mathglot done. Without using the RMcloser script, relisting is essentially done by appending the ((subst:relisting)) template at the end of the opening section/paragraph, after the OP's signature, in the article's talk page. The bot will pick this up in the next run and update WP:RMC and other related pages. – robertsky (talk) 07:41, 12 October 2022 (UTC)
Thanks! Mathglot (talk) 07:43, 12 October 2022 (UTC)

To page movers

Hello,

Just a comment to the page movers out there, when deciding whether or not to leave a redirect during a page move, please check "What links here" and see if there are redirects to the page you are moving. If there are, and there are often are, by not leaving a redirect, you are creating broken redirects which then have to be deleted. But if there are redirects that exist to the page that will be moved and you leave a redirect when you move that page, then the Wikipedia bots can correct those existing redirects to point to the new target.

Additionally, if for some reason you don't want to leave a redirect during a page move and there are broken redirects, it would be very helpful if you either changed them yourself so they weren't broken or if you would tag them for speedy deletion. Thank you! Liz Read! Talk! 19:37, 25 September 2022 (UTC)

Indeed, no-one wants broken links being being created when they don't need to be. Also page movers should be aware of WP:PMRC, as there's only a limited number of valid reasons to not leave a redirect when moving pages. -Kj cheetham (talk) 20:39, 25 September 2022 (UTC)
Liz can correct me if I am wrong, but the issue this time may have been that sometimes redirects that have no preexisting talk pages are involved in round-robin moves. When one of those redirects ends up at the original title and no talk redirect is created, it breaks links to the existing talk page. Moves that result in broken talk pages / talk page archives are a fairly common issue worthy of a reminder. It's more of a cleanup problem than a behavioral issue like the active repression of appropriate redirects when performing one-way moves. Dekimasuよ! 06:54, 26 September 2022 (UTC)
Ahecht's swapper thankfully allows for the quick creation of the appropriate talk page redirects in round-robins. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:31, 12 October 2022 (UTC)
Not for talk page archives though which also get moved without leaving redirects, leading to broken links. On conversation with Ahecht, I realised it is intentional, especially when double-swapping changes the scope of parent talk page. CX Zoom[he/him] (let's talk • {CX}) 20:44, 12 October 2022 (UTC)

Multiple relists

I'd be interested to hear people's thoughts on the question of when RMs should be relisted more than once. I generally don't do it unless there's a particularly compelling reason (e.g. when someone has made a new argument that others haven't had time to consider), but recently I've seen plenty of folks relisting for a second or third time just to attract more participation, for instance here and here and here and here. WP:RMRELIST says that "In general, discussions should not be relisted more than once before properly closing", but it also notes that "Despite this, discussions are occasionally relisted more than once". Is there any interest in loosening that language so as to make multiple relists more commonplace (as is the case at AfD and many other venues), or do we still feel that second relists should be the exception rather than the rule? I don't feel strongly either way—I just want to make sure that what I'm doing is in line with current consensus. Cheers, Extraordinary Writ (talk) 03:35, 20 September 2022 (UTC)

Nearly all RM relisting is busywork, a waste of time, and creates more confusion than help. Waste of time relisting is squarely comment-free relisting. Comment-free relisting adds noise and shuffles the listing order. A useful relisting necessarily includes a meaningful relist comment, such as a refocusing comment for a defocused discussion, or a note that there is new information since the early votes and it pings the early voters to come back and reconsider their votes in light of the new information. Relisters should only be qualified intending closers who on looking at the discussion see that for some reason it is not ready for closing.
The four examples are pointless comment-free relists that should not have been done. SmokeyJoe (talk) 23:13, 20 September 2022 (UTC)
Sorry boss. I strive to do better the next time round. On a more serious note, some re-relists were faults of mine for not pinging the wikiprojects earlier. And yes, terrible busywork, self-afflicted. – robertsky (talk) 15:47, 22 September 2022 (UTC)
So, some relists were done because important notifications weren’t done, and you just did them? It’s important to explicitly state that, so that the newly notified people get their seven days. Many people think that a relist means the discussion gets another seven days from the date of relist, and this is not true, another closer may decide to close even immediately after a comment-free relist. SmokeyJoe (talk) 21:50, 22 September 2022 (UTC)
At the risk of WP:BEANS, notifying a WikiProject doesn't automatically mean seven added days either. If it did, that would lead to a lot of gaming the process. Dekimasuよ! 13:58, 23 September 2022 (UTC)
If someone thinks a missed notification means the discussion seven day minimum needs to be reset, they should say so in the relist comment. A new notification doesn’t automatically justify a relist, let alone a timer reset. SmokeyJoe (talk) 23:21, 23 September 2022 (UTC)
The table at Wikipedia:Requested moves/Current discussions (table) can be sorted by the number of days requests have been open. This order doesn't change when things are relisted, so it can be useful in searching for older discussions that might be ready for closure. Dekimasuよ! 17:10, 23 September 2022 (UTC)
That is indeed an excellent table, and I thank User:Wbm1058 again for it. SmokeyJoe (talk) 23:24, 23 September 2022 (UTC)

Talk:Roxas City#Requested move 23 September 2022

This has been ongoing for almost a month and has no further discussion from the day it was proposed. Requesting closure. Howard the Duck (talk) 02:26, 17 October 2022 (UTC)

Done. Judekkan (talk) 03:02, 17 October 2022 (UTC)
Thanks! Howard the Duck (talk) 12:25, 17 October 2022 (UTC)

RMCI loophole?

In the MRV for Modern paganism, the OP complains that while the closer mentioned the previous RM, they didn't take it into account in their decision on determining consensus. (The RM had unequivocal support for the move.) Given the wording of how WP:RMCI#Determining consensus is written, I endorsed the close. WP:RMCI states Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Wikipedia community in general as reflected in applicable policy, guidelines and naming conventions. (Emphasis mine.) Likewise, the second paragraph makes a similar statement which doesn't seem to lend itself to requiring the closer to allow any weight from previous RMs, nor allowing them to do so. The only caveat given there to WP:IAR is when the requested move will break policy or guidelines or naming conventions.

Is this a loophole? Should the existing wording mean that the closer should consult previous RMs? Should the wording be changed to allow and/or require the closer to make such considerations?

If yes, are there other pieces of work that the closer may want and/or need to consult? (ARB decisions regarding the article in question come to mind for an RM I closed where I took the ARB edit edict of the article into account. This RM is still in MRV.)

Thoughts? - UtherSRG (talk) 15:41, 20 October 2022 (UTC)

Should the closer consult the previous RMs? I think: Yes, but.
The onus to link and provide some comment on previous RMs should lie with the RM nominator. I note that the best RM nominations summarise the prior RMs and why they failed or did something different.
It would be nice if the RM template auto-listed prior RMs, like happens with AfD, but prior RMs are sometimes on unexpected different pages. Maybe just a templated spot and display for prior RMs, like what MRV does for “discussion with closer”. Just having the prompt has a good effect. SmokeyJoe (talk) 21:33, 20 October 2022 (UTC)
I like your suggestion that the RM nominator should have some burden here. And I agree that it would be nice if the template could accommodate. Perhaps the instructions at WP:RM#CM could be updated for including how to at least include pointers to the previous moves, with suggestions for how to locate ones that are not immediately obvious.
That said, RM nominators are not expected to be as knowledgeable as RM closers are. As such, I don't know if all of the burden lies on the nominator. So, given the wording of RMCI, and given an RM that doesn't mention the previous RMs (failed or otherwise), should the closer consult the previous RMs? Or perhaps a better question is: Is there a mandate for the RM closer to consult previous RMs if the previous RMs were not mentioned in the current RM? - UtherSRG (talk) 01:13, 22 October 2022 (UTC)
Personally if I was going to close an RM I'd only look at previous RM in any detail if they were referred to in the latest discussion (anyone involved in the discussion, doesn't need to be the nominator). -Kj cheetham (talk) 12:38, 22 October 2022 (UTC)
P.S. The older a previous RM was, the less weight I'd give it, if any. -Kj cheetham (talk) 16:04, 27 October 2022 (UTC)
There is nothing wrong with a closer reviewing the content of prior RMs, but there is the question: To what end? What information in a prior RM is relevant to the current RM? Policy-Guideline-Essay references? Have previously valid facts—NGRAMS, page views, etc. been invalidated in the new RM? Are the prior RM decisions relevant? What about the scenario where previous RMs over the course of years have always had the same result. What has changed to prompt the current RM? In most cases in my experience, the nominator just doesn’t like the previous decisions. Should the closer conclude that the community has made a consistent decision over the last decade through multiple RMs, especially if nothing significant has changed, and close the RM consistent with the decisions in prior RMs.
An additional speed bump appears if a closed RM decision that relies on significant data in previous RMs makes to MRV. Can the closer be challenged as a SuperVote! if there is a strong reliance on prior RMs in the current decision? I can just imagine the complexity of that discussion. IMHO, move with some care here.Mike Cline (talk) 14:07, 22 October 2022 (UTC)
If the closer discovers important information in a previous RM not linked or even mentioned in the current RM, they should draw attention to that previous RM and the important information and relist, not close. SmokeyJoe (talk) 21:43, 31 October 2022 (UTC)

advertising while first relist

Hello. In case there is no participation in the first week of an RM, while relisting I notify the related wikiprojects in the hopes of getting more participation. Recently I came across Favonian, who does the same. I was wondering, is there user-script to make that faster? Also, should we make it a protocol/guideline to notify relevant wikiprojects if there is zero, or almost zero participation (one vote, and lots of discussion between OP, and voter; or something similar)? If the discussion here is in favour, then we can take it to VP/PR. —usernamekiran (talk) 09:00, 2 November 2022 (UTC)

@Usernamekiran: I use User:TheTVExpert/rmCloser, which makes relisting and advertising a lot simpler. Favonian (talk) 09:07, 2 November 2022 (UTC)
thanks Favonian, I added to my common.js Any thoughts on making it a guideline? —usernamekiran (talk) 09:13, 2 November 2022 (UTC)
Positive, in principle, though I wish we had data regarding the rate of success for such notifications. As of today, the case in which we are both involved is not encouraging. Favonian (talk) 10:55, 2 November 2022 (UTC)
I went through my previous contributions, and the results are not much promising. During Talk:Powertrain layout#Requested move 27 July 2022 I had notified four wikiprojects, yet there was zero participation in the next week. I guess not many editors actively watch talkpages of wikiprojects, or maybe they don't participate in the RMs if the subject doesnt interest them much. In most of the RMs, I see familiar usernames, making me think they are RM regulars (coming to RM from WP:RMC, instead of article/TP or wikiproject). A downside of the RM relist notification can be spamming wikiproject talkpages. But given we would only notify them if there is no participation in the first week, I think notifications would not mount enough to be felt as spamming. —usernamekiran (talk) 10:37, 3 November 2022 (UTC)

A thing I will be doing

First of all, I've noticed that a few to several editors, who help on this page, have been using the summary: "done 1" , or "done 2" , or "done 3" and so on, when removing completed requests from the RM/TR project page. It struck me as a concerted effort to respect and honor AA, A befitting tribute in my opinion, and a thing I am now doing as well. The other thing I intend to start doing is to reply to a technical request with ((doing)) when I begin the round robin process to swap the pages. It is a prudent measure to avoid wasted duplication of effort. Hopefully others will see the benefit and adopt the practice themselves, but it is a thing I will be doing from here (except when I forget). Best regards. --John Cline (talk) 01:09, 3 November 2022 (UTC)

It would be simpler still to remove the request before actually moving the pages (if you encounter a roadblock such as title blacklist or move protection, just revert yourself; it should be moved to "administrator needed" section anyway). Of course, everyone should follow the same steps to prevent conflicts.
I've actually had "move conflict" while swapping pages two times. It was quite funny actually, because it resulted in reverting the swap previously done by the fellow mover. No such user (talk) 08:48, 3 November 2022 (UTC)
I can see how your idea would be more effective (almost full proof). I'm not entirely certain, however, that it would be simpler (in my opinion the jury's still out on that one). I too have conflicted with others as we simaltaioneously handled the same request. I suspect it's happened to most (if not all) of us at one time or another. I do think it would be good for us to become proactive in preventing these eventualities instead of beholding the status quo where they are certain to recur at interval. Best regards.--John Cline (talk) 10:02, 3 November 2022 (UTC)
Similar thing, but not entirely, has happened to me in the past. After closing an RM on talkpage, I got edit conflict. Apparently another user had moved the page, with intention to close the RM afterwords. I agree with No Such User, it would be a simple solution. But necessary thing is, everybody follows the same practice. —usernamekiran (talk) 10:23, 3 November 2022 (UTC)
I don't know how common is this, but I probably also edit-conflicted during a past RM closure. CX Zoom[he/him] (let's talk • {CX}) 22:54, 7 November 2022 (UTC)
RM closers have the additional ((closing)) tag that can be used since some take a significant amount of time to write up adequately. The RM/TRs, though, tend to be much quicker, and simply removing them from the list ahead of the move is probably the better alternative. - UtherSRG (talk) 12:01, 10 November 2022 (UTC)

Requested move 18 November 2022

Moved to Talk:AXS_(company)#Requested_move_18_November_2022 (diff)

Primefac (talk) 14:11, 18 November 2022 (UTC)

Requested moves creating links to disambiguation pages

In an earlier discussion - I do not remember where - it was determined that pages movers were not bound to solve the links to disambiguation pages their page move creates. Although I agree with that stance, it makes me unhappy that that effect is now off-loaded to others. Is there a request page (or other option) where these moves can be listed so that a bot operator can pick them up and solve (the bulk of) them? The Banner talk 14:20, 10 November 2022 (UTC)

Would be interested to know if there's such a page as well. I usually resolve such inbound links though AWB for the discussions I close, except for when it is too large or takes too much time for me to handle, like after I had done the close for Australian where there were 3-4,000 links. The backlog was however cleared within the day or so when there were at least two other editors working on updating the links as well. – robertsky (talk) 14:27, 10 November 2022 (UTC)
Page movers (in the broad sense of the term) should repoint incoming redirects and fix links in navigation templates, but they aren't otherwise required to fix dab links, though they're encouraged to help if they can (see the second paragraph of WP:FIXDABLINKS and its footnote).
The place to ask for help is WT:DPL. This project's participants are currently quite active and will most likely swipe up any dab links by the end of the next working day even if you don't ask them to. Bots aren't useful unless in exceptional circumstances because fixing links is sensitive to context. – Uanfala (talk) 14:56, 10 November 2022 (UTC)
Recently, a lot of work was done and the list here is now much shorter. But still you have Iranians with 175 incoming links. As far as I can see, page mover do not fix links in templates. I still see a lot of them showing up at the maintenance page. The Banner talk 17:02, 10 November 2022 (UTC)
page mover do not fix links in template... that's a sweeping statement, but I get you. – robertsky (talk) 17:10, 10 November 2022 (UTC)
Correction, As far as I can see, too often page movers do not fix links in templates.. The Banner talk 17:12, 10 November 2022 (UTC)
Just went to WT:DPL for help with this move close at Show and tell (disambiguation) after reading this talk page section, thanks for the good pointer, folks!! :) — Shibbolethink ( ) 15:29, 11 November 2022 (UTC)

Need to update WP:RMTR instructions?

For the last few months, I've been seeing a lot of clearly non-technical requests posted at WP:RMTR. I think that it may be time to provide some kind of essay or instructions explaining what a technical request is and is not, including reasons why some requests that appear to be technical will be contested due to controversial reasons. (And I'm saying this not knowing if I'll have time to write this, but just bring this up in case someone else might feel enthralled to do so.) Steel1943 (talk) 18:44, 21 November 2022 (UTC)

Personally I'm not convinced an essay would reduce the number of such requests, but could be something to be pointed at in response to such requests. There's already guidance at the top of WP:RMTR and in a box at the right, plus at the higher level WP:RM. For "Administrator needed" requests there is a guide, which is not always looked at by requestors. -Kj cheetham (talk) 14:17, 25 November 2022 (UTC)

Requested move

As an IP I am unable to request a page move (which seems a bit odd), but could someone add to the list (or go ahead and move) The Shoes of the Fisherman (movie) to The Shoes of the Fisherman (film) in line with the naming conventions? Thanks - 2A00:23C7:2B86:9801:6562:A1FC:F7F2:51BF (talk) 16:15, 28 November 2022 (UTC)

Two moves at once?

Is it permissible/possible to operate two RM discussions at the same time for the same article? E.g. request a move of "Article X" to "Article XYZ" and also a move of "Article X" to "Article ABC"? Elizium23 (talk) 20:17, 30 November 2022 (UTC)

Why not just discuss both options in the same RM discussion? -Kj cheetham (talk) 20:20, 30 November 2022 (UTC)
Generally, we do not permit two RM discussions at the same time. However: the question arises in the context when a RM for one article identified a consistency problem and triggered a bundled RM for multiple related articles (Talk:Sexual abuse scandal in the Catholic archdiocese of Chicago). I believe the best course of action was to procedurally close the first RM and bundle it with the second, but that did not happen (it was unbundled instead). However, the situation occurs rarely enough that we don't have to make a rule for it. No such user (talk) 11:30, 1 December 2022 (UTC)

moving/re-titling the page from Terence Trent D'Arby to Sananda Maitreya.

The following discussion 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.


Hello, we are opening a discussion about moving/re-titling the page from Terence Trent D'Arby to Sananda Maitreya.

We kindly request to have all the content of the page moved in full to https://en.wikipedia.org/wiki/Sananda_Maitreya and to have the page renamed to "Sananda Maitreya". Since April 2021 the whole discography has been renamed to Sananda Maitreya and it is correct that also wikipedia follows this worldwide update.

Just as one of many examples please check the very first album Introducing The Hardline on Spotify and on Apple Music. Also please check the italian wikipedia page, which already reflects this.

Thank you very much for your precious help in this matter. Francesca Sananda Maitreya - staff (talk) 16:06, 4 December 2022 (UTC)

Hi, please check WP:RM#CM to start a discussion to move the article. The request needs to be done at Talk:Terence Trent D'Arby. Let me know if any question. Vpab15 (talk) 16:33, 4 December 2022 (UTC)
Hi, @Sananda Maitreya - staff: Welcome to Wikipedia, there are a few things I'd like you to know:
  • Your username is not in accordance to Wikipedia's policies. Each account must be owned by a single individual. The current username gives the impression that it is an account of the organisation, you can rename your account. Relevant links are shared on your talk page by Uhai.
  • If you have a connection to the subject of any article, personal or professional, you constitute a conflict of interest, so please avoid to edit the article directly, but feel free to start discussions at the article's talk page. If you need an edit be done, put ((edit request)) right above your request, an independent reviewer will review it and perform the edits if appropriate. Again, relevant links are shared on your talk page.
  • You opened the move request at the wrong place, please follow the instructions by BD2412 below. Thanks! CX Zoom[he/him] (let's talk • {CX}) 16:36, 4 December 2022 (UTC)
@Sananda Maitreya - staff: Per the instructions at WP:RM#CM, to request this page move, click on the "New section" (or "Add topic") tab of Talk:Terence Trent D'Arby, without adding a new subject/header, inserting the following:
((subst:requested move|Sananda Maitreya|reason=Since April 2021 the whole discography has been renamed to Sananda Maitreya and it is correct that also wikipedia follows this worldwide update. Just as one of many examples please check the very first album Introducing The Hardline on [https://open.spotify.com/album/6K0ySLloZibpwuTsVe7fxS Spotify] and on [https://music.apple.com/gb/album/introducing-the-hardline-according-to-remastered/1632646636 Apple Music]. Also please check the [[:it:Sananda_Maitreya|italian wikipedia page]], which already reflects this.))

Cheers! BD2412 T 16:35, 4 December 2022 (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.

Straightforward backlogged close

I think that Talk:Mahsa Amini protests#Requested move 9 December 2022, currently in the backlog, shouldn't be difficult for a close by an uninvolved person, though I won't say which way I think it will be closed, since I'm the formal proposer (in reality, I was only trying to tidy up a messy procedural situation, so I'm not quite the real proposer). Boud (talk) 00:57, 19 December 2022 (UTC)

 Done Polyamorph (talk) 08:12, 19 December 2022 (UTC)

Related discussion at Wikipedia:Village pump (proposals)#New bot to change wikilinks following a requested move

Hello! There is a discussion at Wikipedia:Village pump (proposals)#New bot to change wikilinks following a requested move related to requested moves. Thanks, echidnaLives - talk - edits 23:36, 3 January 2023 (UTC)

Focused Ultrasound Foundation

Hi, I am requesting a page to be renamed/moved. I am requesting it to be moved here rather than moving myself per the Wiki:MovingAPage guidelines that first suggest it be requested here before attempting. The reason is this organization is no longer called "Foundation for Ultrasound Research" it is now called "Focused Ultrasound Foundation". The Wiki page is https://en.wikipedia.org/wiki/Foundation_for_Focused_Ultrasound_Research Voila34228 (talk) 21:56, 11 January 2023 (UTC)

WikiData errors

-snip- (I moved this over to Wikipedia talk:Page mover#Wikidata errors, I think that's a better place to ask, but since this page has significantly more watchers, if you might have an answer to why page moves are breaking wikidata interwiki links, please check the discussion over there, thanks!) ASUKITE 17:04, 13 January 2023 (UTC)

Move Utsav Naik (Gujarati actor) page to top-level

I have created the page at https://en.wikipedia.org/wiki/Draft:Utsav_Naik . I am a Gujarati movie actor with 2 upcoming movies. I have added all the credible sources required from popular news publications Utsavnaik12 (talk) 21:12, 14 January 2023 (UTC)

As you have already noticed, WP:AFC is the process for new users wanting to move pages from Draft to mainspace. Your submission is in the queue and it will be reviewed by a reviewer, hopefully in the next 1 or 2 months. IffyChat -- 21:27, 14 January 2023 (UTC)