Template talk:This is a redirect

One of my main concerns is that it seems the only time a page-move category is populated is when the move protection is full. I tried removing the "small=yes" from pp-move, but that just places the page-move notification within the Redr box, which might not be a bad idea. Does pp-move not categorize unless there is full move protection? and is this something that also needs to be addressed with the pp-move template? – Paine  01:46, 15 September 2014 (UTC)[reply]

{{

pp-move-indef}} isn't a special case of {{pp-move}} - I think that it should behave the same apart from the expiry date. --Redrose64 (talk) 09:58, 15 September 2014 (UTC)[reply

]

Well, at least we know it's not the code in this template that suppresses the categories. I think I'll go back to the "small=yes" parameter for now. Having the move-protection notification box within the Redr template will be more meaningful when the module becomes more category-effective. Mr. Stradivarius might be very helpful in that regard. That's a handy table you built above! Let me thank you for all your help thus far – you've certainly made it easier for me to massage this protection detection and other concerns as expressed in previous discussions. Now we just need to decide which code set is the one to use: (1) the switch-only code, or (2) the ifeq-switch code. Would one of those render faster than the other? – Paine  15:12, 15 September 2014 (UTC)[reply]

To editor Redrose64: Here I sit, test after test of the sandbox – in which I've placed your originally suggested code with some rcat additions – and I thought of a question. Now, I'm not sure if this question even has an answer; however, I am sure that if this question does have an answer, you would know it. What I wonder stems from the fact that there are probably a lot of move-protected redirects. Not too many semi-move-protected and perhaps even fewer template-move-protected, but I would surmise there are quite a few fully-move protected redirects out there, and yet there is no {{R move protected}} that would feed a Move-protected redirects category. Yes, those move-protected redirects do find their way into Category:Wikipedia move-protected pages (hopefully); however, they are in there with a relatively large bunch of other types of move-protected pages (or would be, but there are probably a lot of pages that are protected, but have not been tagged with {{pp-move}}). Yes, they are in italics, which makes them stand out. Yet I wonder why they are not sorted into their own category like other protected redirects? Do you know if there is an answer for this? and if there is an answer, what do you think it is? – Paine  02:32, 16 September 2014 (UTC)[reply]

Another small concern might be the fact that there are already redirects that are tagged with pp-protected, and I wonder if there will be any conflicts due to multiple calls to Module:Protection banner, like you mentioned earlier? – Paine  01:18, 17 September 2014 (UTC)[reply]

To Redrose64: I found a way to confirm that this would not be a problem. Please respond to the concern just above this one at your earliest convenience. – Paine  21:42, 21 September 2014 (UTC)[reply]

Sandbox code appears ready

The code in the sandbox, which includes the following (a variation of your originial suggestion) tests well in your sandbox table and seems to be ready to deploy:

<!--
  Automatically detect protected redirects:
--><includeonly>{{#switch: {{PROTECTIONLEVEL:move}}
   |sysop={{#switch: {{PROTECTIONLEVEL:edit}}
     |sysop={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R protected|embed=yes}}
     |templateeditor={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R template protected|embed=yes}}
     |autoconfirmed={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
     |#default={{pp-move|small=yes}}
   }}
   |templateeditor={{#switch: {{PROTECTIONLEVEL:edit}}
     |sysop={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R protected|embed=yes}}
     |templateeditor={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R template protected|embed=yes}}
     |autoconfirmed={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
     |#default={{pp-move|small=yes}}
   }}
   |#default={{#switch: {{PROTECTIONLEVEL:edit}}
     |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}}
     |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
     |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
     | <!--Not protected, or only semi-move-protected-->
   }}
 }}</includeonly>

– Paine  23:01, 21 September 2014 (UTC)[reply]

That can be simplified because the code for move protection is the same for both sysop and templateeditor:

<!--
  Automatically detect protected redirects:
--><includeonly>{{#switch: {{PROTECTIONLEVEL:move}}
   |sysop|templateeditor={{#switch: {{PROTECTIONLEVEL:edit}}
     |sysop={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R protected|embed=yes}}
     |templateeditor={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R template protected|embed=yes}}
     |autoconfirmed={{pp-move|small=yes}}{{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
     |#default={{pp-move|small=yes}}
   }}
   |#default={{#switch: {{PROTECTIONLEVEL:edit}}
     |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}}
     |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
     |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
     | <!--Not protected, or only semi-move-protected-->
   }}
 }}</includeonly>

Since the only difference between the upper and lower "halves" is the presence or absence of {{pp-move|small=yes}}, it can be further simplified to:

<!--
  Automatically detect protected redirects:
--><includeonly>{{#switch: {{PROTECTIONLEVEL:move}}
   |sysop|templateeditor={{pp-move|small=yes}}
 }}
 {{#switch: {{PROTECTIONLEVEL:edit}}
   |sysop={{pp-protected|small=yes}}{{R protected|embed=yes}}
   |templateeditor={{pp-protected|small=yes}}{{R template protected|embed=yes}}
   |autoconfirmed={{pp-protected|small=yes}}{{R semi-protected|embed=yes}}
   | <!--Not protected, or only semi-move-protected-->
 }}</includeonly>

--Redrose64 (talk) 15:56, 22 September 2014 (UTC)[reply]

Excellent! Now, you see? That's why you get the big bucks! – Paine  16:37, 22 September 2014 (UTC)[reply]

 Deployed – Paine  16:57, 22 September 2014 (UTC)[reply]

I just modified the template to use local versions of collapse top and collapse bottom. this issue is that the {{collapse top}} and {{collapse bottom}} templates do not render in mobile view or in the print version. this is not a serious problem here, since it's less likely that anyone will be viewing redirects from a mobile phone and certainly not in the print version. however, we are actively trying to clean up transclusions of these templates in article space, and by using the {{collapse top}} and {{collapse bottom}} templates here, it makes it impossible to find them with 'What Links Here'. note that the local versions also don't appear in print or in the mobile view, but they are slightly more efficient, since we can expand some of the parserfunctions, and they have the chance of working in mobile view if we make some changes to the css classes. hopefully my changes didn't cause any problems, and this is a feasible workaround so I can go back to cleaning up the true problematic transclusions of {{collapse top}} and {{collapse bottom}} in article space. thank you. Frietjes (talk) 19:26, 15 September 2014 (UTC)[reply]

Thank you, Frietjes, for the heads up! – Paine  21:31, 15 September 2014 (UTC)[reply]

The purple box produced by this template has a significant amount of space above and below the text, produced by textstyle = padding-top: 1.8em; padding-bottom: 1.8em;. This seems inconsistent with the usual styling of information that appears in boxes in the English Wikipedia. For example, compare three top boxes in the template documentation, or the "This is a talk page" box that appears when editing this page, or the "categories" box at the bottom of an article. I suggest removing this padding. Peter coxhead (talk) 09:12, 5 October 2014 (UTC)[reply]

To editor Peter coxhead: I went ahead and streamlined this from 1.8em to 0.9em. We can see how that goes. Thank you for your ideas, and a Joyous and Happy New Year to you and yours! – Paine  23:58, 11 January 2015 (UTC)[reply]

It seems like whenever I check the category

Hi, Dustin, and Happy Holidays to you and yours! Over time, others have used the manifold sort, and I would say that at present, you use it more often than others. Just like everything else, that may change tomorrow. Joys! – Paine Ellsworth ^CLIMAX! 23:48, 29 December 2014 (UTC)[reply]

(a second comment)

redr}} all the time, but I never use the template without parameters ... is it correct that using the template without parameters is what leads to the categorization you are referring to? --User:Ceyockey (talk to me) 00:45, 23 January 2015 (UTC)[reply

]

@Ceyockey: yes, either leaving the template blank, or specifying an empty first parameter should do it, I believe. Leaving the first parameter empty allows you to add what you know while still marking it as needing assistance. The example used in the template documentation is this: {{This is a redirect||from short name|unprintworthy}} djr13 (talk) 16:14, 29 January 2015 (UTC)[reply]

There is a minor message redundancy when using this template to call {{r from code}}, which results in something like: "For more information follow the category link.. For more information follow the category link(s).". Example redirect: DOCTYPE. djr13 (talk) 17:31, 19 January 2015 (UTC)[reply]

There are several rcats that I haven't updated yet, and "R from code" is one of them. I'll try to get to it today. – Paine Ellsworth^CLIMAX! 17:11, 20 January 2015 (UTC)[reply]

 Fixed by reporter; I hadn't realized this would be an easy fix, and have gone ahead and fixed the problem (which was entirely in the other template). Thanks! djr13 (talk) 08:52, 21 January 2015 (UTC)[reply]

Cool! Joys! – Paine  15:50, 21 January 2015 (UTC)[reply]

When you include the {{

]

This should probably do it: {{Redr|from alternative language|p1=LANGFROM|n1=LANGTO}}. Replace LANGFROM/LANGTO with the appropriate language code. If you want to use the default value for that parameter, just remove it entirely. If you are adding other redirect categories, do so as normal, though if you move from alternative language to a later position than first, simply rename p1 and n1 to that same higher number. Does this make sense? An example of this usage should probably be added to Template:R from alternative language/doc. djr13 (talk) 19:49, 19 January 2015 (UTC)[reply]

 Done – Paine Ellsworth^CLIMAX! 21:44, 19 January 2015 (UTC)[reply]

Well you haven't. You worked on it on one edit in 2010 and one other now. Technically that is a span of six years. It is still arty farty nonsense. Si Trew (talk) 21:03, 20 January 2015 (UTC)[reply]

If you're going to enter other discussions like this, then please be more explicit. Who is "you" in "you haven't"? And "who" worked on "what" on one edit in 2010 and one other now? And "what", exactly, is still "arty farty nonsense"? And why are you forking this discussion all over the place? Please try to maintain yourself to one discussion area in accordance with Wikipedia policy, thank you! – Paine Ellsworth^CLIMAX! 02:35, 21 January 2015 (UTC)[reply]

Printability

Just wrote an essay on printability (

printworthiness

) at:

• Wikipedia:Printability

Maybe another step toward a

guideline? – Paine Ellsworth^CLIMAX! 08:22, 15 February 2015 (UTC)[reply

]

"Sort"? You mean "list"?

If you follow the hint to "DISPLAY CATEGORY SORT →" and press "Show", what gets displayed is a list of categories, so why not just say "DISPLAY CATEGORY LIST →"? I find the former wording slightly confusing. --Deeday-UK (talk) 22:42, 25 March 2015 (UTC)[reply]

Actually, what is displayed is (or are) an explanation for why the redirect is sorted to a given category(ies). So "sort" is more precise than "list", where the latter might be more than just "slightly" confusing to most editors. – Paine Ellsworth^CLIMAX! 04:18, 26 March 2015 (UTC)[reply]

Sort as in "an instance of sorting", then, which is the last of the six meanings given by Dictionary.com. I was familiar only with the first five. Maybe "DISPLAY CATEGORY SORTING →" could remove any doubt? --Deeday-UK (talk) 12:24, 26 March 2015 (UTC)[reply]

Sorry, I'm not sure I understand how "sorting" would be less confusing than "sort"? The definition of "sorting" at Dictionary.com seems to be completely different than what is meant here, which is simply a "sort" to a specific category. "Sort" is also used on Wikipedia to denote the way a page is sorted to a category that is called the {{DEFAULTSORT}} (not "defaultsorting"), so "sort" would still seem to be the more consistent usage, don't you agree? – Paine Ellsworth^CLIMAX! 17:13, 26 March 2015 (UTC)[reply]

Why the collapse, and why collapsed by default?

A major annoyance when viewing or previewing redirects using this template is having to click to show the tags on the redirect.

1. Why is the template message folded? I'm not aware of other text on redirect pages that could benefit from hiding the categories.
2. Does it have to be folded by default?

Note: The following user CSS will keep the categories displayed, but if no overriding concern exists, removing the folding templates from the template would be the cleaner solution.

.redirectMsg~table tr {display:initial!important}

85.178.197.197 (talk) 13:14, 10 June 2015 (UTC)[reply]

Template-protected edit request on 17 June 2015

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove

• {{This is a redirect/collapse top}} and
• {{this is a redirect/collapse bottom}}

They appear to serve no other purpose than to unnecessarily introduce the need to click to view the list of categories. 85.178.195.203 (talk) 00:17, 17 June 2015 (UTC)[reply]

Not done: please establish a

edit protected}} template. — Martin (MSGJ · talk) 07:59, 17 June 2015 (UTC)[reply

]

@

WP:BOLD is obviously not available here. 85.178.195.203 (talk) 09:45, 17 June 2015 (UTC)[reply

]

@

talk) 11:08, 17 June 2015 (UTC)[reply

]

Actually, I'm not sure if I am okay with it. The issue has risen in the past, and there is discussion on this talk page about it. Where the IP seems to feel consensus is established is just a question as to why the collapsibility is present. I see no consensus there, silent or otherwise. The question was only there for a week, and I've been pretty busy lately. However, I will happily answer the IPs question:

• As editors who work on redirects and their categorization make their checks, the thing they check for most is what categories have been used to sort the redirects. When they come to a page that has been tagged with this template, the collapsibility provides a quick look at the categories at the bottom of the page without the need to scroll down the page. To be clear, registered users are able to see the hidden categories at the bottom of the page. It would cost registered editors a lot more time as they check many redirects to have to scroll down to the bottom of the page rather than to just view, check categories and be on to the next redirect. This applies both to manual editing and to usage of
  AWB
  .

So I hope after knowing this, the IP will see that all they have to do is to sign in to Wikipedia as a registered editor to be able to see the hidden categories – there will be no need to have to open the collapsed box to view them. – Paine  20:58, 17 June 2015 (UTC)[reply]

OK, but should we not place more emphasis on the users of this template, rather than its maintainers?

talk) 01:28, 18 June 2015 (UTC)[reply

]

Not really sure what you mean, Alakzi. For me, the "users" of this template are the editors who consistently tag redirects with Redr and up to seven rcats – and the more rcats used, the longer Redr would appear without the collapsibility – of whom I am an ardent "user". It is true that I also work to maintain this template and make it as easy to use as possible, but that is just a fraction of the amount of time that I spend "using" this template to tag redirects. Since I am an ardent user of this template who has no problem with its collapsibility, exactly how am I placing less emphasis on "users"? What am I missing? – Paine  05:48, 18 June 2015 (UTC)[reply]

If I'm reading the documentation correctly, this template is meant as a wrapper of R from/to templates. I'm not a frequent user of R templates; I might type in one from memory, but I'd still want to preview before saving. I suppose this is really quite minor.

talk) 14:10, 18 June 2015 (UTC)[reply

]

I guess it's just me then. I do what you describe quite a lot, and I always try to remember to preview my edits cuz I do make mistakes, at least one error per year and sometimes a bit more. I suppose that I zip up to that show link almost unconciously and click it to preview, so my perspective is probably a bit skewed. Since you're right in that this really isn't that big a deal, if you want the collapsibility gone, then just say so and it's gone. – Paine  16:33, 18 June 2015 (UTC)[reply]

Sorry I did not even look at the section above! I have now merged them so they are related. — Martin (MSGJ · talk) 11:59, 17 June 2015 (UTC)[reply]

NP, I should have been more explicit. 85.178.217.2 (talk) 12:05, 17 June 2015 (UTC)[reply]

A new subsection has been added to the template documentation that explains the need for collapsibility. Thought I'd mention it here. Best of Everything to You and Yours! – Paine  21:37, 17 June 2015 (UTC)[reply]

I should also mention that even registered editors are unable to view hidden cats unless they have checked a box in their Preferences. This is easily done, and the following steps should be taken:

1. Go to Preferences → Appearance
2. Scroll down to Advanced options
3. Check the box Show hidden categories
4. Click Save

You may need to

A retrospective +1 to the removal of collapsibility. Overtime that's going to save us collectively millions of clicks. --Deeday-UK (talk) 12:02, 14 December 2015 (UTC)[reply]

There are times when one creates a redirect for a topic to an article but over time the topic is either removed from the target article or migrated to another article. I am thinking that including an optional parameter "target_article_permid" would allow one to add the version id of the target article, which would be used for annotation / review purposes only, not for a functional change. Granted, this could be included in the e0 comment. An alternative to manual addition might be inclusion of an auto-populated annotation parameter which would take the id of the target article at the time of redirect placement and add it as a comment on the talk page of the redirect. This would not be that useful for mature articles, but for articles without a substantial edit history or those which have been recently created, it could be helpful for discerning why a redirect was placed in the first place and help in "fixing" misdirected redirects. --User:Ceyockey (talk to me) 23:36, 3 July 2015 (UTC)[reply]

Yes, that is a very good idea! As a past monitor of Category:Redirects to an article without mention, which I notice has once again grown from zero to 171 occupants, there have been many sifts through page histories to try to find out why a redirect targets a certain article. Although I'm not sure how to implement it, an automatic parameter would probably be the ideal application. In many cases it would be a huge time saver. – Paine  14:56, 4 July 2015 (UTC)[reply]

I've noticed @

I don't think we can say what "the preference of the community is"; I'm not aware of any formal RfC on this question. However, my preference is very strongly to use the redr template only when there are several R templates. Peter coxhead (talk) 11:33, 21 August 2015 (UTC)[reply]

There is one advantage to {{

redr}} that I know of - it automatically detects any protection, and displays an appropriate padlock icon, thus removing the need for any {{R fully protected}} or similar. --Redrose64 (talk) 16:12, 21 August 2015 (UTC)[reply

]

To editors Ceyockey, Headbomb, Peter coxhead and Redrose64: I have entered a note to that effect in this template. Pleasant pathways, Painius  10:09, 25 October 2015 (UTC)[reply]

There is currently a discussion at

What I saw was a little box containing numbers and letters (sometimes known as tofu) - this is what happens when the desired character is not found in any of the installed fonts. I think that the numbers and letters are 01F310, which would be Unicode Character 'GLOBE WITH MERIDIANS' (U+1F310), which does not have much font support.

It is bad practice to use characters (whatever they look like) for setting a gap between two parts of a list - it's not just the fonts installed on somebody else's computer, but you need to consider accessibility too.

Regarding the <hr /> tag - some of its attributes are obsolete in HTML5, but not all are (it still recognises the global attribs like class= id= and style=); and the obsolete ones all have replacements. For example, width="25%" becomes style="width:25%;" like this -

---

If you want information on accessibility, try

WT:ACCESSIBILITY. --Redrose64 (talk) 08:21, 23 December 2015 (UTC)[reply

]

Thank you,

sandbox along with the removal of a superfluous "if" function that had been introduced along with the now extinct collapsibility. I'll engage it in the live template in a day or two so as not to load down the queue and servers. Thank you for being here! Happy holidays! Paine  09:01, 23 December 2015 (UTC)[reply

]

One change that can be made to the template is that it should have all templates in one parameter, like Template:Multiple issues, rather than separate parameters. 96.41.0.15 (talk) 17:29, 25 January 2016 (UTC)[reply]

I'd be interested to hear what you think the benefits and drawbacks would be.  Be prosperous! Paine  12:21, 27 January 2016 (UTC)[reply]

Sandbox version

This is to open a discussion about the new code in

{{This is a redirect|rcat=
 {{R from move|embed=yes}}
 {{R from alternative spelling|embed=yes}}
 {{R printworthy|embed=yes}}
}}

As can be seen, the new code does not eliminate the need to include the |embed=yes parameter inside each rcat. To get the sandbox version to accept the rcats like this:

{{This is a redirect|rcat=
 {{R from move}}
 {{R from alternative spelling}}
 {{R printworthy}}
}}

...without the |embed=yes parameters, will take a major edit to every rcat. That is why I opened this discussion here. It is important to learn what editors think about both the new code in this template's sandbox as well as the need to edit the rcats to eliminate the need for the embed parameter. Not long ago I would have gone ahead and implemented these changes; however, more and more editors have become interested in redirect categorization (a very good thing), so consensus is needed before changes like this can be made. If you have already read the

I think that it is worth spending some time defining what the redirect categorization system is intended to do - and why.

For me there is clear value in understanding the nature of the terms redirected "from" and "to" because this is of use to understand how to treat links, and useful metadata (for Wikidata for example). E.G. redirect from typo should not be wiki-linked to (except from list-of-typo pages) and will become a {{

Confuse

}} hat-note if the redirect becomes a dab page or an article.

Redirect "to" categories have inherent problems in that the target can move, double redirect bots do not, AFAIK update the templates.

Redirect by subject might be better moved to talk page as part of project banners ("Redirect" class items).

All the best: Rich Farmbrough, 20:59, 17 February 2016 (UTC).[reply]

These are good discussion issues, and I think that the rcat system is in place mostly to track redirects that may need editing. Different editors track different categories, for example, I track these categories and try to keep them current. What do you think about the edit in the sandbox version of this template that allows from one to several rcats to tag redirects under just one parameter instead of seven? And what do you think about the changes needed to every rcat in order to use the sandbox code without having to include the |embed=yes parameter in every rcat?  Paine  21:42, 17 February 2016 (UTC)[reply]

It sounds like a good idea. Changing 200 templates is fine if it helps, maybe there is some encapsualtion that makes it simpler? Not sure why the the paramter needs a name. All the best: Rich Farmbrough, 21:27, 18 February 2016 (UTC).[reply]

Thank you, Rich! I have looked and looked for a simpler way to lose the embed parameter, but I haven't yet found one. The parameter, |rcat=, is a named parameter because the unnamed parameters are used in the present version of this template on several thousands of redirects. To use an unnamed parameter instead of rcat= would mean fairly major changes to all those redirects. This is a consideration, of course, and might be done eventually, which would simplify this template a great deal. We might look upon this as a step-by-step process toward improvement, and these are just the first steps. When we finish this step, then we can go on to the next and edit all those redirects to comply with a much simpler version of this template.  Paine  23:00, 18 February 2016 (UTC)[reply]

• Thanks for the notification, Paine. My primary concern is that Rcats are transparent. "R" as an abbreviation for "Redirect" is widespread and intuitive enough, but otherwise, I'm always a bit peeved when I have to open another window and plug in something like "Rsh" to discover what it means. As Rich points out, Rcats can become non-applicable after page moves, and those can really only be updated manually. We should reduce friction in areas like this. Opaque template shortcuts have come up at RfD sometimes, and as I've said there, I'm really concerned that they're a barrier to participation, especially in an already esoteric area like redirect categorization.

For that reason, I never use the "This is a redirect" shell anyway, but if the proposed change makes it easier to parse which Rcats apply, that's an improvement in my book. I appreciate the convenience of shortcuts and abbreviations, but we need to strike a balance between convenience and comprehensibility; IMO, we need more of the latter. Like just about everything else in the project, we want to encourage more editors to get involved. --BDD (talk) 21:31, 17 February 2016 (UTC)[reply]

(edit conflict) It's a pleasure, BDD! We have had our diffs differences in the past on shortcut issues, and since I've found that many editors, new and experienced, are agreeing more and more with the "comprehensibility" side of the issue, I've begun to restrict my usage of shortcuts. I have altered my template scripts to use "This is a redirect" rather than "Redr", and I have decided to use, for example, "from shortcut" rather than "rsh". It's quite a change for me, but I'm adjusting. I think it would be better in several ways if we could get this template to apply several rcats under one parameter. That will also be quite an adjustment for me; however, I certainly don't mind making that adjustment if several editors find it to be an improvement both to this template and to the rcats themselves.  Paine  21:54, 17 February 2016 (UTC)[reply]

It's unclear to me what the benefits are of the new 'one parameter' syntax for {{

Redr}}; is it to eliminate the limit of maximum seven redirect categories (which seem plenty to me)? From the point of view of an editor that goes about categorising redirects, the new syntax seems to require a lot more typing (especially of braces) and formatting, so I wouldn't say it makes the job easier. --Deeday-UK (talk) 21:45, 17 February 2016 (UTC)[reply

]

There are some benefits, for example, as it is now if an editor wants to use parameters from an rcat, then they must know how to use the |p#= and |n#= parameters to apply them. If there is only one parameter with rcats used in the manner demonstrated above, then each rcat can pass any or all of their parameters in a normal manner with no restrictions. A maximum of seven rcats is almost always enough, so that would only be a mini-benefit of this edit. While the new code would require more typing (on the surface), there are ways to get around this, for example by using a template script like I do.  Paine  23:05, 17 February 2016 (UTC)[reply]

Paine, I can't thank you enough for your flexibility here. It would be easy, and not entirely justified, for you to get a bit righteous about this when it's an issue you work so hard on. But just look at how active this discussion is! It's heartening to see such interest, and I'm hopeful that any changes made here will help lower the barriers to entry for other editors to get involved with Rcats. This is absolutely how Wikipedia is supposed to work. Cheers all around. I'm going to go ahead and unwatch this, since I'll keep using the Rcat tags directly, but I'm always up for a good discussion about redirects. --BDD (talk) 15:47, 18 February 2016 (UTC)[reply]

• I also am tired of seeing strings like that look like {{
  WPBS}} to make that unnecessary should be done here. Ideally, I should be able to wrap an existing "stack" of rcat templates with {{this is a redirect|}} and }} and move on. It's also fine that it can accept other forms of input. It's important that it be able to support meaningful parameters (sometimes two+) on rcat templates, as they're already entered, without |p3= type workarounds. More later. Bunch of work to do today.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:58, 17 February 2016 (UTC)[reply
  ]

Again, you and BDD aren't the only ones who prefer longhand names, so I now try very hard to use either longer, more comprehensible shortcuts or the entire template name. I plan to add the rcats I use most often to my TemplateScript list, which will mean just a "one-click" will supply the whole template name. I recently did that with the "{{Redr}}" shortcut and am using the whole "{{This is a redirect}}" with just one click. The embed system is used so that the Redirect template templates in each rcat (there are presently two) can tell if it's being used within the This is a redirect template or used individually to tag a redirect. This will be unnecessary if we decide to go with the edits under discussion here. One benefit of using only one parameter addresses what you mention about the "p#" parameters. Each rcat used within the one parameter will be able to apply its own parameters in a normal manner with no restrictions. Enjoy your day!  Paine  22:53, 17 February 2016(UTC)

• I would like to be able to type {{R|from capitalization|to diacritics|from move}} although I really don't mind putting three separate lines with lots of extra curly braces; I do it so fast as I have a system for creating redirects where I enter a pound sign then type in REDIRECT with no space, hit space bar, tap in two opening square brackets and two closing brackets brackets, hit enter twice, type in as many opening and closing curly braces as I estimate I'll need with line breaks between each set of four, then I backtrack and fill out each R template, then paste the article name between the the four square brackets.

Where I get stuck is in Template namespace or such since the rcats don't work in all namespaces and putting them in wastes my time while I hit Preview over and over to make sure I'm not treading the line.

If I get stuck, I throw in a {{

This is a redirect}}, they go in a special misc. category and then without fail Paine Ellsworth

steps up and tidys up my work.

PS: I have done thousands of redirect category entries but I am clueless about the shorthand ones. I would welcome a combined template but it ain't no big deal to me. I hope my efforts are helpful in some way. Cheers! {{u|

Talk} 22:55, 17 February 2016 (UTC)[reply

]

Your efforts are very welcome and helpful,

Checkingfax, and it is great to know that you preview your edits before saving. Some editors who don't realize that some rcats are only used in one or two namespaces apply them anyway, which makes more work for those who have to make the corrections. It appears that your present method would fit right in with these changes – if you were to begin with {{This is a redirect|rcat= and then insert all the curly-braced rcats after the "rcat=" (either on the same line or on their own separate lines, and no more pipes needed), then place an extra set of closing curly braces ( }} ) at the end, you would find your method very compatible with the proposed sandbox version of this template.  Good faith! Paine  00:25, 18 February 2016 (UTC)[reply

]

Paine Ellsworth, sometimes I get cocky and do not do a preview and it bites me every time‍—‌especially if I do not check my Save afterwards.

What about embed=yes for each set of curly braces? Is that going to be the norm? Cheers! {{u|

Talk} 00:42, 18 February 2016 (UTC)[reply

]

We've all been there. Even now I sometimes forget to preview and get "stung". It reminds me how important it is to preview even for more experienced editors. The |embed=yes parameter would be needed with the sandbox version of this template; however, if editors agree here to make the same or similar edits to all the rcats that I made to the {{R from incorrect name}} rcat's sandbox, then there would no longer be a need to use that embed parameter.  Paine  00:49, 18 February 2016 (UTC)[reply]

• Question - @Paine Ellsworth: Can it be simplified a step further:

{{This is a redirect|
{{R from move}}
{{R from alternative spelling}}
{{R printworthy}}
}}

which would mirror {{multiple issues}} even more closely?

Comment - Editors are more familiar with the {{multiple issues}}. That being said, the format change suggested in this section would be a improvement and simplification of the "This is a Redirect" shell. As long as it doesn't affect the functionality or display of the rcat templates when placed individually without the shell, I'm all for it. —Godsy^(TALK_CONT) 00:59, 18 February 2016 (UTC)[reply]

I haven't done that much rcat work, myself, but I do appreciate the work others have done. I think closely mirroring {{multiple issues}} is a good idea. The named parameter is probably less complicated to implement, but without it, it would likely be friendlier for others to use. If it's too complicated, a new template would be simplest... Also, not to bring it up for discussion now, but since it's mentioned above, I'd like "to" templates to have a parameter for the target page, because of double redirect fixing, but I'm not sure how appropriate that would be. —PC-XT+ 03:59, 18 February 2016 (UTC)[reply]

To editors Godsy and PC-XT: I would like very much to make this change so that the |rcat= parameter isn't needed and the first unnamed parameter, |1=, can be used. That is actually a long-range goal of mine and will require major edits, probably by bot, to the redirects that are already tagged with the present version of the This is a redirect template. Until then, this is a good interim change that will help many editors, especially newer ones, with the application of this template. The way to edit the rcats (in the same or similar manner that {{R from incorrect name/sandbox}} is edited) will not alter their functionalities in any way; however, they will display a little differently when used individually. For most of the rcats the differences in display will be negligible, yet there are a few that may need more thought. To illustrate, here is an example of the basic display difference:

{{R from incorrect name}} – the present individual display:

• This is a redirect from an erroneous name, i.e., either an incorrect name or a title that is unsuitable as a Wikipedia article title or other project page name. The correct name is given by the target of the redirect. For more information follow the bold category link.
  • Pages that use this link should be updated to link directly to the target without the use of a piped link that hides the correct details.

{{R from incorrect name/sandbox}} – the proposed individual display:

I did consider creating a new version of the This is a redirect template to accomplish this, and that is also a consideration to be discussed here. It's not part of my proposal because I thought it would be better to do it this way; however, I am always open to hearing the benefits of a new template as opposed to the drawbacks.  Good faith! Paine  00:08, 19 February 2016 (UTC)[reply]

• (edit conflict) Comment'. Paine notified me of this discussion. I don't mind it provided:

1. It is not a breaking change either in usage or in the resulting look of existing pages.
2. It is neither enforced nor preferred over separate rcats.
3. It does not change the look of of existing pages.
4. It does not attempt to sort rcats into some order different from that specified by the editor.
5. Any collapse box is expanded by default. Si Trew (talk) 04:03, 18 February 2016 (UTC)[reply]

I second those conditions, part of which I alluded to in my comment above.—Godsy^(TALK_CONT) 05:07, 18 February 2016 (UTC)[reply]

• To editor Si Trew: These proposed changes have been tested and nothing will be broken on existing pages. As in the past, the choice of whether to use this template or individual rcats to tag redirects will continue to be in effect. There will be very little change to existing redirects. The main minor display change is illustrated just above in my response to Godsy and PC-XT. The sorts will be ordered in the way an editor puts in the templates, and since each rcat will pass its own parameters when needed, there will be no p#–n# problem if an editor places a new rcat at the top or beginning of the sequence. And there is no longer any default collapsing – while some editors seem to have liked the collapsibility that has been removed, if it is reinstated in the future then it will be by parameter and not by default.  Good faith! Paine  00:08, 19 February 2016 (UTC)[reply]

• My main concern is to get rid of the need to use |p1=, |p2=, etc. So any change that fixes this issue has my support, subject to the conditions that Si Trew gave above. Peter coxhead (talk) 11:49, 18 February 2016 (UTC)[reply]

• Thank you, Peter, and that is one of the main benefits of this proposal. Each rcat will be able to pass its own parameters within its own curly braces. There will no longer be a need for the p# and n# parameters, and if an editor inserts a new rcat at the top/beginning, then that will not affect the parameters of the other rcats in any way.  Good faith! Paine  00:15, 19 February 2016 (UTC)[reply]

• I've been out of the loop for a long time, so I'm very confused by this conversation. Firstly, just to clear something up, when you say we would need to edit every "rcat", do you mean the redirect categories or the templates for the redirect categories? I assume the latter. Secondly, what is the point of changing the code to simplify it in that way? Why would anyone use either of those mark-ups when the simplest code (that is already usable and the only code I thought anyone did use) is {{This is a redirect|from move|from alternative spelling|printworthy}}? McLerristarr | Mclay1 13:35, 19 February 2016 (UTC)[reply]

• It's good to hear from one of the people who helped shape this template early on! Matt, you have been missed while you've been "out of the loop"! To dispel the confusion, your assumption is correct – the categories will remain as they are, and the rcat templates themselves will need to be updated in the same or similar manner that I have done at {{R from incorrect name/sandbox}}. Your second question's answer is not uncomplicated and has to do with several suggestions from editors over the years, and especially in the discussion at MediaWiki talk:Move-redirect-text#Redr. For awhile, the This is a redirect template had been used to automatically tag redirects that were the result of renamed pages. Then an editor challenged that usage, which resulted in the MediaWiki talk page discussion. Let me illustrate one of the major benefits of this new code. For the longest time, one of this template's shortfalls was its inability to pass parameters from individual rcats. So if there was, say, a redirect that was printworthy and yet was an "other capitalization", which defaults to "unprintworthy", there was no way to use this template, because:

• {{
  This is a redirect
  |from other capitalisation|printworthy}}

...would populate both the Printworthy redirects and Unprintworthy redirects categories. The |e#= explanation parameter gave me an idea: Most all of the rcat templates have no more than two unnamed parameters, |1= and |2=. So I installed two parameters in the This is a redirect template, |p#= and |n#= to allow it to pass an individual rcat's unnamed parameters in the following manner:

• {{
  This is a redirect
  |from other capitalisation|p1=printworthy|printworthy}}

That code passes the {{R from other capitalisation}} rcat's first parameter, and the redirect populates only the Redirects from other capitalisations and Printworthy redirects categories, not the Unprintworthy redirects category. This worked well except for cases where another editor would come along and change the sequence:

• {{
  This is a redirect
  |from scientific name|p1=plant|printworthy}}

The above populates two categories... Redirects from scientific names of plants (the specific "plant" category) and Printworthy redirects. Now suppose another editor checks the history and finds that the redirect is also the result of a page move. That editor alters the code to:

• {{
  This is a redirect
  |from move|from scientific name|p1=plant|printworthy}}

Many editors forget to update the "p#" parameter to "p2=plant", so the redirect populates the Redirects from moves, Redirects from scientific names (the general category) and Printworthy redirects categories. This problem can be very frustrating for the editors who monitor the science redirect categories; it also applies to all the other rcats that have parameters that rely on the sequencing – even the |e#= parameter suffers from this flaw. The new code in this template's sandbox gets rid of problems like this:

{{This is a redirect|rcat=
 {{R from scientific name|plant}}
 {{R printworthy}}
}}

...if altered to:

{{This is a redirect|rcat=
 {{R from move}}
 {{R from scientific name|plant}}
 {{R printworthy}}
}}

...will only add the Redirects from moves category and not alter the Redirects from scientific names of plants category. After you read through the discussions, both here and on the MediaWiki talk page, you'll better understand why the new code is needed. There is also new information below.  Good faith! Paine  14:04, 20 February 2016 (UTC)[reply]

New template

Some editors have indicated that a new template might be better than altering this template, so I have adjusted the code at

Sounds like a good plan, and a good name. ({{

Rcat shell}}) The change to this template could have worked, but it's less complicated to start a new one. After it is worked out, it should be easier for others to decide if they should be merged into one template. —PC-XT+ 06:19, 25 February 2016 (UTC)[reply

]

Thank you,

Follow Jimbo! Paine  02:12, 29 February 2016 (UTC)[reply

]

@

Nyuszika7H: Please give an example of pages(s) where this problem exists. --Redrose64 (talk) 21:42, 16 June 2016 (UTC)[reply

]

I think its to do with the automatically included protection level.

Template:This is a redirect#explanation parameters and Miley cyrus both have the top protection level bullet point in a separate list to other bullet points. (ping @Redrose64:) - Evad37 [talk] 01:50, 17 June 2016 (UTC)[reply

]

Ah, right, it only happens there. I thought it happened elsewhere too, but looks like I was wrong.

talk) 09:06, 17 June 2016 (UTC)[reply

]

I suspect a misplaced newline. If so, this edit should fix it, please check. --Redrose64 (talk) 09:13, 17 June 2016 (UTC)[reply]

Appearance is much better! What a difference a small change can make.  

What's in your palette? Paine  22:08, 17 June 2016 (UTC)[reply

]

To editor

Dustin: the discussions are above on this page. Since the {{Redirect category shell}} template was created to replace this template, then it should be used in the future to categorize redirects. So far, no one has come forward with a bot that's able to make the conversions, so I've been doing it manually as I go. It took me about six years to reach over 200,000 transclusions, so if I live long enoughI should be able to make all the conversions. Thank goodness there are more and more editors who help with these!  Paine Ellsworth  ^u/c 13:56, 18 January 2017 (UTC)[reply

]

To editor Paine Ellsworth: I was surprised too. I have fixed some today and realized its very easy to convert the old once if they only have one R from/to. That can be done easely with AWB. Therefore, I suggest adding something like {{#if:{{{2|}}}||[[Category:This is a redirect called with just one parameter]]}}. Christian75 (talk) 20:21, 4 March 2017 (UTC)[reply]

Furthermore, I suggest adding a preview warning on the old template, see

Template:This is a redirect/sandbox (preview it and see the warning). Christian75 (talk) 20:21, 4 March 2017 (UTC)[reply

]

To editor

sandbox. That will be seen on all redirects that are tagged with this template and hopefully will get editors to convert to the Rcat shell. Let me think about it some more – maybe make a maintenance category named Redirects tagged with This is a redirect or something similar.  Paine Ellsworth  ^{put'r there}  05:37, 5 March 2017 (UTC)[reply

]

To editors

sandbox and will implement it as soon as I decide whether or not to categorize. At this point I'm tending toward waiting until the number of transclusions of Redr is significantly lower, since I see little sense in starting a category with nearly 300,000 entries. What do you think?  Paine Ellsworth  ^put'r there  00:46, 9 March 2017 (UTC)[reply

]

@

redr

}} and the names of the various redirect templates that they won't necessarily use preview—but combined with the warning seen on the transclusions of the template, it would probably stop any large-scale additions of it and also would stop most if not all folks new to redirect-tagging from getting into the habit of using Redr. An additional positive of the on-transclusion warning is that it makes it even easier to see at a glance which redirects already had their template converted versus which ones still need conversion.

A maintenance category has some use, but fairly little that in this stage cannot be accomplished by simply checking Special:WhatLinksHere to find the transclusions, except that it shows even fewer of them per page than WhatLinksHere is capable of. It would add a hidden category on the page, but with the on-transclusion warning that's pretty redundant—anyone can see the warning, while hidden cats are, well, hidden to most folks.

By the time we're down to a smaller number, and especially by the time we're basically just catching new additions of it, it might have some practical uses simply because once we're caught up, few folks will remember to check the transclusions of an old, deprecated template whereas a category has a bit more visibility through the whole categorization tree structure. Even so, I think it might be more useful at that point to simply make a category for all redirects using deprecated redirect templates, be it Redr/This is a redirect, R to AfC namespace or its shortcuts or any others (which probably exist but I don't know from top of my head). AddWittyNameHere (talk) 21:51, 9 March 2017 (UTC)[reply]

Okay, sounds good, and I'll implement Christian75's preview warning sans any categories for now.  Paine Ellsworth  ^put'r there  08:25, 10 March 2017 (UTC)[reply]

I've been fixing a few slowly, as I come across them organically. I approve of the new "The template below has been deprecated. Please convert to or use its replacement template instead." notice to spread the word; no need for new occurrences to fill the place of the old and work against those fixing them. — Godsy ^(TALK_CONT) 10:47, 10 March 2017 (UTC)[reply]

Yes, and I thank Dustin and Christian for spurring me on. The transclusions for this template have been steadily rising, so we had to do something to update the editors who help categorize redirects.  Paine Ellsworth  ^put'r there  15:08, 10 March 2017 (UTC)[reply]

The on-transclusion warning of deprecation seems to help. There were 279065 transclusions when I logged off yesterday (~5am utc, I think), there's 278405 now. We're no longer acquiring new transclusions as fast as the old ones get fixed. AddWittyNameHere (talk) 16:19, 10 March 2017 (UTC)[reply]

Firstly, thanks To editor Paine Ellsworth: for implementing the warning. Secondly the fall in transclusions is my fault. I fixed a few thousands yesterday with AWB (replacing one string, with another string. E.g. replacing {{redr|from move}} with {{{{Redirect category shell|\n{{R from move}}\n}} (\n newline, same syntax as Ellsworth is using). I have 50+ rules now to replace one string to another string. Christian75 (talk) 11:09, 11 March 2017 (UTC)[reply]

@Christian75:: Yeah, a couple of us were quite busy yesterday I think, you most of all--you certainly fixed a huge number and I checked a large number of specific types of redirects and fixed the bunch of 'm using redr. (syntax I'm using as well for the most part, easier for whoever has to edit the redir later because it's far more visible where one template starts and another ends). Just so you know, there's no need for you to look at redirects to monotypic taxa: I've sorted out all three subcategories and am about three-quarters done checking the main category. AddWittyNameHere (talk) 14:30, 11 March 2017 (UTC)[reply]

Hello, Category:Redirects from molecular formulas contains 3396 redirects, and 2677 of them are tagged with {{Redr|rmf|p}} (I have checked it with AWB on a dump). I propose we request a bot owner to convert:

{{Redr|rmf|p}}

to

{{Redirect category shell|

{{R from molecular formula}}

{{R printworthy}}

}}

We should ask for the same for {{redr|from move}} which was automatically added to all moved pages in the period from 18 Oct 2013 to 6 Oct 2015. Comments? Christian75 (talk) 11:33, 11 March 2017 (UTC)[reply]

@Christian75: Sounds like a possible idea, though I could do it manually (with the help of keyboard shortcuts, browser tabs and copy-paste) in ~2-2.5 days (willing to start once I finish checking the last bunch of redirects to monotypic taxa, though I'll wait for a response here--if I'm finished with redirects to monotypic taxa before you or someone else answers, I'll either go convert some other redrs first or do one of the other Burdens Of Repetition Eternal (BORE) I'm dealing with) so I'm not entirely certain if getting a bot owner to do it would actually be faster due to having to request and then wait for someone to take up the task (and possible discussion at BOTREQ, etc.) (On the really large groups of redirects though, a bot certainly would be faster even with the additional time for requesting the task, getting a bot owner to respond and all that). AddWittyNameHere (talk) 14:42, 11 March 2017 (UTC)[reply]

@Christian75: And they should be done now. As the last page showed only 195 rather than the expected 196 articles for the last remnant, there's probably one page out there I didn't see. Considering the scope (a couple thousand articles), it's also well-possible I may have accidentally skipped a very small number of them though a spot-check didn't show any cases of it. If you want, you could re-scan with AWB on a dump so we'll catch what few if any are left, though my gut feeling says 'if it's not 100% fixed, then it's at the least 99.5% done; whatever may possibly be left is so small a number they may as well wait until someone gets to them through the transclusion list'. Up to you though.

As to redr-using redirects from moves lacking all other templates...those almost all need at least one additional template. There's probably too many of them to manually fix faster than a bot could, but as someone would have to eventually double over all of them to add the missing templates, it's perhaps still more efficient to let someone manual-fix them. Not sure, would have to ask @Paine Ellsworth: what they think. AddWittyNameHere (talk) 04:30, 14 March 2017 (UTC)[reply]

The following redirect-template redirects (that's 'redirects in template-space to redirect-templates', to clarify) still use Redr, and are template-protected (or at least are in Category:Template-protected redirects. I found a few semi-protecteds in there, though, so I may have missed one or two being mis-catted) so I can't actually convert them:

• Template:Redirect from modification, Template:R from alternative punctuation, Template:R from alternative title (All three to {{R from modification}})
• Template:Protected redirect, Template:Redirect protected (both to {{R fully protected}})
• Template:R from ASCII
• Template:R from EXIF
• Template:R from name without diacritics, Template:R from title without diacritics (both to {{
  R to diacritics
  }})
• Template:R no print
• Template:R to list
• Template:R yes print
• Template:Redir from US postal ab
• Template:Redirect from initialism
• Template:Redirect from school
• Template:Redirect to decade

The following non-redirect-template redirects ('redirects in template-space to any template that isn't a redirect-template') still use Redr, and are template-protected as well:

AddWittyNameHere (talk) 15:48, 11 March 2017 (UTC)[reply]

@AddWittyNameHere: The template is already checking for protection level, so it would be quite easy (for e.g. @Paine Ellsworth:) to add two categories. One categories which list redirects which only sysops can edit and one for template-editors. Christian75 (talk) 21:01, 11 March 2017 (UTC)[reply]

The latter exists: Category:Template-protected redirects. Something about how it categorizes them is faulty, though—it threw in a bunch of merely semi-protected ones, too. My main purpose in listing them wasn't so much getting them categorized as getting the entire list out there so that either Paine Ellsworth or someone else with either template editor or sysop rights can find them all without either me needing to separately request sixty or so template-edits or them needing to sort through everything to find them. :) AddWittyNameHere (talk) 21:24, 11 March 2017 (UTC)[reply]

But the category is polluted with redirects which are converted to "Rcat shell", and it only lists templates. A lot of other types of pages are protected too. Christian75 (talk) 01:01, 12 March 2017 (UTC)[reply]

Yup, but non-templates are either full-protection, in which case I need a sysop anyway, or there's simply semi/pending/extendedconfirmed, in which case I can do it myself. Mind, a category for full-protected ones is useful enough—I merely meant there's no need to create a separate category for the template ones since I already sorted out the most applicable category there. AddWittyNameHere (talk) 06:18, 12 March 2017 (UTC)[reply]

@

this is a redirect}} within the pages that you listed above to {{redirect category shell}}, except Template:- and Template:TL (which are fully protected), and Template:WikiProjectBannerShell (which I'll let someone else handle). Best Regards, — Godsy ^(TALK_CONT) 05:10, 12 March 2017 (UTC)[reply

]

@Godsy: Thank you! AddWittyNameHere (talk) 06:18, 12 March 2017 (UTC)[reply]

Yes, thank you very much, Godsy! I've converted the banner shell and made fully cascade-protected edit requests for the other two. I still find some shortcuts to redirect templates that AWB has missed for whatever reason, and I will work from the category and make those conversions as well.  Paine Ellsworth  ^put'r there  12:57, 12 March 2017 (UTC)[reply]

Okay, both Template:- and Template:TL have been updated and their protection levels changed.  Paine Ellsworth  ^put'r there  14:53, 12 March 2017 (UTC)[reply]

Nice! Thanks for following up on those, Paine! Is this talkpage going to be the place for posting updates to the conversion process or should I make a talk-subpage? (On the one hand, that'd keep 'status updates' from flooding this talk page...on the other hand, I suppose that with the deprecation, it's not like this talkpage has any other purpose any more anyway...) AddWittyNameHere (talk) 14:59, 12 March 2017 (UTC)[reply]

Thank you! This talk page will probably do just fine for the updates when needed.  Paine Ellsworth  ^put'r there  18:30, 12 March 2017 (UTC)[reply]

• Update. I've gone through about 20% 60% of the category and have found many rcat shortcuts that needed conversion to the Rcat shell. I've also gone through all of their talk pages and have converted those where they existed. So a gentle reminder to all who work on these conversions... the subject-page redirects you convert might also have associated talk pages that are usually, if they exist, in one of two states: 1) they are redirects themselves and will need either conversion from Redr or to be initially tagged with the Rcat shell and appropriate rcats, or 2) they have been turned into talk pages, sometimes with project banners, Old RfD templates and maybe even discussions – these should have the {{Talk page of redirect}} template at the very top. Thanks to everyone who helps out with these ultimately gnomish and usually unsung tasks!  Paine Ellsworth  ^put'r there  23:21, 12 March 2017 (UTC)[reply]

Thank you for the reminder. Most of what I'm doing at the moment (the molecular redirects mentioned somewhere up on this page--~41% through them and I estimate to be finished with them around March 14th somewhere in the 7-11am UTC timeblock if all goes well, or the 6-9pm timeblock if I encounter unexpected delays) is pretty much talkpage-free, from what little attention I've paid the talkpages, but I'll readily admit they tend to slip my mind. AddWittyNameHere (talk) 23:33, 12 March 2017 (UTC)[reply]

Mine also, even now sometimes. However, there are a bunch out there that I didn't forget over the years and that are probably a fairly significant part of my old Redr tags. The vast majority of the talk pages for the rcat shortcuts didn't exist, so AWB skipped right over them, but there were a few that were tagged with Redr, and fewer still that either had individual rcats or no rcats. Anyway, don't be too hard on yourself. ;>)  Paine Ellsworth  ^put'r there  00:58, 13 March 2017 (UTC)[reply]

Nah, just felt like facepalming because it's obvious enough I ought to have remembered, but oh well, even if I were to purposefully ignore them, they'd eventually be caught and fixed through the transclusion-list once everything else is done, I suppose, so it's not a huge issue. Still, better to fix the entirety of a page at once and all that. AddWittyNameHere (talk) 16:03, 13 March 2017 (UTC)[reply]

• Update. Just finished AWB-ing Redirects to redirect templates, so all of the rcat shortcuts and convenience links should be converted. That's lunch.  Paine Ellsworth  ^put'r there  17:30, 13 March 2017 (UTC)[reply]

Great! There was something a bit painful about seeing deprecated redirect templates on the very redirects to redir templates. I'm about to do session 2 out of a predicted 3 in molecular redirects, then dinner, then continue on for most of the night (UTC, though since I'm in UTC+1, there ain't much difference) and wrap those up. If anyone has identified any other similar-scale groups of redirs all needing the exact same conversion, let me know and I'll put those on the list of 'what am I converting next'. AddWittyNameHere (talk) 17:56, 13 March 2017 (UTC)[reply]

@Primefac: Your changes looks nice :-) I found one case where it doesn't work. An example from the /doc [2]:

{{This is a redirect
  |e0=See '''{{-r|(Other redirect title)}}''' for printworthy redirect.
 |from airport code
  |e1=* ''This airport code has been discontinued.''
 |from ambiguous page
  |e2=* '''Note:'''  ''The ambiguity is easily disambiguated.''
 |from London bus route
  |e3=* (This bus route is to and from Maidenhead.)
 |from Unicode
 |unprintworthy
  |e5=* ''Up to '''eight''' of these '''{{para|e#}}''' parameters may be used – the '''{{para|e0}}''' as a '''TOP note''' as well as one {{para|e#}} parameter for each different rcat.''
}}

"subst:" gives:

{{redirect category shell|{{R from airport code
  }}
* ''This airport code has been discontinued.''{{R from ambiguous page
  }}
* '''Note:'''  ''The ambiguity is easily disambiguated.''{{R from London bus route
  }}
* (This bus route is to and from Maidenhead.){{R from Unicode
 }}{{#if:
   |{{#if:
    |{{R unprintworthy
  |{{{p5}}}|{{{n5}}}}}
    |{{R unprintworthy
  |{{{p5}}}}}
   }}
   |{{R unprintworthy
  }}
  }}
* ''Up to '''eight''' of these '''{{para|e#}}''' parameters may be used – the '''{{para|e0}}''' as a '''TOP note''' as well as one {{para|e#}} parameter for each different rcat.''|h=See '''{{-r|(Other redirect title)}}''' for printworthy redirect.}}

It produces the right visual output, but my impression was that a bot should subst them all. Christian75 (talk) 11:17, 17 April 2017 (UTC)[reply]

Christian75, that's very odd. As far as I'm aware, when you pass a parameter to a template it ignores whitespace (e.g. putting every param on a new line in an {{infobox}}), so I don't know why it would re-insert it here. I'll look into it.

I know the e, n, and p parameters are deprecated, so I've added some tracking cats to see what's actually being used. It might be that we can just cut a lot of the code and make it less likely to break when substed. Thanks for finding this! Primefac (talk) 12:40, 17 April 2017 (UTC)[reply]

It depends on the type of parameter. For named parameters, and also for explicitly numbered parameters, leading and trailing whitespace is stripped from parameter values. However, for positional parameters, all whitespace is preserved. Consider the two lines

 |from airport code
  |e1=* ''This airport code has been discontinued.''

- here there is one positional parameter and one named parameter, and the newline after the first instance of the word "code" is significant. If however they had been written as

 |1=from airport code
  |e1=* ''This airport code has been discontinued.''

the only difference is the addition of two characters 1= but we now have one numbered and one named parameter, and the newlines are all stripped. When doing this it's important to explicitly number all of them, otherwise you may find unexpected effects. --Redrose64 🌹 (talk) 20:45, 17 April 2017 (UTC)[reply]

Of course, the other issue we have to consider is that (technically speaking) {{

rcat shell}} doesn't actually accept random comments made in the code, so even when substing something inline like -ihah

you end up with some odd-looking code. I think we have to ask ourselves whether the extra note is proper to include.

{{redirect category shell|{{R move}}{{R hatnote}}
* '''Note:'''  ''See '''[[Instituto Hondureño de Antropología e Historia]]''' for hatnote mention.''{{R related}}{{R sect}}{{R unprintworthy}}}}

{{redirect category shell|{{R move}}{{R hatnote}}
* '''Note:'''  ''See '''[[Instituto Hondureño de Antropología e Historia]]''' for hatnote mention.''
{{R related}}{{R sect}}{{R unprintworthy}}}}

{{redirect category shell|
{{R move}}
{{R hatnote}}
* '''Note:'''  ''See '''[[Instituto Hondureño de Antropología e Historia]]''' for hatnote mention.''
{{R related}}
{{R sect}}
{{R unprintworthy}}
}}

I'm not really keen on any of those options, but if we're trying to keep those random notes then we're going to have issues with formatting (regardless of whitespace). Primefac (talk) 15:09, 18 April 2017 (UTC)[reply]

If that third option is desired, it might require a bot run for formatting. Primefac (talk) 15:22, 18 April 2017 (UTC)[reply]

• One more ping to see if anyone's keen on commenting, otherwise I'll just remove the reliance on the eX parameter and only subst the actual templates. Primefac (talk) 18:57, 26 April 2017 (UTC)[reply]

It could be really nive if this template was not deleted after all the subst'ing. and kept as a subst only template. Does that require a new TfD? Christian75 (talk) 13:42, 4 May 2017 (UTC)[reply]

Christian75, my original intention (once all extant uses are substed) was to simply redirect this to the rcat shell. I don't think changing that would necessarily require a new TFD, but it would definitely require some sort of consensus. Primefac (talk) 14:21, 4 May 2017 (UTC)[reply]

Thanks, I hoped someone would see this - but I havn't pinged anyone and do not think I will do it. Christian75 (talk) 14:01, 16 May 2017 (UTC)[reply]

It is a good idea to keep as a subst: only, because it can be very fast. However subst will only replace the cabalistic symbols with marginally less cabalistic ones. Better for HPB to make intelligent replacements. All the best: Rich Farmbrough, 09:53, 28 May 2017 (UTC).[reply]

User:Primefac boldly added made this auto-subst only. I reverted him. He re-reverted. We had I thought, agreed to a compromise where I would stop doing good replacements, and he would stop doing bad replacements. Therefore I restored the status-quo ante. He has reverted me again - and 6000 more items have been subste'd.

I am restoring the status quo once again. We can now discuss.

Discussion

Further to the request at Bot requests I have invested a significant amount of time in producing a method of replacing this template, in the most useful way I can. Conversely I understand Primefac has invested effort in making the template substable. Nonetheless the substing method is comparatively poor and sometimes wrong.

For this reason I propose that the template not be further substed, at least with the current set-up, but instead we suspend work on this until the BRFA is approved, and do the thing that actually gives better results.

All the best: Rich Farmbrough, 10:04, 28 May 2017 (UTC).[reply]

Rich Farmbrough, I ran the autosubst past a few users, double-checked everything, and even cleaned up a few messes I made along the way. Yet all I have heard from you is complaining and not a single reason why the autosubst is sub-par. The only thing I can see that your bot run does that autosubst doesn't is add white space. I don't think that's enough to sideline the substitution of the template. Primefac (talk) 13:06, 28 May 2017 (UTC)[reply]

• It deals with {{{e1}}}.... etc.
• It leaves those that have parameters outside the e, p, n series for manual processing.
• It replaces parameters with carefully chose templates rather than blindly prefixing "R ".
• It doesn't leave red-linked R cats.
• It follows the layout on the doc page.
• It removes redundant colons.

Is that not enough?

All the best: Rich Farmbrough, 14:41, 28 May 2017 (UTC).[reply]

It's great. Some of them are minor points (the layout given by the autosubst is listed as an acceptable arrangement on the /doc), but overall I can see the benefits. While I am partially culpable, it would have been nice to have had this conversation two weeks ago and saved all the drama. Primefac (talk) 14:50, 28 May 2017 (UTC)[reply]

Good! Just to clarify on layout, in the deep dark days of yore, redirects could only have text on the fist line, and there were some of these that used the template.

All the best: Rich Farmbrough, 15:56, 28 May 2017 (UTC).[reply]

this can't be right ... Frietjes (talk) 15:48, 31 May 2017 (UTC)[reply]

Frietjes, that particular issue was fixed, and while I thought I had found the erroneous edits apparently I was wrong. Also, this template is no longer being autosubst. If you have a good way of finding these erroneous substitutions I'm all ears, because I've searched three times now and have fixed everything I've discovered. Primefac (talk) 15:56, 31 May 2017 (UTC)[reply]

Primefac, should be possible with a regexp match + tracking in the redirect category shell. but, that would add some processing overhead. the other option would be to go through the bot's edit history during the time period when this was happening and check all of those pages. Frietjes (talk) 15:58, 31 May 2017 (UTC)[reply]

@Primefac and Rich Farmbrough: All remaining transclusions of this template are on fully protected pages. —Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:18, 11 June 2017 (UTC)[reply]

Indeed, by my reckoning there should be 99 of them. All the best: Rich Farmbrough, 12:41, 11 June 2017 (UTC).[reply]

Plus 4 not in the Category:Protected redirects, making 103. All the best: Rich Farmbrough, 12:46, 11 June 2017 (UTC).[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Replace the following: {{Wikidata redirect}} with: {{Wikidata redirect|Q14450647}} @CLYDEFRANKLIN 17:52, 25 August 2022 (UTC)[reply]

To editor

ed. ^put'r there 18:10, 25 August 2022 (UTC)[reply

]

Template-protected edit request on 19 August 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Edit request: change {{

 Completed.

ed. ^{put'er there} 19:50, 19 August 2023 (UTC)[reply

]