Template talk:R from move

Latest comment: 2 years ago by Paine Ellsworth in topic Recent revert 21 July 2022

cui bono?

edit

I think this template may encourage some users to move an article to an inappropriate title, use this template to keep it from being reverted (without a request for page-move), then ask everyone to “assume good faith” during that week (“just following instructions”, etc.).

∗∗∗

Stepping back a bit, what constructive purpose does this template serve? Note that page-moves are recorded amply in the log for the title in question, and in the edit summary of the revision produced during the page-move. What more is needed, and by whom? ―cobaltcigs 16:28, 29 August 2010 (UTC)Reply

the reason for the template is to explain a necessary redirect, to prevent it being deleted without checking. DGG ( talk ) 16:27, 23 May 2011 (UTC)Reply
That is true for all redirects, right? That they get checked before deletion? Not all redirects from moves are necessary. -- JHunterJ (talk) 10:55, 23 July 2012 (UTC)Reply

Automating

edit

Any chance this could be automatically added to the old page whenever a page is moved? --BDD (talk) 18:20, 15 May 2013 (UTC)Reply

Request for comment

edit

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.


The deletion discussion that recently closed with no consensus to delete as noted above is obviously unsatisfying for some contributors. The main problem seems to be the allegation that some editors misuse this Rcat by tagging a redirect-from-move with it, thereby making a 2nd edit to the redirect, which makes it more difficult to revert the move. Several possible solutions were discussed for this gnarly problem, and the closer of the deletion discussion suggested these be further discussed. So to try to avert yet a third attempt to delete this Rcat, I feel it's important to try to come up with a solution that will best serve the Wikipedia project and all readers and contributors. So please record your thoughts about this here in this discussion. – Paine Ellsworth CLIMAX! 08:19, 23 September 2013 (UTC)Reply

I'm wondering if the real question to ask shouldn't be "should redirect categorization templates go on talk pages?" That seems to me to be the logical course if we were trying to retain the redirect categorization system, but wanted to preserve redirects for overturning moves. VanIsaacWS Vexcontribs 01:26, 1 October 2013 (UTC)Reply
Let me try an example so I can see if I can understand you better. Let's say there is a page titled Eye-hand span (hyphen), and you need to move it to Eye–hand span (ndash). The talk page, Talk:Eye-hand span will be moved to Talk:Eye–hand span, as well. Both the article redirect and the talk page redirect that are left behind should then be tagged with {{R from move}}, {{R from modification}} and {{R for convenience}}. Additionally, the article redirect would be tagged with {{R unprintworthy}}. Since both the article redirect and the talkpage redirect are tagged, I'm not sure I understand how not tagging the talkpage would make a difference in an editor's ability to reverse the move. What am I missing? – Paine Ellsworth CLIMAX! 08:54, 1 October 2013 (UTC)Reply
Might it make sense for the move page facility to apply this template automatically? — Robert Greer (talk) 16:03, 1 October 2013 (UTC)Reply
Most certainly it would. But it appears that the devs give this a not-so-high priority. I conjecture that they may realize that most contributors want to do it for the wrong reasons. They want to see the move page categorization automated so no editor will move a page (vandalism or good-faith boo boo or whatever) and then quickly tack {{R from move}} on the redirect that's left behind. That second edit on the redirect of course means that most editors can't revert the move without the help of an admin or even a WP:RM situation. What these contributors seem to miss is that even if the move were to be categorized automatically, there are hundreds of other Rcat's just waiting to be used the same way. Everytime I've moved a page, the move Rcat is but one of two or more other Rcats that are needed to tag the redirect, like {{R from initialism}}, {{R from alternative name}}, {{R unprintworthy}} and many others. One admin, BDD, brought out the only really good reason to automate the move-categorization process. He reminded us that some redirects from moves may go for days, weeks, months, even years before someone like me or several other contributors will get around to it or find it by accident (I've found a lot of those) and categorize them. When the process is automated, the category is immediately populated by the redirect from move. That is the main reason to automate the process, and it is definitely a good one. – Paine Ellsworth CLIMAX! 01:58, 3 October 2013 (UTC)Reply
  • Thanks for the kind words, Paine. I'll repeat the essence of my comments at the TfD. Moves are essentially logged in three ways. There's the automatic logging in page history that's hard-wired into the MediaWiki software. There's {{R from move}} itself, which as we've said doesn't always promptly get applied (and can indeed be somewhat problematic when promptly applied). And finally, there's Category:Redirects from moves, which is populated by the template. I suppose reasonable people can disagree, but I believe this triple logging has some redundancy, and that's why I advocated trying to automate the application of R from move, or deprecating it altogether.
Ideally, I'd like to see an arrangement where redirect tagging somehow doesn't prevent moves over the redirect. I don't know how practical that is, but my suggestions at TfD would require a software update anyway. I don't know where that leaves us, but I think that's what it's going to take to make this situation more efficient. --BDD (talk) 15:18, 3 October 2013 (UTC)Reply
I've just submitted gerrit:87345, which (once merged) will add MediaWiki:move-redirect-text. We will then be able to set that to {{R from move}}, solving this problem the right way. Jackmcbarn (talk) 15:22, 3 October 2013 (UTC)Reply
FOGOOS! (Farm out, gravy and out of state!) – Paine Ellsworth CLIMAX! 13:51, 4 October 2013 (UTC)Reply
That change was just merged today. It should be live here on October 17th at 20:00 UTC. Jackmcbarn (talk) 15:01, 4 October 2013 (UTC)Reply
BDD, it's a good idea whose time apparently has come. The next step (dare I say it?) is to find a way to autotag redirects with the correct categorization(s) immediately after the redirects are created. Or at least automatically make them populate a Category:Newly created redirects so that gnomes like me can keep it emptied by applying the necessary Rcats. – Paine Ellsworth CLIMAX! 13:40, 4 October 2013 (UTC)Reply

I would like to make sure I understand. When gerrit:87345 goes live on October 17th, after that any time a page is moved, the redirect that is left behind will automatically be sorted into Category:Redirects from moves – is that correct? – Paine Ellsworth CLIMAX! 17:08, 6 October 2013 (UTC)Reply

An admin will need to create page MediaWiki:move-redirect-text with content {{R from move}} once the change goes live, but yes, after that they will. Jackmcbarn (talk) 17:19, 6 October 2013 (UTC)Reply
That means that {{R from move}} will still be available for use on past moves that are not yet tagged. Now, my next question would be: Will the Redirects from moves category appear on the redirect page as a hidden category like it does at present? – Paine Ellsworth CLIMAX! 19:07, 6 October 2013 (UTC)Reply
Yes. It will behave exactly like redirects that are tagged with {{R from move}} now do, because the wikicode will be exactly the same. Jackmcbarn (talk) 20:31, 6 October 2013 (UTC)Reply
Multiple awesomes and kudes, Jackmcbarn! Thank you, thank you very much! – Paine Ellsworth CLIMAX! 21:15, 6 October 2013 (UTC)Reply

To editor BDD: Did you plan to create MediaWiki:move-redirect-text with content {{R from move}} when gerrit:87345 goes live today? – Paine Ellsworth CLIMAX! 17:29, 17 October 2013 (UTC)Reply

Huh? Sorry, I'm not sure I have the technical chops. If it's easy as inserting some text somewhere I can do the job, but otherwise it may be better left to someone who knows what he or she is doing. --BDD (talk) 18:00, 17 October 2013 (UTC)Reply
No, no, no, that's okay... Jackmcbarn just mentioned that an admin would have to create that file, and I'm sorry, because I mistakenly assumed that you and any admin would have the "chops". Mybad, totally mybad. I'll ask over at VPT to see if we can find someone. I have an errand to run, so it will have to wait until I return. Chou! – Paine Ellsworth CLIMAX! 19:28, 17 October 2013 (UTC)Reply
If it's simply a matter of protections and permissions, I'd be happy to carry it out. It's the how I'm not quite sure about. Is it just as simple as adding {{R from move}} at MediaWiki:Move-redirect-text? I just want to be certain about that, because I haven't done anything in that namespace before and I'm wary of breaking something. --BDD (talk) 19:57, 17 October 2013 (UTC)Reply
I've submitted an edit request. And yes, it's that simple. Jackmcbarn (talk) 02:50, 18 October 2013 (UTC)Reply
  Done. To monitor, see the move log from 08:44 on. --Redrose64 (talk) 08:46, 18 October 2013 (UTC)Reply
Well, whaddya know - see Kifisias Avenue station - it's got one line of history, and is categorised. --Redrose64 (talk) 08:49, 18 October 2013 (UTC)Reply

Excellent! Now to deal with the problem for which editors have blamed this Rcat. I will add something to WP:REDIRECT about the need for a brief wait period before the addition of other Rcats to ensure an easy revert of the move back to status quo if it is contested. All are welcome to make any needed fixes to what I add. Joys! – Paine Ellsworth CLIMAX! 16:25, 18 October 2013 (UTC)Reply

  • Fantastic. Thanks all for your attention to this. --BDD (talk) 16:51, 18 October 2013 (UTC)Reply
  • I think it is a rather bad idea to add language to prohibit editing redirects after a move, especially as there is little or no prospect of effectively enforcing such a prohibition. I think it is unreasonable to expect editors to keep track of pages they've moved and later go back and add appropriate redirect templates to the page. If a user is abusively moving pages and then editing the redirect to make moving back more difficult, that is a behavioral problem to address with that specific editor -- we should not be making rules that make editing more inconvenient for editors that are making good page moves and edits to add appropriate redirect templates. Besides, there are already multiple avenues by which an editor can request deletion of a redirect that is holding up a legitimate page move. olderwiser 18:58, 18 October 2013 (UTC)Reply
    I tend to agree with you, so it's all over but the shouting as far as I'm concerned. This gerrit is one of the best things I've seen happen on Wikipedia. Thank you BDD, Jackmcbarn, Redrose64, Van, Robert Greer and older wiser for your wisdoms throughout! Joys! – Paine Ellsworth CLIMAX! 17:12, 19 October 2013 (UTC)Reply
  • By the way, for anyone who didn't see yet, discussion from here is spilling over into Wikipedia talk:Redirect#Redirects from moves. Jackmcbarn (talk) 17:29, 19 October 2013 (UTC)Reply
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.

Unclear wording

edit

"This rcat automatically tags all redirects that result from page moves" is potentially ambiguous, in that some less-experienced users may see this template on one redirect and think MediaWiki automatically adds it retroactively to old moved titles (as opposed to the reality, where it must be added manually to any redirect moved before the software change discussed above). Is there anything we should do to clarify this wording? --SoledadKabocha (talk) 00:40, 4 November 2014 (UTC)Reply

Suggested rewording: "This rcat template is automatically added to all redirects that result from page moves." If the active voice is really important, my best guess is, "The MediaWiki software automatically adds this rcat template to all redirects that result from page moves." - but I think that sounds wordy. --SoledadKabocha (talk) 01:54, 17 November 2014 (UTC)Reply
Good catch, SoledadKabocha! The notice has been reworded and also "noincluded", so it no longer appears on redirects. – Paine Ellsworth CLIMAX! 07:18, 20 November 2014 (UTC)Reply

Capture unsynched talk page redirects

edit

Mr. Stradivarius – I have placed the following code in the sandbox and would like your help to engage it in {{R from move}}:

{{#ifexist: {{TALKPAGENAME}}|{{#switch: {{SUBPAGENAME}}
  |doc=
  |sandbox=
  |testcases=
  |#default={{#ifeq: {{PAGENAME:{{#invoke:redirect|main|{{TALKPAGENAME}}}}}}|{{PAGENAME:{{#invoke:redirect|main|{{SUBJECTPAGENAME}}}}}}
 |<!-- do nothing -->
 |{{#ifeq: {{FULLPAGENAME}}|{{SUBJECTPAGENAME}}
  |<!-- do nothing -->
  |[[Category:Unsynchronized talk page redirects]]}}}}}}

The first part just ensures that a talk-page redirect exists after a page move. The switch keeps those three subpages out of the maintenance cat if they are the result of page moves and redirect to the main templates' pages. The next part compares the target of the talk page to the target of the subject page and, if the page names (excluding namespace) are the same, then nothing happens. If they are different/unsynched, then the rest of the code will place the talk page in Category:Unsynchronized talk page redirects. As you see, that cat doesn't exist yet, as I've found no better-named existing category, and you might want to suggest a better name for it. This code will:

  • ensure that talk pages are either synched to their subject pages following a page move, or placed in a maintenance category to be captured and fixed,
  • capture all unsynched talk pages, past and future, that are tagged with {{R from move}} (or, of course, the {{Redr}} template with that rcat),
  • maybe resolve some bugs, at least phab:T12814 on the English Wikipedia,
  • maybe lead to resolution of those bugs on other wikis,
  • help Jenks24 with the challenge mentioned on my talk page.

I have tested this code, and it appears to work well, so I would greatly appreciate it if you could take a look at it and maybe tweak it if needed (and then transfer the sandbox to the live template when ready). Pleasant pathways, Paine  16:29, 21 October 2015 (UTC)Reply

Test redirects:
Pleasant pathways, Paine  02:17, 23 October 2015 (UTC)Reply

Edit request on 31 Oct 2015

edit

Please see details above – the sandbox is ready to be deployed to template {{R from move}}, which is now transcluded in a cascade-protected page, and can be edited only by administrators.  Paine  08:36, 31 October 2015 (UTC)Reply

I have fixed the protection. You should be able to edit it now. — Martin (MSGJ · talk) 21:59, 31 October 2015 (UTC)Reply
Thank you so much, Martin! I've deployed the sandbox code. Pleasant pathways, Paine  23:11, 31 October 2015 (UTC)Reply
To editor Martin: I noticed that this template is again cascade protected, so I'm unable to edit it. Can you tell me what the reasoning is, and why your protection fix was reverted?  Paine  07:34, 8 December 2015 (UTC)Reply
See § Page protection issue below. Wbm1058 (talk) 19:47, 11 December 2015 (UTC)Reply

Recent addition of #ifexist causing trouble at Wikipedia:Database reports/Linked misspellings

edit

Paine Ellsworth, your recent changes to this template are causing spurious misspelling listings at Wikipedia:Database reports/Linked misspellings. Note item #13 on that list, 2013 Oklahoma tornados. I was scratching my head over why that page was shown as a "linked misspelling" which was linking to itself, until I noticed m:2015 Community Wishlist Survey/Miscellaneous#Error categorization by #ifexist bug. I confirmed that this edit cleared the page from "what links here". So, until that Mediawiki bug is fixed, we need to fix all the pages that were {{R from move}}d to correct a misspelling by either removing the {{R from move}} as I did, or reverting to the previous version of this template that didn't use #ifexist. – Wbm1058 (talk) 18:32, 7 December 2015 (UTC)Reply

On the other hand, this bug is also flagging obvious typos which are unlikely search terms, such as 196` Soviet Top League (meant to be 1961 Soviet Top League) and 2007 San Fancisco Zoo tiger attacks, so I'm just deleting those, as a better way to solve the problem. Wbm1058 (talk) 19:44, 7 December 2015 (UTC)Reply
Sigh: Wikipedia:Redirects for discussion/Log/2014 October 13 § 36(movie). "9 years old and Mostly Harmless." Hey, a "keep" argument based on the title of a novel? So we need to keep around this typo because it lasted for 18 days in October 2005? Could I move it to 36 (movie) without leaving behind a redirect? That would fix the "misspelling". Wait a minute, a missing space is not a misspelling, that's surely an {{R from modification}}, right? Wbm1058 (talk) 20:13, 7 December 2015 (UTC)Reply
No, no wait a minute. That redirects to 36 Quai des Orfèvres (film) which is definitely more than just a simple modificaiton of 36(movie). I'm just going to remove the {{R from misspelling}}. Wbm1058 (talk) 20:20, 7 December 2015 (UTC)Reply
So, I've just removed {{R from move}} from .45 Remington-Thompson and 1080º Avalanche, the first two items on the linked misspellings list, and will wait for your response before I do any more, in case you would prefer to revert the addition of #ifexist to the template. Wbm1058 (talk) 20:39, 7 December 2015 (UTC)Reply
To editor Wbm1058: Workin' on it, boss.  Paine  05:03, 8 December 2015 (UTC)Reply
Okay Wbm1058, I read the Phab page and now have a few questions/items for you.
  1. First, since you have removed the R from move template from the first two items on the Linked misspellings list, why are they still on the list? I thought that removing the move rcat from the redirect was supposed to remove those two from the list. Yet, they're still there on the list. Are they now supposed to be on the list? and no longer "spurious misspelling listings"?
  2. Next, the Item 13 redirect is not a misspelling according to Wikt:tornado. Both "tornados" and "tornadoes" are correct plural forms, and the first form, "tornados", appears first, which usually means that it is the preferred plural form.
  3. "36(movie)", while not a "misspelling", is most certainly a "typo", and so should retain the R typo rcat. And yes, it should also be tagged as a modification, and {{R fod}} + {{R up}} as well. Since typos that are not misspellings are covered under the R from misspelling rcat, I will give some thought as to a better name for that rcat. {{R from misspellings and other typos}} springs to mind, but I'm sure we can do better than that.
  4. I'm not sure yet what to do about this, because the code in R from move that I added was to help corral unsynchronized talk page redirects, which just means that their subject page redirects don't target the same {{PAGENAME}} (without the namespaces) as the talk pages. I will see if the #ifexist: functions can be eliminated, but first glance tells me it will cause other complications. I'll scrutinize it and get back to you. We may want to consider just letting the devs work their magic on this one. Happy holidays! Paine  07:02, 8 December 2015 (UTC)Reply
Almost forgot #5: Not sure if you're aware that the {{Redr}} template has been modified to detect and tag protected redirects automatically. This should save some time for admins who change protection levels, because they will no longer need to be concerned about also adding/subtracting protection templates. Redr does it for them. You might want to consider using Redr rather than applying individual rcats to redirects. See also {{This is a redirect/Comparison}}.  Paine  07:23, 8 December 2015 (UTC)Reply
The beginning was this edit. I used the {{#ifexist: {{TALKPAGENAME}} function because I felt that it was necessary in order to determine if the balance of the new code was to be engaged. If a subject page was moved and the left-behind redirect had no talk page, then there was no need to engage the balance of the code; however, if the left-behind redirect had a talk page, then the balance of the code should be engaged. At this point what happened was that the new Category:Unsynchronized talk page redirects filled up quickly to more than 25,000 pages! The majority turned out to be talk-page archives that had no subject pages and are therefore unsynchronized (technically), so I added {{#ifexist: {{SUBJECTPAGENAME}} with this edit. Entries began to drop out of the new category and stabilized at a more manageable number of < 8,000.
After looking again at all this, frankly I'm not certain whether or not the {{#ifexist: {{TALKPAGENAME}} code is absolutely necessary. I used it initially because I thought it made sense to ensure that any redirect left behind from a page move had a talk page that would also be autotagged with {{redr|from move}} in order to engage the rest of the new code in this rcat. On the other hand, the {{#ifexist: {{SUBJECTPAGENAME}} code was necessary to rid the new category of more than 17,000 talk-page redirects that had no subject pages. If that code is removed, then all those unwanted pages will again populate the new category. How to proceed?  Paine  08:51, 8 December 2015 (UTC)Reply
@Paine Ellsworth: Answering Q. #1, the list is bot-generated once a week, so they will remain on the list until the next weekly bot run. I confirmed the edit to remove {{R from move}} resolved it by checking "what links here"... that's what the bot does to generate its list. You may confirm this for yourself by looking at item #36 on the list, Aarons Rod. Note that "what links here" says that it links to itself. Remove the |move and then check "what links here" again. Still reading the rest of your response. Wbm1058 (talk) 15:02, 8 December 2015 (UTC)Reply
Good catch on Q. #2. It was another editor who moved page 2013 Oklahoma tornados to 2013 Oklahoma tornadoes, and then tagged "tornados" with {{R from move}} and {{R from misspelling}}. I just corrected that to {{R from alternative spelling}}. But this is peripheral to the main issue that we're discussing here. Wbm1058 (talk) 15:37, 8 December 2015 (UTC)Reply
Q. #3 relates to Wikipedia talk:Redirect § Redirects from incorrect punctuation – how to tag?. Perhaps {{R from typo}} (~ 440 transclusions) and {{R typo}} (~ 520 transclusions) should be disambiguated between {{R from misspelling}} and {{R from incorrect punctuation}}. I would argue that a missing space before a parenthetical disambiguator should be tagged as a lower priority for correction than, e.g. a misspelling of Barack Obama's name (which happens almost every week at least once). Wbm1058 (talk) 16:44, 8 December 2015 (UTC)Reply
Re: 36(movie) – I think that is a "pure" typo unrelated to either spelling or punctuation, since a space is just a modification and, in this case, a typing error.  Paine  17:36, 8 December 2015 (UTC)Reply
...then simply use {{R from modification}}. {{R from incorrect punctuation}} just redirects there, any way. "Pure" typo unrelated to anything specific are just vanilla modifications. Wbm1058 (talk) 17:59, 8 December 2015 (UTC)Reply
...and yet, still "typos" and subject to categorization as typos, no?  Paine  19:06, 8 December 2015 (UTC)Reply
We should resume this discussion later in a new section. Making a mental note to get back to this as a "tweak list" item. Wbm1058 (talk) 17:02, 9 December 2015 (UTC)Reply
Re: Q. #4: Excellent. Category:Unsynchronized talk page redirects is a super real-time replacement for User:Mikaey/Broken talk pages which lists talk pages which redirect elsewhere but have a non-redirecting subject page. That list, as you can see from its history, is stale as it was last generated in August 2009. And, it seems that the only editor to work on that list in six years is me, starting earlier this year. I was wondering what you were up to, as you haven't yet updated Template:R from move/doc to explain this new functionality. Just noting and confirming that Talk:Frumuşica, which is near the bottom of Mikaey's list (I was working off the bottom of the Broken talk pages list), is now also categorized in Unsynchronized talk page redirects. Yes, we need to find a solution that both keeps this new cat and doesn't clutter up the misspellings list. And, I'm thinking that, realistically, the only way that cat with over 7200 members get cleared is by a bot. I'll see if I can design a bot that can clear that category. I'm still reading the rest of your comments... Wbm1058 (talk) 17:50, 8 December 2015 (UTC)Reply
I appreciate your wanting to find a bot solution, Wbm1058, and I would have asked you to do that since you've helped me out with bots in the past; however, I was holding off asking because I'm still analyzing the cat to see if there are any other types of unsynched talk page redirects that can be eliminated from the cat using this code. I've eliminated /doc, /sandbox, /testcases and, as previously noted, talk page archive pages, and there are probably more that can be allowed to be unsynched, so a bot solution at present is premature. Don't worry, because when I think the cat is ready for a bot, I'll let you know. Thank you very much, though, for thinking about that and for making the offer. Build the bot at your leisure, because it will be needed soon enough.  Paine  18:11, 8 December 2015 (UTC)Reply
OK, sure. Of course all the kinks will need to be ironed out before the gatekeepers at WP:BRFA approve anything. Wbm1058 (talk) 18:43, 8 December 2015 (UTC)Reply
Two things should be mentioned while you're designing the bot:
  1. at present, the cat purposefully contains only mainspace talk-page redirects, and when those are dealt with, the plan is to tackle the few that are left in other namespaces.
  2. I'm finding that most of the entries in the cat are talk pages that need to be changed to sync to their subject pages; however, about 5–10% of the entries go the opposite direction, i.e., the subject pages need to be changed to sync to their talk pages. I don't know much about bots, but that might be tricky.  Paine  19:15, 8 December 2015 (UTC)Reply
Re: #5: No, I didn't notice that as of 22 September 2014, {{Redr}} detects and tags protected redirects automatically. Another super enhancement. I should open a discussion about your overall redirect-tagging system sometime (there's things I'd like to tweak), but deferring on that for now, to focus on the problem at hand. Wbm1058 (talk) 18:43, 8 December 2015 (UTC)Reply
Me2. Happy holidays! Paine  19:28, 8 December 2015 (UTC)Reply
  • "The majority turned out to be talk-page archives that had no subject pages and are therefore unsynchronized (technically)". Well, these should be fixed. Likely an article and its currrent talk page were moved, but the talk archives were left behind? If so, they should be reunited. Maybe, if there's a lot of these, we put them in a separate category. Happy holidays! to you, too! Wbm1058 (talk) 17:02, 9 December 2015 (UTC)Reply
  • No, they were removed from the category using code in this rcat precisely because they did not need to be fixed. After the talk page archives were moved, they left behind redirects to the new archive pages. Those redirects do not have subject pages, so they show up as unsynchronized redirects unless we stipulate in the code that talk-page redirects with no subject pages are to be ignored. That is done by use of the {{#ifexist: {{SUBJECTPAGENAME}} function.  Paine  02:38, 10 December 2015 (UTC)Reply

Fresh look at the problem

edit

Paine Ellsworth, after a month away from this, I'm looking at it again. Noting that this template {{R from move}} is widely used on both mainspace (namespace 0) and talk pages (namespace 1), and we are looking to populate Category:Unsynchronized talk page redirects, shouldn't our first check be to see if we are on a talk page? If the first test is:

{{#ifeq: {{NAMESPACENUMBER}}|1

then if we are on namespace 0, we're done and thus no #ifexists are necessary when {{R from move}} is transcluded on mainspace redirects. That should keep 1080º Avalanche from linking to itself and becoming a false-positive on the linked misspellings list.

Then if we are on a talk page because the NAMESPACENUMBER=1 test was successful, then #ifexist: {{TALKPAGENAME}} becomes unnecessary. We know the TALKPAGENAME exists because we are on it right now... the fact that {{R from move}} is sitting on the talk page means it exists!

Next I think you found that when we are on a subpage of a talk page (most often an archive), such as Talk:Hillary Rodham Clinton/Archive 25, we should not populate Category:Unsynchronized talk page redirects. Instead of checking to see whether the corresponding mainspace page exists, why not check to see if we are on a subpage, and if so, we're done, as we don't want to put any subpages in Category:Unsynchronized talk page redirects. – Wbm1058 (talk) 20:49, 19 January 2016 (UTC)Reply

Wanted to let you know that I received your notification. Let me see if I can put together some code that uses your suggestions to do the same job without the #ifexists functions.  Paine  07:13, 20 January 2016 (UTC)Reply
To editors Wbm1058 and Faceless Enemy: The new code has been thoroughly tested and then engaged in the live template. This will hopefully correct the errors you noted. If not, let me know and we'll go from there. Wbm1058, your suggestions above were very helpful since we are restricting everything to mainspace talkpages. I also removed the switch temporarily, since I've never encountered NAMESPACE=1 subpages that were /doc, /sandbox or /testcases. I'll put that switch back in when we enter phase two and rid the other namespaces of unsynced talk pages. Thank you for finding this and for spurring me on to find a solution. Well, I sincerely hope it actually is a solution. Again, let me know if the code needs to be further massaged.  Paine  17:29, 20 January 2016 (UTC)Reply
Looks good so far. Thanks, Wbm1058 (talk) 02:29, 21 January 2016 (UTC)Reply
Paine Ellsworth, that's great, thank you!!! Faceless Enemy (talk) 04:08, 21 January 2016 (UTC)Reply
Good to hear, and I sympathize with the challenge, because the #ifexist function is found many places. Hopefully soon we will be able to stop with the bandaids and fix the source of the "bleeding".  Be prosperous! Paine  21:28, 22 January 2016 (UTC)Reply

Page protection issue

edit

Hmm, I just noticed the red padlock on this template, and although the template itself is still just template-protected, I see the message:
"WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following page (which is protected with the "cascading" option enabled). Please ensure that you are following the protection policy."

Since that page was moved at 16:49, 20 November 2015‎, it is now transcluding {{R from move}}. So because of this "cascading protection", I believe that you've been locked from editing {{R from move}} since November 20. Can you confirm that? From the history, I see that you last edited this template on November 7.

Now, I go to that recently created {{R from move}} redirect, and clicking on the "Change protection" dropdown, I see:

Change protection level for "Wikipedia:New admin/Protecting deleted pages/Transclusionist"

and I see that the box for "Cascading protection (automatically protect any pages transcluded in this page)" is checked.

Now, if you and other template editors want to be able to edit Template:R from move again, I see two options:

  • I can uncheck that box for cascading protection and click Confirm to change the protection level of Wikipedia:New admin/Protecting deleted pages/Transclusionist
  • I can just remove the {{R from move}} from that recently created redirect-from move

Not knowing the full implications of removing cascading protection there, I'm thinking that the second choice might be safer. Wbm1058 (talk) 17:03, 11 December 2015 (UTC)Reply

Though on second thought, given what little links to that page and that the page it redirects/was moved to says "This is the page to practice transcluding protection with", it's probably safe for me to start practicing transcluding protection by unchecking that box ;) Wbm1058 (talk) 17:39, 11 December 2015 (UTC)Reply
It appears that (from my perspective) the project page that was recently moved is a protected page whether or not {{R from move}} tags it (there is no cascade protection mentioned on the edit page). Depopulation of a valid entry in a category should only be a very temporary bandaid and not a real "fix" of the deeper problem. Also, before you take this template off the cascade list, have a look at this section above and its ensuing edit request. It was cascade protected, then Martin took it off the cascade list, and I edited it a bit, then someone else put it back on the cascade list. I just don't want you to get in a bind over this. We'll figure it out.  Paine  19:00, 11 December 2015 (UTC)Reply
Oh, I see. You already noticed the problem 3 days ago. Sorry, I'm a greenhorn with this cascade-protection stuff. Wbm1058 (talk) 20:03, 11 December 2015 (UTC)Reply

I think I found Martin's October 31 fix: HERE. The offending page was User:Chillum/Salt. I suspect you were locked out between Sept. 21 and Oct. 31. Who knows why cascade was checked on that page, as Martin said in his edit summary, "cascading presumably not needed". This will likely be an ongoing problem as admins randomly move pages with the cascading option checked on. That option being turned on by any admin-protected page transcluding {{R from move}} is simply not compatible with template editors being able to edit the template. Wbm1058 (talk) 20:28, 11 December 2015 (UTC)Reply

It's sounds as if the cascade checkbox is checked by default? Its default should be "unchecked".  Paine  23:49, 11 December 2015 (UTC)Reply
I don't know, but I'd be surprised if they were all checked by default. But, I was bold, and the padlock is pink again :) Wbm1058 (talk) 03:00, 12 December 2015 (UTC)Reply
Does that now make you a "Rogue Rouge admin"?    Paine  23:35, 12 December 2015 (UTC)Reply

Linking to self?

edit

For some reason, the {R from move} template has a link to itself. So the pages that are redirects from a move due to a misspelling show up at Wikipedia:Database_reports/Linked_misspellings. An example page is 1998–99 Allied Dunbar Premership Two, which shows itself as the only namespace article that links to it ([1]). Is there any way to make it so that this doesn't happen? Faceless Enemy (talk) 22:51, 29 December 2015 (UTC)Reply

To editor Faceless Enemy: This is addressed in this discussion above. It has to do with a parser function, #ifexist, that has been added to help synchronize talk page redirects with their subject pages. There is no solution as yet. Happy New Year! Paine  21:41, 1 January 2016 (UTC)Reply

Notes towards developing a system to fix broken / unsynchronized talk page redirects

edit
Oh, my. Category:Unsynchronized disambiguation talk pages now has more members than Category:Unsynchronized talk page redirects. Time to get working on a bot; over 8,500 members in each. wbm1058 (talk) 12:26, 5 May 2016 (UTC)Reply
BRFA filed. – wbm1058 (talk) 20:46, 18 May 2016 (UTC)Reply
I look forward to see how well this works!  OUR Wikipedia (not "mine")! Paine  09:27, 4 June 2016 (UTC)Reply
  Done – though I expect the category to repopulate steadily at a rate of several per week. I may try to automate periodic bot runs to re-clear it, but for now I'll attempt to develop a similar AWB "find & replace" that will clear Category:Unsynchronized talk page redirects. That may be a bit trickier. wbm1058 (talk) 16:49, 4 June 2016 (UTC)Reply

Script error

edit

{{R from move}} on a page without a redirect can generate Category:Pages with script errors. It was reported at Wikipedia:Village pump (technical)#Category:Pages with script errors being flooded with errors. PrimeHunter (talk) 16:28, 24 September 2017 (UTC)Reply

@Paine Ellsworth: Did you notice this problem report? Noting that Template:R from move/except was created at 22:52, 26 September 2017‎, just a couple of days after the problem was reported on the village pump. I was looking at recent changes to the template because Category:Unsynchronized talk page redirects always seems to be empty every time I check it, and I was wondering why. – wbm1058 (talk) 22:15, 20 January 2018 (UTC)Reply
To editors Wbm1058 and PrimeHunter: wish I could say yes, but no, I didn't catch that report. You're right, though. Something is amiss. I promise to check into it anon verisimo.  Paine Ellsworth  put'r there  22:34, 20 January 2018 (UTC)Reply
To editors Wbm1058 and PrimeHunter: as you say, the exception subpage template was not added until two days after the script error was reported at the VPT, and the last edit to R from move before that was August of 2016. So there does not seem to be reason to suspect this template. However... I took a close look at the /except code and found that I had a brain hiccup when I added the most recent exception. I just fixed the code, so the Unsynchronized talk page redirects category should start filling again. Happy New Year to you and yours!  Paine Ellsworth  put'r there  02:12, 21 January 2018 (UTC)Reply

Template-protected edit request on 23 June 2020

edit

Change "Swisslog Holding" to "Swisslog", as this is the correct name of the company JulianJorns (talk) 13:29, 23 June 2020 (UTC)Reply

  Not done: this is the talk page for discussing improvements to the template {{R from move}}. Please make your request at the talk page for the article concerned. * Pppery * it has begun... 14:13, 23 June 2020 (UTC)Reply

Recent revert 21 July 2022

edit

To editor Steel1943: Hey-de-hay, Steelman!

  |from=a page that has been moved (renamed) or is the result of a page move
  |info=One reason this page was kept as a redirect is to avoid breaking links, both internal and external, that may have been made to the old page name. Any redirect with a page move logged on its history page should be tagged with this rcat template.

Just added text to clarify the usage of this rcat template. Done this thousands of times to this and other rcats. You say "this wording addition needs discussion since it wasn't discussed and I don't agree with it". What exactly seems off the mark to you? P.I. Ellsworth , ed. put'r there 18:55, 21 July 2022 (UTC)Reply

  • Hello to you too Paine! Good to hear from you as well! Anyways, down to the point here ... I don't agree with that wording if the target of the {{R from move}} is not the same target (or the eventual location of that target via additional page moves) as where the content was moved. For example, let's say I move "Apple" to "Green apple", then I retarget "Apple" to "Orange": In that case, I would not believe that {{R from move}} should apply since the target was changed to a different subject. Hope that explains my issue with the wording. Steel1943 (talk) 20:40, 21 July 2022 (UTC)Reply
    • In your example, when you moved Apple to Green apple, was not the Apple redirect a redirect from a page move no matter what it eventually targets? Yes, of course it was. That is one reason an editor was confused and asked me for clarification. Whenever a page is moved (or merged for that matter), if it becomes a redirect then it is an R from move (or merge) for the life of the redirect no matter what the eventual targets become. P.I. Ellsworth , ed. put'r there 20:47, 21 July 2022 (UTC)Reply
      • I understand what you mean, but I don't agree with it applying to this template/rcat for the reasons I stated. If this needs to be categorized, maybe a new rcat should be created, like {{R from previous move}} while clarifying the difference between the two rcats? Steel1943 (talk) 21:30, 21 July 2022 (UTC)Reply
        • Well, I guess we don't agree then, either on the application or the need for a sub-rcat template. Let's say you moved Apple to Green apple and left the Apple redirect to target the new name. We agree at least that the Apple redirect should then be categorized into Category:Redirects from moves. Five years from now another editor retargets Apple to Orange, or Fruit, something else. Is that editor then expected to REMOVE the redirect from the main redirects-from-moves category and put it somewhere else? That's just not logical. Apple is still a redirect that resulted five years ago from a page move. It should continue to stay in the Redirects from moves category. For me, that's the only way it makes any sense. Anything else yields an erroneous count in the category. P.I. Ellsworth , ed. put'r there 00:21, 22 July 2022 (UTC)Reply
          • I do agree that we are disagreeing here. 😅 However, in regards to "Is [the] editor then expected to REMOVE the redirect from the main redirects-from-moves category and put it somewhere else?": Well ... with the exception of the "somewhere else" part (since to my knowledge, such an rcat doesn't exist yet), that's what I've been doing for a few years now, so it makes sense to me. I'd say it's akin to other situations where an rcat is changed on a redirect after the redirect's target has changed, such as when a redirect tagged with {{R from unnecessary disambiguation}} gets retargeted to a disambiguation page and gets recategorized with {{R from incomplete disambiguation}} after its disambiguator becomes ambiguous. Steel1943 (talk) 13:55, 22 July 2022 (UTC)Reply
            • That last part makes sense; I do it all the time when I find them (most other editors seldom think to make the needed changes). The bottom line is that a redirect that results from a page move is a {{R from move}} for the remainder of its existence. It's like a branding iron, and its mark never goes away. P.I. Ellsworth , ed. put'r there 16:32, 22 July 2022 (UTC)Reply