This page is within the scope of WikiProject Redirect, a collaborative effort to improve the standard of
redirects and their
categorization on Wikipedia. If you would like to participate, please visit the project page, where you can join the
discussion and see a list of open tasks. Note: This banner should be placed on the talk pages of project, template and category pages that exist and operate to maintain redirects. This banner is not designed to be placed on the talk pages of most redirects and almost never on the talk pages of
mainspace redirects. For more information see the template documentation.RedirectWikipedia:WikiProject RedirectTemplate:WikiProject Redirectredirect pages
This template was considered for
deletion on 15 November 2009. The result of the discussion was "keep".
This template was considered for
deletion on 8 April 2012. The result of the discussion was "keep".
This page is a redirect from...
The "from..." bit should be deleted. It is pointless to tell someone the name of the page they are reading. Also, with no parameters, it will just read "This page is a redirect from Example." which is incorrect since it is not a redirect from Example, it isExample. McLerristarr |
Mclay106:52, 2 December 2010 (UTC)reply
Use of this template
I have begun to use this template whenever I can, but there are times when I don't think it can be used, which is sad because this is such a good template. Most recent examples are:
Millenniums, where I was able to use this template, and
Since {{R from plural}} has the ability to subdue the
Unprintworthy redirects category and automatically add the redirect to the
Printworthy redirects category by just piping the word "printworthy" in this way: {{R from plural|printworthy}}, and since the This is a redirect template uses pipes to separate redirect templates, I still don't see a way to use this template for printworthy plurals. Is there any possible way to do this? If not, is it being worked on? Thank you in advance for any help you can give. –
Paine Ellsworth (
CLIMAX )
00:00, 18 April 2011 (UTC)reply
I noticed that both the template and the /doc page were miscategorized. The culprits were the {{R from alternative language}} and {{R from Unicode}} redirect templates. I caught this by noticing that the This is a redirect template was in the Unprintworthy redirects category under the "T's". The R from Unicode was putting it there, because it was used in the example on the /doc page. My solution was to use the {{Category handler}} in the R from Unicode Rcat, and then replace the presently editprotected R from alternative language with an Rcat that also had the Cat handler and was without an ifeq parser sequence, the {{R from ambiguous page}}. –
PIE (
CLIMAX )
23:17, 15 February 2012 (UTC)reply
please add or link to a usage list of parameters and values
I just found out about this template today; I don't think I heard of it before. I had been using R templates; I gather this is a replacement. While the doc gives a few examples of parameters and values, it's unclear, and if someone could please add a list of parameters and values so that we unfamiliar users will know how to use it without having most redirects treated as miscellany that would probably be helpful. I don't think I want to be programming ifeq functions into most redirects and while a free-form text parameter makes sense I don't know why there are six and when to use which. Thank you.
Nick Levinson (
talk)
16:47, 24 November 2013 (UTC)reply
Hi, Nick Levinson – This template is basically just a "shortcut" way to apply up to six R templates at a time. I don't use the "e#" parameters, but I do use this template a lot rather than to type out all the R templates individually:
#REDIRECT [[(target page)]]
{{Redr|from move|from modification|from alternative spelling|printworthy}}
("Redr" is just a shortcut for "This is a redirect") ...and so on. I built a comparison page at
Template:This is a redirect/Comparison to give an idea of the difference in appearance. There will hopefully come a time when readable text will be allowed on redirects. When that time comes I hope that most redirects will have this template on them rather than just the individual Rcats.
The one major drawback with this template is that some Rcats take parameters, like the ones that can be changed from unprintworthy to printworthy, or the {{Ralterlang}} that takes language codes. Those Rcats can be used in the This is a redirect template, but not if the parameters are needed. We haven't yet figured out a way for this template to take Rcats with parameters. – Paine EllsworthCLIMAX!19:26, 24 November 2013 (UTC)reply
I still don't understand what values to put into which parameters. I've seen diffs with the template being used more recently and still don't know how the R templates are being transformed into these. So I expect to continue to add R templates to new redirects I create but I hope this template's doc is clarified sometime by someone and that I find out about it. I don't know what to write in the doc, so I'm not the one. Thanks.
Nick Levinson (
talk)
18:25, 1 December 2013 (UTC)reply
Well, what might be a little confusing is that most Rcats (R templates) have "shortcuts", so you may see these shortcuts used on more recent examples. I use shortcuts all the time to save time. The above example with shortcuts might look like this:
...which would add the exact same categories. Forgive me, but I am still unclear as to what would make the /doc page better for you. This is very important, because if the /doc page is too technical, or if it is too unclear in any other ways, then it does need to be improved. Please try to give me a better idea as to what the /doc page requires. – Paine EllsworthCLIMAX!18:54, 1 December 2013 (UTC)reply
A shortcut to this template is not a problem. I tend to write long names for clarity for other editors but redirects also work.
What to write as a parameter's value is what I don't know. In your example just above, I guess "mod" is for "R from modification", but when I look at the list of
common R templates "mod" is not there. (It's at {{R from modification}}, but it's rare to look at individual pages when the R list is much more convenient to use.) And that's the direction we need to work in: We need to be able to go from the list of R templates and know what to write in the parameter space, because if I just write what may be a reasonable abbreviation this template may not recognize at all. So a list of acceptable parameter values is needed, and the values probably should be added into {{R template index}}, into each table row. Or, if this template's doc can be made self-sufficient, it should have a complete list of values ordered much as they are in {{R template index}}. That likely requires adding advice to both doc pages to ensure coordination of updates, so when either one is updated so is the other (manually), which doesn't always happen with other template pairs but is better than not so advising.
If some R templates are not compatible with this template, that should be specified for each affected R template, so we'll know when to use an R template after this template in a given redirect.
I gather there are 12 parameters (6 anonymous and 6 named) and that all are optional (even that using any one parameter does not require using any other), but I'm not sure.
And I don't know if the order of the parameters matters (it seems to), so the doc should tell us whether it does or not and, if it does, what the order should be.
If a template like {{
R from modification}} exists, you can use whatever comes after the R, you don't need to use any shortcuts or abbreviations. This works whether the R template is the true name or a redirect. So, you can put either {{
this is a redirect|mod}} or {{
this is a redirect|from modification}} - they are exactly the same because {{
R mod}} is a redirect to {{
R from modification}}. Similarly, {{
redr|mod}} is identical in action to {{
redr|from modification}}
All R templates should be compatible with this template.
If you're not using the named parameters, the order of the six unnamed parameters is largely immaterial: {{
this is a redirect|from modification|printworthy}} is exactly the same as {{
this is a redirect|printworthy|from modification}}. However, if you use any of the six |en= parameters (to give explanations), the numbers of these are associated with the positions of the unnamed parameters. So, in the case of {{
this is a redirect|from modification|printworthy}}, an |e2= parameter (if provided) would be associated with the second unnamed parameter, i.e. |
from modification| If you specify two unnamed parameters, but also provide (say) |e4=, there isn't a fourth unnamed parameter for that to be associated with, so it is ignored. --
Redrose64 (
talk)
22:33, 1 December 2013 (UTC)reply
What's the plan?
Hi all, I've just happened across this template. It's good-looking and I like it. Is there a plan brewing to start rolling it out across the project, or...? Also, I'm a little confused by its not appearing the same way on the pages where it's used so far - for example,
Millenniums. —
Scott•talk11:22, 2 January 2014 (UTC)reply
Hi, Scott – I don't know about others so much; I use this one all the time. Millenniums is an example of a redirect that had not been categorized, and I used this template to do so. The appearance may be different based on its position and the use of its shortcut {{Redr}}. You've been around awhile, so you may know that there was a time when the position of
Rcats (redirect category templates) was once a limitation issue. That is no longer the case, so you may find these in any one of several different positions on a redirect edit screen. I try to position it for readability, since there has been comment by new editors that some code is hard to read. You may have seen the
comparison page that shows the difference between how Rcats appear when they are used individually and how they appear when used in this template. Of course, this will only become important when
T16373 and
T44642 are fixed.
Maybe you know of some way to fix the only major problem with this template? Let me describe it:
Using
Millenniums as an example, let's say we decide that it is a "printworthy" plural instead of "unprintworthy". This becomes important if Wikipedia ever becomes a fully printed encyclopedia. So let's say that Millenniums, like
Millennia, is printworthy. Up until a little while back, the only option was to tag the redirect with the individual Rcat and its piped parameter, as in {{R from plural|printworthy}}, which subdues
Category:Unprintworthy redirects and populates
Category:Printworthy redirects. This is still the only option for most Rcats that can have their printworthy/unprintworthy status or other detail (for example, {{R from alternative language}}) altered with a parameter. Some time back, an editor created R from printworthy plural as a workaround, but I think it would be better if we could get this template to directly accept an Rcat's parameter when needed. I've tried using {{!}} in place of an Rcat's pipe, which is a neat trick that works in hatnotes, but it does not work in this template for some reason. Perhaps you know of something that might work? – Paine EllsworthCLIMAX!18:24, 2 January 2014 (UTC)reply
I want to thank you,
Scott, because as a result of our little talk here, I worked several hours to come up with a way for this template to accept one optional, unnamed parameter from each Rcat. This means that editors can now use this template's parameters p1 thru p6 to include params from the individual Rcats. For example, one can use {{This is a redirect|from plural|p1=printworthy}} to subdue {{R from plural}}'s default populating of
Category:Unprintworthy redirects and instead place the redirect into
Category:Printworthy redirects. I've updated the /doc in case your interest continues. – Paine EllsworthCLIMAX!05:23, 31 January 2014 (UTC)reply
In addition to this template's six seven parameters that allow it to hold up to six seven different rcats, it will now accept most or all of the parameters that are found in some rcats. It now accepts...
one unnamed parameter from each rcat, and
a second parameter from each rcat that is enabled by "2=".
Can you fix it not to repeat the "Unprintworthy" message? Silly question I know you can! (I would suggest just having it at the end of the list.) All the best, RichFarmbrough,
19:18, 10 April 2014 (UTC).reply
To editor
Rich Farmbrough: Forgive me for not responding sooner – I'll have to work on that one. Since the redirect is only sent to one of the printworthiness categories only one time (no matter how many rcats are included on the redirect that can send it to one of those categories), I felt that was the important thing. The appearance of the often repeated "Printworthy" or "Unprintworthy" messages should be addressed, so I will definitely look into it. – Paine08:21, 11 September 2014 (UTC)reply
Thanks! All the best: RichFarmbrough, 08:50, 11 September 2014 (UTC).
I came across this template at
Annales des empereurs du japon. It took me some time to figure out what it meant. The reason is that to me, the large "" symbol at the left of the template looks like it is pointing at one of the three bullet points. In other words, at first glance I assumed that the three bullet points were three possibilities, and the large arrow indicated which of the possibilities applied to this page. It is only because I recognized the {{
ambox}} style, which always has a vertically centred image on the left, that I figured out what was actually going on. I think if I was less familiar with that convention I might have remained confused. Is this a problem that needs fixing? Personally I think yes. —
Noiratsi (
talk)
09:46, 17 July 2014 (UTC)reply
Sorry it has taken so long for you to get a response,
Noiratsi – and also for any confusion caused by the general redirect symbol, "". That general symbol is used on pretty much everything that has to do with redirects and the
WikiProject. Do you have a specific suggestion as to how this can be improved in this template so as to decrease or dispel any confusion? – Paine EllsworthCLIMAX!08:33, 11 September 2014 (UTC)reply
Thanks for your reply! It's hard to say what would work better. The symbol works well when it's just next to a single line of text, or in places like {{
User WikiProject Redirect}}. It's only when it's next to a bulleted list like on the page I linked to that I think it might be confusing. Is it possible to do something like move the symbol closer to the top of the box, so that it 'points' at the first line, where it says "This page is a redirect"? Of course, if it's just me that finds it confusing, then it's no problem; I just wondered if others might be confused in the same way I was. —
Noiratsi (
talk)
09:26, 11 September 2014 (UTC)reply
(
edit conflict)
When I see words like "if it's just me", I am reminded of how businesses rate their consumer letters. When a consumer writes in either to give kudos or to complain about something, the company leaders give a certain "weight" to each letter. So one letter may be multiplied and treated as ten opinions (as if ten people wrote in with the same opinion), or a hundred people, sometimes even a thousand opinions. In a vast community like Wikipedia, one person who is confused will most likely equal a whole lot more editors who are (or may become) confused by the same problem, as well.
Right now I'm at work on a collapsible option that may help in this regard. When I finish the tests, I'll point you to an example to see what you think about it. Collapsing the template after the first rcat might just help to make the image less confusing, especially for those redirects that are tagged with several rcats. – Paine12:57, 11 September 2014 (UTC)reply
I have an idea for this. In the {{
mbox}}, add the parameter |textstyle=border-left: solid 1px #c0c0c0; - this will draw a thin grey full-height vertical line between the redirect arrow and the rest of the box. --
Redrose64 (
talk)
12:46, 11 September 2014 (UTC)reply
Pleasure! – and thank you,
Redrose64, for thinking of making the left text border visible as a line! – Paine
What it's about
@
Paine Ellsworth:, @
Noiratsi:. It's not about how it looks but what it says. The Wikipedia rendering engine, people's own CSS styles, and how they have set up their browser, determines how it looks (I presume you tested on low resolution devices, readers for the blind, and so forth; see
WP:ACCESSIBILITY. What you have gained with a nice em line on a particular resolution with a particular Wikipedia skin that may be overridden client-side, you have lost tenfold in information. Let the rendering engine do it, that is what it is there for. There are experts at Wikimedia and people who have done those so they work as much as they can on low-bandwidth, low-resolution, monochrome devices or for that matter people who are reading it on a
Braille reader or through
speech synthesis or whatever: for all I know (I bet there is) there is some add-on that will put a box in the corner to turn it into
Morse code. I don't have to know that because I follow the Wiki markup rules and write in plain text with Wiki markup tags, and then those readers can intelligently parse those to provide the best attempt they can in ways other than you view it. And most of the time we can't even be bothered to put in a alt=tag, usually. I quite like that I edit in plain text and see all the markup because then I can see and at least have half a stab at seeing this kind of stuff. My dander is up.
Si Trew (
talk)
08:36, 20 January 2015 (UTC)reply
Lose the collapsible box and the glitz, it is not necessary at all. The only people who look at a redirect are editors who are interested in the redirect itself, and almost certainly they then want to know why it is redirected without having to fiddle with a fancy but useless collapsible box (what's with the title, non-functioning arrows that one would think would go to some link but don't, and and small caps in the useless title "-> DISPLAY CATEGORY SORT ->"? I guess it is {{
mbox}} that does that? It certainly doesn't display the category sorting, which is clearly displayed in the categories at the bottom. I must be some kind of idiot to think that it might link to
WP:Category sorting or something, and the "back" and "forward" arrows would indicate there may be other pages that might have more information, but don't.
{{
multiple issues}} doesn't do that, and that's in reader space. This is in editor space,[st note 1] and it just makes it more difficult for editors to find the information they want, with absolutely no good done by it. The data still has to be downloaded anyway, collapsed or not, it's just arty-farty fiddling. Make it always fully expanded and lose all the glitz.
Si Trew (
talk)
06:48, 20 January 2015 (UTC)reply
In a nutshell. This nail varnish makes it worse, not better. I looked up Annales des empereurs du japon. It was fine as it was with
User:Gorobay, a very good Japanese speaker (I don't think Gorobay is Japanese but that's none of my business) who regularly contributes to
WP:RFD with Japanese redirects, who made the correct redirect in 2011 with
]. Until 22 September 2014, that was fine, and the first edit to add stuff was fine, but then it (I presume) got carried away with changing the template itself just to make it look nice on that one sole redirect that nobody except editors will look at. I am on a hunt now but I have two in my sights.
Si Trew (
talk)
08:49, 20 January 2015 (UTC)reply
^By "reader space" I mean things likely to be seen by a WP user who is coming to look up information in the encylopaedia. "Editor space" means pages that are only likely to be seen by readers who are also editors, potential or actual, and with their "editor" hat on are trying to change the "encyclopedia that anyone can edit" to make it better, rather than on that occasion looking up information themselves. This is not the same thing as namespaces, as it's defined by purpose not technicalities, though some namespaces can be broadly put into one or other, many (such as talk pages and project pages) can't.
I agree, mostly. The template could use some visual simplification, especially the removal of collapsing. I get the impression that maybe half the point of the collapse is to emphasize "This is a
redirect:", but that could also be achieved by other means, like with a slight background color. The concern about the symbol could also be helped by aligning it only with this top section of the message box. I'm not sure if {{mbox}} is made to accommodate this placement though. If the point of collapsing is to take up less space, that's pretty trivial on a redirect page.
djr13 (
talk)
10:54, 20 January 2015 (UTC)reply
For visual simplificatiom read Cut the crap. It isnot used on redirects, it is used on a redirect template. To discuss any individually, go to
WP:RFD.
Si Trew (
talk)
21:08, 20 January 2015 (UTC)reply
{| class="wikitable"
|-
! [[File:Symbol redirect arrow with gradient.svg|16px]] !! This is a [[Wikipedia:Redirect|redirect]].
|-
|
| This redirect is:
* Redirect categories etc
* Listed here
|}
Thank you,
djr13 and
Si Trew, for expressing some interesting concerns. I've been working on this template for years, and it has been a fascinating learning experience for me. Much of what I know about editing templates I learned from experimenting with and testing this one. It was a process of evolution that has led to its present state and abilities. I have some work to do outside Wikipedia, so I will begin to address your concerns later today. I do want you to know, though, that I consider it to be a very simple template in terms of its appearance and have tested it in three browsers and all the skins. So any major changes to its appearance should go through that gauntlet again. When I come back later today, I will address your concerns one-by-one. Joys! – Paine EllsworthCLIMAX!17:20, 20 January 2015 (UTC)reply
Oh now I get it. You need to settle down, Mr. Si Trew. Djr13's edit looked fine in my IE10. It was YOUR edit that broke my post above. Not to worry, I fixed that, as "pre" tags are so much better than "code nowiki" tags in many applications. – Paine EllsworthCLIMAX!05:35, 21 January 2015 (UTC)reply
The reason I go so strongly is the page is protected, and as a non-admin I can do nothing about that (and I don't want to be an admin). As someone who uses these templates every day, yes, I have a vested interest. I had to get a change to {{
Expand French}} through by strong pushing because that was protected ({{
Expand Romanian}} and {{
Expand Spanish}} aren't for example) so I am sorry to go so strong, but if I don't then nothing gets done. I can't boldly edit it because it is protected, and I can't revert, so I come to discuss. And when I come to discuss then I get told off for doing so.
I want to make these templates better and I am sorry if I was too strong in my wording, but over the years of editing I know that if one is not, it just gets ignored. I was polite, I didn't swear, I didn't make any personal accusations, or anything like that. I, like you, want to make this template better, but I think you are taking it in the wrong direction. The talk page for the template is exactly the right place to do so.
Si Trew (
talk)
06:37, 21 January 2015 (UTC)reply
Present concerns about this template
I will attempt to address each concern in the above discourse that are expressly about this template. All are welcome to chime in and give opinions about the concerns expressed and my responses to them. Please give me time to address these concerns so there won't be any edit conflicts. – Paine EllsworthCLIMAX!04:14, 21 January 2015 (UTC)reply
It's not about how it looks but what it says. – Si Trew
Thank you. I chose the look so it would be different from other templates. It's present appearance is not that old, because it's appearance was not a large concern prior to the software modification in January 2014 that finally allowed text on redirects. It's present appearance has been tested in three browers and across all the skins. There have been no specific accessibility complaints about this template.
It should look the same as other templates that do similar jobs, for example, {{
multiple issues}}. It is not its job to look "different". (ST)
For what it's worth, I personally like the basic look of the template, and my concerns are very minor. Will respond by item!
djr13 (
talk)
08:42, 21 January 2015 (UTC)reply
Lose the collapsible box and the glitz. – Si Trew
The collapsibility serves the purpose of shortening the page for those editors whose only concern is to see what categories are populated. If editors have their hidden-category-visible option enabled, they will not have to scroll down to see the categories. The categories will be right there at the bottom of the short page. When editors would like more info about the rationales of specific categorizations, then they may click on the [show] link. As for "glitz", I'm not sure what you mean, and you yourself stated "it's not about how it looks".
I can see the categories at the bottom. If I want to know "why", I need to expand the box. Which would have been easier were the box already expanded. (ST)
I and others who often work with categories are used to having to go to the bottom of a page. On any page, content goes first, which on a redirect page could be considered the target (obviously) followed by brief notes on why that page currently redirects to the other. I believe there are ways editors can configure their settings or styles to put categories up top if they need to. Also, in fact, the "DISPLAY CATEGORY SORT—[show]" stuff alone takes up enough space to fit in one or two bullet points, reducing the benefit of saved space that collapsing might afford.
djr13 (
talk)
08:42, 21 January 2015 (UTC)reply
It certainly doesn't display the category sorting, which is clearly displayed in the categories at the bottom. – Si Trew
I'm not sure what you mean. The template, when open (uncollapsed) actually does display the category sort along with a rationale for why the redirect has been sorted to a specific maintenance category. And not all editors have their preferences set to see the hidden categories at the bottom, yet even those editors can view the category sorts by clicking on [show] – one simple click, quick and easy.
It's a
WP:SURPRISE. There are a whole load of gnomes at {{WikiProject Category Sorting}} and I would have thought that is where it linked.
...the "back" and "forward" arrows would indicate there may be other pages that might have more information, but don't. {{Multiple issues}} doesn't do that, and that's in reader space. This is in editor space... – Si Trew
There are no "back" arrows – the two arrows both point and lead the editor's eyes toward the [show] link. That is their sole purpose. Is there any reason to think they don't do their job? To compare this template with any "reader-space" template is like comparing apples and oranges. Editors need good tools to use to get their job done, and this template helps editors do just that.
So you think to have two arrows which are not arrows facing in opposite directions which are not linked to anything are a good idea? Why don't you link them to point to what they do? Answer: Because it is fancy but I can't be bothered to make it useful. (ST).
Okay, it is a right facing arrow on the left. Which is never a good thing to do as it confuses,
QED. (ST).
I looked up Annales des empereurs du japon. It was fine as it was with User:Gorobay ... who made the correct redirect in 2011 – Si Trew
Gorobay is an excellent contributor, no doubt about it. He is, as you indicate, a very focused editor with express language and Unicode symbol edits. While his edit to the above referenced redirect was "correct" and not "incorrect", it could be made "more correct" by the inclusion of {{R from book}} and the
printworthiness rcat. So while it was indeed "fine", I just made it "finer", and since I had come across this template by then and was working on it, I used this template to do so.
He is indeded, at least we are agreed on one thing. (ST).
I am on a hunt now but I have two in my sights. – Si Trew
I have no idea what you mean by this, but it does not sound very good. I suggest you try to relax and calm down so you can talk about these things objectively.
I do, but I didn't express it well. It was not angry or personal. I meant simply that I was going to look at some edit histories of two templates. I can see why you would think I was on a "manhunt" and I'm sorry if it seemed that way. (ST)
The template could use some visual simplification, especially the removal of collapsing. – djr13
As I mentioned above, collapsibility serves the important purpose of shortening the page for those editors whose only concern is to see what categories are populated.
The concern about the symbol could also be helped by aligning it only with this top section of the message box. – djr13
I'm neutral on this one. If anyone can find a way to keep the arrow aligned with the top area, then I don't see any reason why it shouldn't be done.
I tried looking into this, and I'm not sure if it's possible. This template calls {{mbox}}, which calls
Module:Message box, which uses a table of all blasphemous things to accomplish its formatting goals.
At least by default, table cells are styled as vertical-align: middle; while we would want vertical-align: top;. Alternatively, we would want to change the table to have a different cell structure, so that, like in my mockup, the graphic and the header are on the same row. Neither of these appear to be possible with {{mbox}}. A third option might be to find some way to encapsulate or otherwise shove something else into the table cell to force the image to the top. That would be pretty ugly, code wise.
It is not used on redirects, it is used on a redirect template. – Si Trew
If you mean this template, it most certainly IS used on redirects. Redirect templates are used WITHIN this template to simplify both the editing and the code on redirect pages. And since a recent edit made to this template, it now has the ability to sense protection levels, both when they are applied and when (if) they are removed. And that's all done automatically.
Okay,
Si Trew and
djr13, I think that I've addressed all your concerns above, so if I've missed anything specific, then feel free to remind me, gently I hope. Let me suggest that if you would like to see any major changes to this template, either technical or aesthetic, you can create a subpage that would hold your version of the template, then link to it here on the talk page. That way, others would be able to assess your exact suggestions for improvements of this template. Joys! – Paine EllsworthCLIMAX!05:57, 21 January 2015 (UTC)reply
I've answered Paine Ellsworth's inline with (ST) after my comments. Thanks, PE, for addressing the concerns. Please be sure I was not having a go at anyone personally but I fundamentally disagree that it should "look nice" rather than "work well". Had it not been protected, I would have reverted and helped to improve it. I think it would be better to have listed for courtesy at
WT:RFD, and you're right I was a bit grumbly to stumble across this accidentally. Sorry about that.
Si Trew (
talk)
06:50, 21 January 2015 (UTC)reply
It's almost impossible to answer these things because of template transclusions. When one hits a section to attempt to answer, one is diverted to another. Now I am in good faith, but I am not sure whether the people editing the templates with admin rights that I don't have are in good faith. Now is that clear enough? Abuse of admin rights,
WP:BRD like the rest of us.
Si Trew (
talk)
11:15, 21 January 2015 (UTC)reply
Okay, I've responded to the concerns, and I've made some changes that editors can check out in this template's
sandbox and on its
testcases page. The colors have been changed to dark blue, while the redirect arrow has been lifted and stabilized in the upper left corner before the text "This is a redirect". The leading arrow has been removed before the text "Display category sort" and the arrow after that text has been changed to black. The show/hide link is now in standard color. I'm still not convinced that the collapsibility is not a good thing. I personally use it so much to go to a redirect, quickly check its categories, if I like what I see, then I move on to the next, if I don't like what I see, then I edit and scram. It's a lot faster (for me anyway) to not have to scroll down or hit CTRL End to see the categories. So anyway, I'd like to hear feedback on the sandbox version; if it passes your muster, then I'll make it go live. And just so it is better-known, one does not have to be an admin to edit templates (unless they're "fully protected"). I'm not an admin. "
Template editor" is one of several user rights, and anyone may apply for it
on this page. Joys! – Paine EllsworthCLIMAX!14:20, 21 January 2015 (UTC)reply
Protection detection
I have an idea. Modify this template so that it tests to see if the page is protected at any level (semi-, template- or full-prot). If it is edit-protected, transclude {{
pp-protected}}; otherwise, if move-prot, transclude {{
pp-move}}. This detection should be possible, because {{
documentation}} detects the prot level for the template, and applies a suitable padlock icon. If this is done, this should eliminate the need for edits like this. --
Redrose64 (
talk)
17:20, 11 August 2014 (UTC)reply
To editor
Redrose64: I found this code in the history of {{Documentation}} (before it was Luaized). I can introduce this here, but I wanted to check with you first to be sure it is the right code to use:
<!--
Automatically add {{pp-template}} to protected templates.
-->{{template other
| {{#ifeq: {{PROTECTIONLEVEL:move}} | sysop
| {{pp-template|docusage=yes}}
| {{#if: {{PROTECTIONLEVEL:edit}}
| {{pp-template|docusage=yes}}
| <!--Not protected, or only semi-move-protected-->
}}
}}
}}
Need to consider this. Although redirs are permitted in all namespaces except Module: (and perhaps MediaWiki:), only a relatively small proportion are in Template: space, so {{
pp-template}} will often be inappropriate. --
Redrose64 (
talk)
12:49, 11 September 2014 (UTC)reply
<!--
Automatically add {{pp-protected}} to protected templates.
-->{{#ifeq: {{PROTECTIONLEVEL:move}} | sysop
| {{pp-protected}}
| {{#if: {{PROTECTIONLEVEL:edit}}
| {{pp-protected}}
| <!--Not protected, or only semi-move-protected-->
}}
}}
That resulted in boxes above the rcat boxes with the appropriate padlock icons and messages, but does not place the icons at the top-right of the pages – see here and here (note the categories). Maybe you could test the sandbox version on a fully protected redirect (at least in preview) to see what happens? The above code probably needs a good tweak or two. – Paine19:57, 11 September 2014 (UTC)reply
(Should note that use of the small=yes param in the pp template eliminates the box – I kind of like the box, btw – and places the icon at the top-right of the page.) – Paine
I added |small=yes because that's what {{
documentation}} does. But there is still a problem for the cases where a page is move protected and not edit-protected: using {{
pp-protected}} on a page that is not edit protected will put the page in
Category:Wikipedia pages with incorrect protection templates. Besides that, I think that reusing the code from an old version of {{
documentation}} is not the whole story, mainly because it dates from before the introduction of the templateeditor right. I've put this together:
Besides catering for the templateeditor right, this also uses {{
pp-move}} where appropriate. I've coded it so that if the page is only edit-protected, or the move protection is of the same or lower level than the edit protection, it will show {{
pp-protected}}; but if the page is only move-protected, or the move protection is of higher level than the edit protection, it will show {{
pp-move}}. --
Redrose64 (
talk)
21:29, 11 September 2014 (UTC)reply
Well then, it seems that removing the protection rcats from the two redirects also removes them from their categories, so perhaps having this template detect the protection isn't such a good idea if it will cause multiple and confounding calls to the protection-banner module? – Paine13:29, 12 September 2014 (UTC)reply
Now you've lost me. You appear to say we should call {{R template protected}}from this template's protection code instead of {{pp-protected}} and {{pp-move}}? Since this template is used in all namespaces, how does that help? Will it even display the correct padlocks for other protection levels? – Paine17:32, 12 September 2014 (UTC)reply
I didn't say "call {{R template protected}}", I said "call {{
R template protected}} etc." - the "etc." is a placeholder for the list of other templates like {{
R fully protected}}{{
R semi-protected}} and so on. The point is that where the computer can automatically work out which one of several available is applicable, we shouldn't expect the user to add the right parameter to {{
redr}}. This is particularly important when the circumstances can change without manual intervention: prots aren't necessarily indef, so if a redirect is given a one-month semi-prot due to vandalism, as soon as the prot expires the prot template is no longer applicable, and the page drops into
Category:Wikipedia pages with incorrect protection templates (which is filling up - I can see that I need to go through that cat again). Having the {{
redr}} automatically show the appropriate icon, and then automatically remove it again when the month is up, without somebody remembering and going back to remove it manually, is surely a benefit. --
Redrose64 (
talk)
19:01, 12 September 2014 (UTC)reply
Okay, mybad for a complete miss of your "etc.", just very tired at the time. Next thing, just wonder why you included this...
...in your post? And now to your latest suggestion... "Still workin' on it, boss"
. It's a learning experience for me – I've never been too swift with the switch function. I do sense the need to include the protection detector within the mbox, so if an rcat is embedded, then it will be inside the Redr box and not outside looking tacky on a redirect page. Also, use of the rcats instead of the pp templates will not put the padlocks on the redirect page, nor will the redirect be added to the pp categories, so I wonder if there is a way to do both? I'll continue to massage it. O! and I almost forgot – I found a way to include your textstyle param without putting the point of the bent-arrow image right on the border line. It's in the
sandbox. – Paine10:57, 13 September 2014 (UTC)reply
I, too, sometimes do that when I use {{reflist}} in article sections on preview as I edit reference citations. __it happens.
Please see update b below. – Paine15:32, 14 September 2014 (UTC)reply
Protection detection update
Here is where it is presently, 12:11, 13 September 2014 (UTC) – I have repositioned the following code to just before the collapse top template:
(If placed inside the Cot/Cob templates the icon does not appear unless the [show] link is opened.) This code works only so far as the third part, the semi-protected part, as seen at the applicable test redirect. The silver padlock is present, top-right, and the rcat appears in the Redr box just above the collapsed part. Also, both the
Wikipedia semi-protected pages and
Semi-protected redirects categories are populated.
To editor
Redrose64: Could you set up a fully protected redirect as a test redirect that uses This is a redirect/sandbox in the same manner as the other two test redirects? Perhaps one like
Hoofdpagina, which has few links to it? If you could temporarily alter it from this:
#REDIRECT [[Main Page]]
{{Redr|for convenience|from shortcut|protected}}
{{R from alternative language|nl}}
to this:
#REDIRECT [[Main Page]]
{{This is a redirect/sandbox|for convenience|from shortcut|from alternative language|p3=nl|n3=en}}
This also incorporates the upgrades to this template that accommodate the params of rcats, so when we're done and you want to change it back, you can just alter This is a redirect/sandbox → Redr, which will update the code of the redirect.
Some of these already existed, I just needed to add {{
this is a redirect/sandbox}}. None of them are
G8-able, because I just happened to have fifteen sandbox pages in User: space, mostly without User talk: pages. Sandbox13 was created in error - setting semi-prot for moves is not sensible, unless edits are also semi-prot (as with Sandbox5). I notice that all three in the "Template" row throw an error: they shouldn't, because template-protection is available in all namespaces; conventionally, we only use it on Template: and Module: pages. --
Redrose64 (
talk)
19:24, 14 September 2014 (UTC)reply
Okay, I seem to be getting some unusual reads in my browser, so I'll analyze it some more and then create a summary of what I see. As for the errors in the "Template" row, I didn't anticipate that the template-editor right could be granted anywhere but in template space, so the rcat throws the error when used outside of template space. Since you're an admin you probably know the good reason for allowing the template-editor right to extend beyond template space, so {{
R template protected}} can be altered to include all namespaces. – Paine20:16, 14 September 2014 (UTC)reply
Concern
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? – Paine01:46, 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? – Paine15: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? – Paine02: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? – Paine01:18, 17 September 2014 (UTC)reply
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:
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
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! – Paine23:58, 11 January 2015 (UTC)reply
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 EllsworthCLIMAX!23:48, 29 December 2014 (UTC)reply
(a second comment)
Dustin V. S., I use {{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
Minor redundancy with "from code"
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
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
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
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 EllsworthCLIMAX!02:35, 21 January 2015 (UTC)reply
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 EllsworthCLIMAX!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 EllsworthCLIMAX!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.
Why is the template message folded? I'm not aware of other text on redirect pages that could benefit from hiding the categories.
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.
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. – Paine20:58, 17 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? – Paine05: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.
Alakzi (
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. – Paine16:33, 18 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! – Paine21: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:
You may need to
purge your browser cache to ensure that you can see hidden cats in the future. Almost every cat that is populated by rcats is hidden unless the above steps are taken by registered contributors. – Paine01:08, 18 June 2015 (UTC)reply
Enhancement suggestion - Article version parameter
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. – Paine14:56, 4 July 2015 (UTC)reply
Converting _redr_ to _R_ and vice versa
I've noticed @
Headbomb: doing some edits (
here and
here, for example) where the only substantive edit is to replace {{redr}} with {{R from ISO 4}}. Is it true that the preference of the community is to use R-templates when there is a single parameter and redr-templates to handle multiple parmeters? I have not noticed anyone else doing edits like this, but I'm not looking carefully. --User:Ceyockey (talk to me)
10:41, 21 August 2015 (UTC)reply
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
To editor
Redrose64: I was just looking for something to separate the protection text from the rest of the rcats. I think it's especially needed when the |e0= parameter is used to produce a top note, as shown in the
example on this page. If you agree, then perhaps you can suggest other potential separators? I tested the line code (----) and thought we could do better. I thought about decreasing the width of the line with the <HR> tag, but that tag's attributes are not used in HTML5. Do you have any other suggestions? Paine00:43, 23 December 2015 (UTC)reply
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:WCAG or
WT:ACCESSIBILITY. --
Redrose64 (
talk)
08:21, 23 December 2015 (UTC)reply
Thank you,
Redrose64! I believe I met the challenge another way. The e-zero param allows an optional topnote, so I removed it to the top above both the manifold sort text and the protection text if present. Now there is no need to introduce a separator of any kind, and thank you also for the gentle reminder about accessibility issues. The improved code is in the
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!Paine09:01, 23 December 2015 (UTC)reply
This is to open a discussion about the new code in
this template's sandbox that introduces a single parameter that can hold one or more rcat templates within it in the following manner:
{{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
temporary doc page, then you know that there is code in the {{R from incorrect name/sandbox}} that shows the needed edits to all rcats. This example rcat shows the simplest and basic changes that most rcats will need. Some rcats are more complicated and will require different, but similar code changes. There are more than 200 rcats, so it will take a little time to make the edits. When that is done, the sandbox version of this template will be ready to engage. Please leave your comments and opinions about this below, and thank you beyond words for your interest in redirect categorization! Good faith!Paine19:40, 17 February 2016 (UTC)reply
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).
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? Paine21: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: RichFarmbrough,
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. Paine23: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. Paine21: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. Paine23: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 {{
redr|rxy|ryz|rfoo|rjkl}}; it's annoying gibberish. It's fine that these exist as editing mnemonics for people who memorize them, but they should be bot-replaced with things like |R from alternative name or even |from alternative name, or whatever syntax the final version of this thing wants – as long as it's human readable (and even the "from" and "to" parts of these template names are meaningful).
It's not clear to me why we're using some |embed=y system; that was first also used with wikiproject banners and it was abandoned for a reason. Whatever is being done with {{
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|
Checkingfax}} {
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!Paine00: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.
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. Paine00: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(
TALKCONT)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:
From incorrect name: This is a redirect from an erroneous name – either an incorrect name or a title that is unsuitable as a Wikipedia article title or other project page name – that serves readers because it is a good search term. The correct name is given by the target of the redirect.
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.
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!Paine00:08, 19 February 2016 (UTC)reply
(
edit conflict) Comment'. Paine notified me of this discussion. I don't mind it provided:
It is not a breaking change either in usage or in the resulting look of existing pages.
It is neither enforced nor preferred over separate rcats.
It does not change the look of of existing pages.
It does not attempt to sort rcats into some order different from that specified by the editor.
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!Paine00:08, 19 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!Paine00: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 |
Mclay113: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:
...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:
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!Paine14: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
User:Paine Ellsworth/Sandbox for editors to see how the new template would appear. My suggested name for the new template is also included, {{Rcat shell}} or
Template:Rcat shell. One benefit for making a new template is that rather than having to use an |rcat= parameter, a single, unnamed parameter, |1= (or its equivalent, a single pipe symbol "|"), is all that's needed. Paine14:04, 20 February 2016 (UTC)reply
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,
PC-XT, I also am leaning in this direction. At some point, someone may want to take on the task of converting the many redirects that are presently tagged by the This is a redirect template to the Rcat shell template, then no merge would be necessary. Follow Jimbo!Paine02:12, 29 February 2016 (UTC)reply
I just noticed that this template has been "deprecated," yet I and undoubtedly others have been adding additional tranclusions while being unaware of this change. Would it not have been worthwhile to have a bot go through and replace the current instances? I completely missed the discussion about this change.
Dustin(talk)00:33, 24 December 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 enough
I should be able to make all the conversions. Thank goodness there are more and more editors who help with these! Paine Ellsworthu/
c13: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
To editor
Christian75: thank you very much for your interest in redirect categorization! Not sure how useful making a new category,
This is a redirect called with just one parameter, would be since the vast majority of uses of this template have two or more parameters. And while your preview warning is a good idea, it will only announce the deprecated status of this template to editors who newly apply this template to a redirect. I've been thinking about a warning that will be seen on all transclusions of this template, as I've shown in the
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 Ellsworthput'r there05:37, 5 March 2017 (UTC)reply
To editors
Dustin and
Christian75: perhaps the best solution is to use both the preview warning along with the notice above all the transclusions, the former to alert editors not to use Redr and the latter to notify editors who come to redirects that are already tagged with Redr. I've placed that code back in the
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 Ellsworthput'r there00:46, 9 March 2017 (UTC)reply
@
Paine Ellsworth: Such a warning would make sense. It probably won't keep every new addition away—particularly folks who've been tagging the occasional redirect for ages and are familiar enough with the syntax of {{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
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 (
TALKCONT)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 Ellsworthput'r there15: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
Suggest: Request a bot for Category:Redirects from molecular formulas
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
List of template-protected redirect & non-redir templates using Redr
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:
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:
Collapsed to avoid stretching the page. ~40 of them
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
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 Ellsworthput'r there12:57, 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
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 Ellsworthput'r there23: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 Ellsworthput'r there00: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
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
subst
@
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.}}
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}}}}
vs
{{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}}}}
vs
{{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
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
Keeping this template
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
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: RichFarmbrough,
09:53, 28 May 2017 (UTC).reply
BRD
User:Primefacboldly 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.
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'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.
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