Jump to content

Template talk:Redirect template/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Incorrect namespace template

Maybe there is a way to subdue this {{Incorrect namespace}} template entirely when an Rcat can be used cross-namespace? Mclay1, you seem to have a much better handle on the template code than I do. You might check out the recent edits at {{R from plural}}, where I collaborated with Martin to subdue the Unprintworthy redirects cat in favor of the Printworthy redirects cat on a few special redirects. Maybe the elegant code Martin used will give us a clue as to how to deal with the challenges of this template?  — Paine Ellsworth ( CLIMAX )  23:42, 22 February 2011 (UTC)

If a redirect template is used for cross-namespace redirects, then {{Incorrect namespace}} will not be transcluded. Its only transcluded if a redirect template is used on a namespace it was not intended for. For example, if a redirect template uses only the main category category parameter, the category will only be added to main namespace pages and {{Incorrect namespace}} will be added to non-main namespace pages. If the main category and other category parameters are used, one category will be added to the main namespace and another category will be added to all other namespace but {{Incorrect namespace}} will not be added. McLerristarr | Mclay1 04:38, 23 February 2011 (UTC)
Then perhaps I don't understand the problem as you've described it at the bottom of the /doc page: "This template automatically adds templates it is directly transcluded on to Category:All redirect templates. At the moment, the category is also added to template namespace pages that transclude redirect templates using this templates. Until this setback has been fixed, this template should not be used on redirect templates that can be used on template namespace pages." What then is specifically wrong that needs to be fixed?  — Paine Ellsworth ( CLIMAX )  00:31, 24 February 2011 (UTC)
If a redirect template using this template is used on a template namespace page, it will add the redirect to Category:All redirect templates. Only the templates this template is transcluded on should be categorised, not templates that transclude a template that transcludes this template. I don't know how to fix it. McLerristarr | Mclay1 03:20, 24 February 2011 (UTC)

Should redirects get feedback?

I'm not confident of correctly adding Category:Article Feedback Blacklist to the template, would a soul braver than I do so? Josh Parris 23:36, 26 February 2012 (UTC)

Is the consensus now to blacklist redirects from feedback? I only ask because I did not know that the feedback blacklist extended beyond dab pages. – PIE ( CLIMAX )  01:27, 5 March 2012 (UTC)

Inquiry

Please note my inquiry in the printworthy= section above. – Paine Ellsworth CLIMAX! 01:49, 8 August 2013 (UTC)

printworthy=

I just tried using the printworthy parameter at {{R from ATC code}}. Prior to this test of the {{Redirect template}} template, I had used {{Main other|[[Unprintworthy redirects]}} on the Rcat itself, and Category:Templates for unprintworthy redirects "includeonly'd" on the /doc page. According to the last paragraph of the /doc page for this "Redirect template", if the printworthy=no parameter is used, then the Rcat should automatically be added to the Templates for unprintworthy redirects cat. This does not appear to be the case. So I intend to revert my edits at {{R from ATC code}} and rm that paragraph on this doc page and bring it here to this talk page until resolved. Here it is:

Also, there are other anomalies with this template, both as noted on the /doc page, and as may be seen in an analysis of my reverted edits on this date at {{R from ATC code}}. – PIE ( CLIMAX )  06:30, 12 February 2012 (UTC)

Okay, this has begun to work again; however, I am not convinced why it is needed. Can someone more versed please explain why it is necessary to automatically put template redirects into the Category:Templates for unprintworthy redirects, which is usually limited to Rcat templates that possess this ability to categorize redirects? – Paine Ellsworth CLIMAX! 01:45, 8 August 2013 (UTC)

I see why it's needed now. It is not supposed to be seen on redirects; it is only supposed to categorize the Rcat itself that uses it and that has the printworthy= param enabled. – Paine Ellsworth CLIMAX! 16:44, 19 December 2013 (UTC)

Proposal

To alter this template so it can be used on template redirects.

  • Template redirect: any redirect that is in template namespace
  • Redirect template: a template that is used to tag redirects and sort them into categories – see WP:RCAT

The ultimate goal is to be able to sort template redirects that are incorrectly tagged with the wrong Rcats into Category:Pages with templates in the wrong namespace so they can be found, tagged and sorted into the correct category(ies).

Detail

There are two functions of the Redirect template template, together with the {{Incorrect namespace}} template, that need to be changed. The first goal is to stop this template from making all templates populate Category:All redirect templates when this template is used to tag them. There is no reason for this, since all redirect (category) templates (aka "Rcats") are already categorized by a /doc-page category link to the All redirect templates category. Disabling this will enable editors to use this template on Rcats that can tag "template redirects" that are not Rcats and that should not be sorted into the All redirect templates category.

The second challenge stems from this template's usage of the {{Incorrect namespace}} template. Most of the function of template Incorrect namespace is vital to this template. It provides this template with a notice that an Rcat has been wrongly used to tag a redirect in a namespace other than that for which the Rcat was intended. Even more importantly it places an incorrectly tagged redirect into CAT:WRONG, which is a category for Pages with templates in the wrong namespace. That category has recently been cleared, but there are still template redirects that are incorrectly tagged with no way of finding them until we alter this Redirect template template. The other template, Incorrect namespace, should not be changed because it is used in many other templates besides this one. A similar template exists that can replace the Incorrect namespace template in this Redirect template template. The replacement of the Incorrect namespace template with that template, {{Incorrect redirect template}}, is also a part of this proposal.

As a third part of this proposal, user namespace can also be included in this template. The code at {{Redirect template/sandbox}} contains the code necessary to include user namespace. That sandbox code is ready to "go live" as soon as discussion about this proposal allows.

Code edit

The code that needs to be omitted as part of this proposal to make the Redirect template template work correctly on template pages is as follows: 

== Template category ==

--><includeonly>{{#ifeq:{{SUBPAGENAME}}|doc||{{Template other|{{{category|[[Category:All redirect templates]]}}}}}}}</includeonly><!--

This code has been erased from the /sandbox version. In addition to the omission of this code and the addition of user namespace, the /sandbox version has replaced all occurrences of the Incorrect namespace template with the Incorrect redirect template template. Again, this means that the "05:20, December 22, 2013" version in the sandbox is ready to replace the live version.

Thank you for reading! – Paine Ellsworth CLIMAX! 06:00, 22 December 2013 (UTC)

Discussion 1

Updates:
  1. Since no discussion has been generated by this proposal, so no objection to it has been raised, I shall implement the change in a few hours. Joys to all! – Paine Ellsworth CLIMAX! 03:55, 31 December 2013 (UTC)
  2. This proposal went into effect with this edit on 31 December 2013. – Paine Ellsworth CLIMAX! 17:13, 31 December 2013 (UTC)

Recent disposal of Incorrect redirect template

To editor Technical 13: This is to talk about your recent edit that disposed of a crucial and integral part of {{Redirect template}} – the {{Incorrect redirect template}}. I have a proposal for you after I give a brief explanation as to why Incorrect redirect template is so important to Redirect template.

  • I have sandboxed your edit to help explain. In one of my own sandboxes, sandbox 7, you can see one of several results of your edit. It does accomplish placement of the rcat text on the page and does not sort to the Unprintworthy redirects category. And yet, please take a close look at the text. Like all rcats, that text is designed to explain to readers why a given redirect is sorted into a given category. That is the sole purpose of rcat text! Hopefully, you can understand why rcat text does not meet your expectations on redirect pages that are not sorted into the rcat's category.
  • Another of my sandboxes, sandbox 7a, has been set up to show how it is supposed to appear. This is important for those of us who monitor the redirect categories to know when an rcat has been mistakenly used to tag a redirect in a namespace other than that for which the rcat is designed. And it sends up a "loud" flag so, hopefully, editors will catch the error on preview, or at least they will see the error box when they save their edit, and then self-revert.
  • Here is what I propose: I suggest that the explanatory text you and other contributors want on redirects be incorporated into a new set of templates that are designed just for that purpose. That way, you will be able to tag a given redirect with the precise text you want – not text that conforms only to the categorization of the redirect – you can devise a more appropriate, more applicable explanation that does not imply that the redirect is going to populate a certain category.

It is sometimes a challenge for me to write with clarity. I sincerely hope that I have made it clear why Incorrect redirect template should remain in this template to perform its necessary purpose. I also hope that I have been helpful with a proposal to do a better job of what you want to do. If I have not been clear enough, I will be happy to answer any questions you may have. Joys! – Paine Ellsworth CLIMAX! 09:37, 9 March 2014 (UTC)

  • Moved from User talk:Technical 13 § R from alternative capitalisation
    Hi Technical 13. I've noticed that you've been declining quite a few edit requests that want {{R from alternative capitalisation}} removed from non-mainspace redirects. I can appreciate your reasoning here, but I don't think there is a consensus right now to change the way that that template is used. The template documentation has said, for quite a few years now, that it should only be used for mainspace redirects. If there is a consensus to change this usage, then I would agree with your declines, but if it's just you that is opposing it then I don't think that's enough to change the status quo. Also, as you seem quite passionate about changing the usage instructions, I think you should regard yourself as "involved" with that debate, and avoid answering edit requests related to it. There's nothing specifically in policy about this, but I do think that Wbm1058 has a point that it is not a good idea to decline requests that you don't have the permissions to fulfil. If they are obviously frivolous requests then I think declining them would be ok, but I don't regard request to remove {{R from alternative capitalisation}} as frivolous. — Mr. Stradivarius ♪ talk ♪ 14:29, 9 March 2014 (UTC)

Improvement of printworthy display

Please apply this edit (it includes an edit summary). — Petr Matas 19:34, 1 May 2014 (UTC)

 Additional information needed – Hi, Petr Matas, I tested this and can see no difference. Your es goes "Let {{R yes print}} know, whether we are being embedded in {{This is a redirect}}." How does your edit "let an rcat know" whether (or not?) "we" (who is?) are being embedded specifically in the This is a redirect template, which may or may not be used to categorize redirects? In other words, it is fuzzy and cloudy as to why this edit is needed and what it will do to improve the performance of {{Redirect template}}. Can you elaborate, please? – Paine Ellsworth CLIMAX! 03:07, 3 May 2014 (UTC)
The redirect 1902 glider contains the non-embedded {{R with possibilities}}, which expands to {{Redirect template|...|printworthy=yes}}, whose part currently expands to {{R yes print|embed=yes}}, which expands to "From a printworthy title: ...", which is wrong. In this case, {{R with possibilities}} and in turn {{Redirect template}} is not embedded in {{This is a redirect}}, and therefore the call should be {{R yes print|embed=}}, which will expand to "This is a redirect from...". The {{Redirect template}}'s name parameter can be used to distinguish whether we (i.e. {{Redirect template}}) are being embedded in {{This is a redirect}} and set the {{R yes print}}'s embed parameter accordingly. — Petr Matas 08:22, 3 May 2014 (UTC)
 Done – Paine Ellsworth CLIMAX! 14:47, 3 May 2014 (UTC)

Extract the core into a subtemplate

Please replace all code of this template from start up to but excluding Printworthiness with {{/core}} and pass all template parameters to it. This will allow us to get rid of the template loop. Petr Matas 18:27, 31 May 2014 (UTC)

We need to pass the parameters using something like this: 

{{/core |{{#if:{{{info|}}}|info}}={{{info|}}} }}

It will be nice if we have a template, which will allow to shorten this to 

{{/core {{pass-param|info}} }}

Petr Matas 18:53, 31 May 2014 (UTC)

I would normally ask you to make your requested changes to the template's sandbox first; see WP:TESTCASES - but Paine Ellsworth (talk · contribs) seems to be doing something there. Accordingly, I think that the proper response is Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. --Redrose64 (talk) 19:11, 31 May 2014 (UTC)

@Paine Ellsworth: I have made the requested changes in the sandbox. After the changes to {{R unprintworthy}} are applied, please apply this edit, where the core of this template is extracted into the subtemplate and {{R yes print}} and {{R no print}} are no longer used. Petr Matas 21:16, 31 May 2014 (UTC)

I think this was already solved, Petr, by simply by merging the code you improved at R yes print and R no print into R printworthy and R unprintworthy, respectively. That action alone will remove the template loop and will turn the first two and their docs (4 pages) into redirects without the need for a /core page. Don't get me wrong, because I have no doubt that your suggested edits to these associated templates will work, I just wonder if more than what was planned is necessary? – Paine Ellsworth CLIMAX! 22:44, 31 May 2014 (UTC)
I also think that no changes should be made until the TfD is closed. – Paine Ellsworth CLIMAX! 22:50, 31 May 2014 (UTC)
I've done a double take, and yours is a superior solution, Petr. Wish I had thought of it! – Paine Ellsworth CLIMAX! 23:31, 31 May 2014 (UTC)
To editor Petr Matas: At this point, I support all you have done except for the code in the sandbox, with which you would like to replace this page. The bottom printworthiness I understand, and that's a good improvement. The top part where you call the /core and follow with several "if" functions is the part that does not seem to me to be necessary. Why does this template page need anything more than to replace the {{R yes print}} and {{R no print}} with {{R printworthy}} and {{R unprintworthy}}, respectively? – Paine Ellsworth CLIMAX! 08:49, 2 June 2014 (UTC)
The idea was to move the code from the main template to /core and transclude /core from the main template. It is to avoid code duplication, which could lead to content forks in the future. The "if" functions are necessary unless someone finds a better way of passing the parameters to /core correctly. Note that the /core contains code like {{{category|[[Category:{{{talk category}}}]]}}}, which will not work (I think) if we pass the parameter using only |category={{{category|}}}. See also my post from 18:53, 31 May 2014 (UTC) above. Petr Matas 09:31, 2 June 2014 (UTC)
Correct: when templates parameters are passed through, they're always present, even if blank. The syntax {{{category|[[Category:{{{talk category}}}]]}}} means "if the |category= parameter is entirely absent, use [[Category:{{{talk category}}}]] but when it is present, use it, even if it is blank". The syntax required for blank and absent to be equivalent is {{#if:{{{category|}}}|{{{category}}}|[[Category:{{{talk category}}}]]}} --Redrose64 (talk) 10:29, 2 June 2014 (UTC)
You probably meant "when parameters are passed through," but thanks for confirming my assumption. Petr Matas 11:18, 2 June 2014 (UTC)
To editor Redrose64: Within this template are several instances of the [[w:... usage. I remember a previous discussion with you about these. Should they be removed? – Paine Ellsworth CLIMAX! 08:49, 2 June 2014 (UTC)
These are the lines: 
-->{{#if:{{{all category|}}}|[[w:Category:{{{all category}}}|{{{name}}}]]|<!--
    -->{{#if:{{{main category|}}}|[[w:Category:{{{main category}}}|{{{name}}}]]|<!--
        -->{{#if:{{{help category|}}}|[[w:Category:{{{help category}}}|{{{name}}}]]|<!--
            -->{{#if:{{{portal category|}}}|[[w:Category:{{{portal category}}}|{{{name}}}]]|<!--
                -->{{#if:{{{talk category|}}}|[[w:Category:{{{talk category}}}|{{{name}}}]]|<!--
                    -->{{#if:{{{template category|}}}|[[w:Category:{{{template category}}}|{{{name}}}]]|<!--
                        -->{{#if:{{{wikipedia category|}}}|[[w:Category:{{{wikipedia category}}}|{{{name}}}]]|<!--
                            -->{{#if:{{{category category|}}}|[[w:Category:{{{category category}}}|{{{name}}}]]|<!--                                -->{{#if:{{{user category|}}}|[[w:Category:{{{user category}}}|{{{name}}}]]|<!--
Here, the w: shouldn't be removed entirely, because that would change a category link into an actual categorisation of the page. The colon needs to be retained; the presence of the w as well means that the category links are treated as interwiki links instead of internal links. I do recall a discussion on the matter, but forget where, or what the details were. IIRC it was something to do with the "what links here" feature: interwiki links don't get listed. --Redrose64 (talk) 10:29, 2 June 2014 (UTC)
I think that treating those as interwiki links is undesirable, so I propose changing "w:" to just ":". Petr Matas 11:26, 2 June 2014 (UTC)
I removed the "w"s from the core template. – Paine Ellsworth CLIMAX! 13:48, 2 June 2014 (UTC)
On a related matter: hiding all those linebreaks inside <!-- --> is largely unnecessary. Linebreaks are whitespace, and whitespace inside parser functions is stripped. --Redrose64 (talk) 10:29, 2 June 2014 (UTC)
I took out the comment tags from inside the "if" functions with this edit, and then had to restore them. Either I did something wrong or the tags are necessary, because their removal appeared to introduce an undesirable "leading space", which when tested on a redirect the individual rcat looked something like this:
* This is a redirect from a title that would be helpful in a printed version of Wikipedia.  For more information follow the category link.
...and when the {{This is a redirect}} template was tried, it looked like:
From a printworthy page title: This is a redirect from a title that would be helpful in a printed version of Wikipedia.  For more information follow the category link.
So removal of the comment tags may not be something we want to do. Unless I did something wrong, of course. – Paine Ellsworth CLIMAX! 13:37, 2 June 2014 (UTC)
Removal of the first pair left a linebreak in place, but that's easily fixed, like this. --Redrose64 (talk) 14:18, 2 June 2014 (UTC)
You're bad! – Paine Ellsworth CLIMAX! 14:31, 2 June 2014 (UTC)

To editor Petr Matas: Petr, I tested your change to the core template and it introduced a "leading space" in the same manner as my first edit to rm the comment tags as shown above. I reverted it temporarily because of its usage in {{R printworthy}}. Then I rm'd the core from that template, so now you can experiment and test without affecting anything that's "live". – Paine Ellsworth CLIMAX! 21:56, 2 June 2014 (UTC)

To editor Paine Ellsworth: Thank you for your thorough testing. Apparently, I forgot to repeat some tests after introducing the last "improvement", which I am undoing here. It seems that links don't like line breaks at all. Petr Matas 03:03, 3 June 2014 (UTC)
Pleasure! – Paine 19:27, 3 June 2014 (UTC)

To editors Petr Matas and Redrose64: Since the discussion about {{R no print}} is just about whether or not to delete it or to redirect it to {{R unprintworthy}}, I went ahead and implemented this edit. Whatever the community decides will no longer affect this template. – Paine Ellsworth CLIMAX! 07:29, 5 June 2014 (UTC)

Template loop error

The template Template:R from title without diacritics gives an error message on redirect pages using it, such as Stanislaw Lem: 

Template loop detected: Template:Redirect template

Since I don't understand where the actual bug is, I am posting this to both Template talk:R to diacritics and Template talk:Redirect template. --Ørjan (talk) 10:39, 5 June 2014 (UTC)

It is because the changes to {{R unprintworthy}} have not been applied yet. Redrose64, Paine Ellsworth, please apply them ASAP. Petr Matas 11:10, 5 June 2014 (UTC)
 Fixed – Paine Ellsworth CLIMAX! 11:50, 5 June 2014 (UTC)

Module edit review request

Hello Jack, I'd like this template to be able to retrieve the embed parameter from the rcat template which transcluded it. Can you review my edit, please? I would like to use the parameter in retval = ..., embed and args.name and getPrettyName(args) or '', ... Petr Matas 05:46, 26 October 2014 (UTC)

COMMENT: I wouldn't be surprised if Magic Jack already has these redirect categorization templates on his long list of template conversion needs. Not sure where rcats stand in the priority levels, but I've been at work to make rcat code as easily convertible as possible, and there are just maybe twenty or so more that need major work. – Paine Ellsworth CLIMAX! 15:14, 26 October 2014 (UTC)
Jack converted the template a few days ago, that's why I could take the advantage of Lua and why I'm asking him for a review. Petr Matas 16:27, 26 October 2014 (UTC)
It doesn't work at all, unfortunately. Grandparent frames are always inaccessible (i.e., frame:getParent():getParent() will always be nil). Jackmcbarn (talk) 20:31, 26 October 2014 (UTC)
What a pity! Thanks for your time. Petr Matas 03:06, 27 October 2014 (UTC)

Avoid code repetition

Hello, what do you think about this edit? It uses the embed parameter in a way that avoids code repetition. It also passes the embed parameter to the {{Redirect template}}, which does not use it yet, but when it does, we will be able to pass the name parameter to the {{Redirect template}} unconditionally. Do you think that this improvement should be applied to other rcat templates as well? Petr Matas 23:33, 20 October 2014 (UTC)

Hello Paine, have you seen this? :) Petr Matas 18:35, 24 October 2014 (UTC)

I don't know if this should be applied. There is a similar idea that another editor placed in the sandbox of the {{R from other capitalisation}} rcat, with a discussion about it on that talk page. I think we want to consider very carefully before we implement something like this. The idea to use two instances of this template in each rcat with only one instance of "embed" in the code seems to make it easier to edit and improve for those of us who are not as code savvy as others. Also, I'm not sure exactly why the designers made it so that the top RT in each rcat was for the This is a redirect template application, while the bottom instance applied to rcats when they are used individually to tag redirects. Why do you think they did that? – Paine  21:25, 24 October 2014 (UTC)
You're very welcome, of course, Petr, and my question wasn't rhetorical. I really would like to get your take on why the designers expressly stated, "This template should be used twice in a redirect template: {{#ifeq:{{{embed}}}|yes|{{Redirect template}}|{{Redirect template}}}} The first instance of this template will appear when used with the {{This is a redirect}} template, whereas the second instance will appear when the redirect template is used individually:..."? But why do that when it is obvious both by your code edit and that of SMcCandlish that it is easy enough to use just one instance of this template to do the same job? – Paine  09:47, 25 October 2014 (UTC)
I am sorry for the delay, Paine, I needed some more time to think about it. I think that they stated to use the {{Redirect template}} twice, because they expected the two versions of a redirect template to differ significantly from each other, which does not seem to be the case anymore, and that's why SMcCandlish had exactly the same idea as I did. Please have a look at this diff, which shows the resulting overall change after {{Redirect template}} would have been improved (but don't apply it yet). I think that the change is not so complicated anymore:
  • Two prologue lines have been changed to different two prologue lines.
  • Two pieces of conditional code, which handles the differences between the two versions, have been added. I think these are better readable now and they would be used in other templates in the same way. I even think that {{Redirect template}} could be refined to get rid of these conditional pieces altogether and to specify the category only once instead of two or three times.
  • The second {{Redirect template}} instance has been removed.
In my opinion, the net effect would be a simplification, even for non-geeks, thanks to not repeating the code. Petr Matas 18:24, 25 October 2014 (UTC)
Oh, and there's one more reason for the instruction to invoke {{Redirect template}} twice: {{Redirect template}} currently infers from presence or absence of the name parameter, which version it has been used from. That's why my proposal originally contained that strange |{{#ifeq:{{{embed}}}|yes|name}}=From incorrect name hack. But we can get rid of that easily, as I explained above. Petr Matas 19:06, 25 October 2014 (UTC)
I remain in favor of consolidating the code to avoid redundancy.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:49, 25 October 2014 (UTC)
There are three areas where I have concern. Petr, you say that you think the reason the designers wanted this template to be used twice in each rcat was because they thought the upper and lower versions would differ significantly from each other, and that was probably no small part of it. Then you go on to say that it "does not seem to be the case anymore". Well it does happen to be the case, and that has actually increased over time. Even the template you pointed to above needed four "embeds" instead of just one. The template SMcCandlish wants to alter needs at least three embeds instead of one, and there are some rcats that would need more than three or four embeds. Also, there are a lot of rcats that would need to be altered.
Of my three concerns, the first two come from my experience with these templates... 1) readability and 2) ease of editing. Their present format derives from my having so much trouble at first just trying to make out what was what, and then to get them to do what they were supposed to do in general cases and in specific usages. I wanted to make them so that future editors won't have the problems I had. My third concern, by coincidence with your request below, has to do with Lua conversion. We will want to keep the code of these templates as simple as possible, so as to provide the presently overworked code magicians who make the conversions to Lua with code that will convert readily with few possibilities for error. The changes you and SMcCandlish would like to make seem to me to go in directions opposite to meeting the three goals of readability, ease of editing and ease of Lua conversion. That is my take; I could be wrong. – Paine Ellsworth CLIMAX! 15:05, 26 October 2014 (UTC)
From a programmer's point of view, the differences are minor and code repetition is one of the uglies things to encounter. I still think that our modifications would be useful even to non-programmers, but maybe they need more tuning before being deployed. However, because it is you, who cares for the rcat templates consistently, there would be no benefit from implementing an "improvement", which hampers your work, whose systematicity I appreciate so much.
One more question: I thought that only the metatemplates like {{Redirect template}} should be converted to Lua, not the individual rcat templates? Petr Matas 04:32, 27 October 2014 (UTC)
That is certainly true now. As you know, the reason Lua has been implemented is to speed up the more complicated templates that slowed everything down. But why should it stop there? Eventually, Lua will probably be used across the board, and wikimarkup will grow cobwebs. – Paine  13:33, 27 October 2014 (UTC)
Because wikimarkup is simpler for simple templates. Lua module is a program, so it has more complicated syntax (declarations etc.). Petr Matas 07:53, 31 October 2014 (UTC)
Thank you, Petr, for your compliment! I'm not sure, of course, but I wonder if you could do what you wanted if there were no /core. It's not needed anymore, since there is no possibility of template loop. Another contributor asked that the repetitious printworthiness be removed from the {{Redr}}, and the best way to do that was to go back to straight category calls rather than template calls. Maybe it would simplify matters if the main template were to be combined again with the contents of the core? That might make it easier to get it to do what you want it to do. Just a thought. – Paine  13:33, 27 October 2014 (UTC)
You are right that the /core is not needed anymore thanks to the removal of the {{R (un)printworthy}} calls from this template, but the /core's presence does not hamper anything. Please look at how the rcat template code could look like in the future. If you like it, I will implement the changes to make it work, while doing my best not to break the legacy templates. Petr Matas 07:53, 31 October 2014 (UTC)
I suppose I don't see why it's necessary. Rcats are generally very short and fast already. I can see why it would be desirable to condense larger templates, both to speed them up and to make them easily accessible to Lua conversion; however, short and concise templates like rcats are already fast and easily accessible to Lua, so my opinion must continue to be... IIABDFI. – Paine  17:32, 31 October 2014 (UTC)
This has nothing to do with performance. The sole reason for the proposed changes is to improve manageability by avoiding repeated code. Note that the existing templates won't need to be updated immediately (according to IIABDFI), but there will be an option to express a given template more concisely when a need for its modification arises. However, if you don't like it, I will leave it alone. Petr Matas 20:07, 1 November 2014 (UTC)
It seems that it will not be necessary to pass the embed parameter, because the Lua module should be able to retrieve it from the calling template. That will further simplify our templates. Petr Matas 05:26, 26 October 2014 (UTC)
This doesn't work, see #Module edit review request. Petr Matas 03:10, 27 October 2014 (UTC)

Unnecessary "fixes"

To editor Jdaloner: Please explain how bypassing a redirect in violation of the Wikipedia guideline that is in the code of a page is more than just the padding of your edit count? There is no deception here, neither real nor intended. This is correct usage of a shortcut redirect in the code of a documentation page. There are still many things on this project that actually do need fixing, so why don't you go fix some of those? – Paine Ellsworth CLIMAX! 11:29, 25 December 2014 (UTC)

I assume you're referring to the recent edit I made to Template:Redirect template/doc. I do not accept the manner in which you describe/characterize that particular edit, but that's beside the point. (I'm also not familiar with "padding of your edit count". I have no idea what mine is, and I'm not even sure where that information is, although I suppose it probably wouldn't be that hard to find. I don't know what advantage would be gained by padding it, though. Are there prizes or something?) Anyway, the /doc page uses the "R from initialism" template as an example. The following is what appears at the end of the main part of the "Usage" section, just before its first subsection:


The first instance of this template will appear when used with the {{This is a redirect}} template, whereas the second instance will appear when the redirect template is used individually:

  • {{This is a redirect|from initialism}}
  • {{R from initialism}}


All the code in the excerpt above is visible (nothing is actually processed), and the reader can see the two instances of "[R] from initialism" (one within {{This is a redirect}} and one by itself).
Skipping down a bit to the "Example" subsection (still within the "Usage" section), both forms of the message generated by this template are shown. The reader sees the following (without the two error messages, which are only generated on this page):
Used individually as in {{tl|R from initialism}} this produces:
{{R from initialism}}


Used with the {{tl|This is a redirect}} template this produces:

{{This is a redirect|rinit|nocat=true}}
In this case, the code cannot be seen (without clicking "edit"), since these are actual transclusions. But the code actually used is not what the reader would expect. The documentation is presenting the reader with a simple comparison: Here are two instances of the same thing (the "R from initialism" template), with only one difference between them (being implemented individually or in {{This is a redirect}}), so that you can see the practical difference (the different forms of the message produced) between these two methods. Based on everything presented to the reader thus far, the obvious assumption is that the first transclusion was generated by {{R from initialism}} (which it was) and that the second transclusion was generated by {{This is a redirect|from initialism}} (which it was not). The second transclusion was generated by {{This is a redirect|rinit}}.
So there are actually two issues here:
  • There is no longer only one difference between the "two instances of the same thing". The first instance is by itself and calls "R from initialism" directly, while the second instance is within {{This is a redirect}} and calls "R from initialism" through the "rinit" redirect. I am fully aware that having "rinit" instead of "from initialism" in {{This is a redirect}} makes no practical difference in the message generated, but that's not the point. If the page is going to show two different implementations of the same thing, then it should do exactly that: show two different implementations of precisely the same thing. If the reader goes to look at the code actually used to generate those messages, it's likely to lead to confusion, since {{R from initialism}} and {{This is a redirect|rinit}} don't have even a single element in common.
  • {{This is a redirect|from initialism}} is displayed earlier on, but then {{This is a redirect|rinit}} ends up being used instead. If the page is going to provide visible/unprocessed code (before showing the result of processing the code), then that visible/unprocessed code is the very code that should be used.
Seeing as how {{This is a redirect|from initialism}} was already displayed earlier on, and seeing as how it actually matches {{R from initialism}}, it seems to me that the simplest fix that addresses both of these issues is to just replace "rinit" with "from initialism". Doing so would bring the page more in line with what a reader would expect, while making no practical change to the page, its functionality, or how the messages are displayed. In other words, this edit can accomplish some good, while having no downside at all. Its ultimate outcome can only be one of two things: (#1) it never makes any difference to anyone, good or bad, or (#2) it actually helps someone.
Even though I am well aware that "rinit" redirects to "R from initialism", I myself was thrown off for a moment when I looked at the code. Once I figured out what was going on, I went ahead and made the edit because it would have helped me, and I figured it might help the next "me" who comes along. (And there was no possibility of it harming anything.) I made the edit without much of an explanation the first time, and was reverted. I then made the edit again and attempted to provide a clear explanation of the reason behind it. Nevertheless, I was reverted again. Is this edit/fix "necessary"? Of course not. No single edit is absolutely necessary. No single edit ever has to be made. But I maintain that it very likely may help someone, and there is no possibility of it harming anything. That's why I made the edit, and why I continue to believe the edit should be implemented. Jdaloner (talk) 15:34, 25 December 2014 (UTC)
There is no longer only one difference between the "two instances of the same thing". The first instance is by itself and calls "R from initialism" directly, while the second instance is within {{This is a redirect}} and calls "R from initialism" through the "rinit" redirect. I am fully aware that having "rinit" instead of "from initialism" in {{This is a redirect}} makes no practical difference in the message generated, but that's not the point.
And here comes the point:
If the page is going to show two different implementations of the same thing, then it should do exactly that: show two different implementations of precisely the same thing.
Interesting point – your words are "If the page is going to show..." – and the page actually does "show" two different implementations of the same thing – and it does exactly, precisely that.
Every page has two different sets of what it "shows". One is visible without clicking edit, and the other is visible after clicking "edit". The latter does not show two different implementation methods of the same page, it shows two different implementation methods of two different pages, one of which happens to redirect to the other. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
This makes me curious as to why you looked at the edit screen in the first place?
In this instance, the code that is actually being used and the code the reader believes is being used (but actually is not being used) happen to generate/produce the same thing (at the present time). However, I can't even begin to count the number of times I have encountered this sort of thing where there are practical differences between the two versions. I'm not an expert on any of this coding stuff; I learn it from the instructional pages on the site. And sometime a long while back, I was trying to figure out how some function or another worked (tables, I think) and was trying to make sense of a help page. What the page was presenting to me didn't seem to make sense, and I eventually realized that throughout the page, the visible code being presented and the code actually being used to generate the examples had numerous differences. I then found that if I replaced the code being used to generate the table with the code I was actually seeing on the page (and clicked "show preview"), it generated something different. Lo and behold, things started making more sense to me at that point. Ever since that experience, when I find myself on an instructional page that I am attempting to learn from, I begin by checking for these sorts of issues--and more often than not, I find them. I have found this to be true for pages in the "Help" namespace, the "Wikipedia" namespace, and yes, "/doc" subpages in the "Template" namespace. There's no point in providing documentation to a reader that in essence claims to be showing an unprocessed version of "a" followed by a processed version of "a", then actually follows with a processed version of "b" instead. Not only is there no point in doing this, it is specifically deceptive, even if that is not the intent. The writer has claimed to be showing what "a" produces, but is actually showing what "b" produces. Even if, at the time the writer does this, they produce the exact same thing, there's no guarantee it will remain that way. Changes to the MediaWiki software, changes in web browsers over time, etc., may eventually reveal or cause differences between what "a" produces and what "b" produces even though there were no differences at the time it was written. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
Do you go looking for instances of "wp" so you can uselessly change them to "WP"? I don't have a problem with such edits, because I sometimes change "#redirect ..." to "#REDIRECT ..." or at least to "#Redirect ..." on redirect pages; however, I never do that unless I am also making a substantial edit, such as adding or subtracting categories, to the page as well. Such edits as capitalizing the "r" in "redirect" and the "wp" in "wp:(project page)" are edits that are not substantial enough all by themselves to warrant an edit.
Do I go looking for these? No. In fact, it would seem that you and I have the exact same attitude towards this right here. If I'm editing the page for another reason, and I notice things along these lines ("wp" to "WP", "#redirect" to "#REDIRECT", etc.), then I make those changes, just like you. And that's what happened here, as well. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
If the reader goes to look at the code actually used to generate those messages, it's likely to lead to confusion, since {{R from initialism}} and {{This is a redirect|rinit}} don't have even a single element in common.
Of course they have elements in common. "Rinit" is just an abbreviation of "R from initialism". That should not be much of a stretch for anybody at all.
I agree that should not be much of a stretch. But why should the reader need to stretch at all? Shouldn't the goal be to make it easier to follow, rather than harder? Jdaloner (talk) 11:40, 26 December 2014 (UTC)
I myself was thrown off for a moment when I looked at the code.
I suppose the question arises about how long a "moment" is? Was it long enough to inspire a little thought? And a moment later, when it dawned on you that "rinit" was an abbreviation for the full name of the rcat, you felt how, exactly? No longer confused? As if you had solved a puzzle?
Yes, precisely. And I did what I believe to be the natural, appropriate, and correct thing in that case. I made it easier for the next person to follow. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
So why then is a little "confusion" necessarily a bad thing?
It's not about whether "confusion" is necessarily a bad thing. In this case, it could either be "a little confusing" or "not confusing". I tend to think the latter is the better option. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
How many people actually know for certain what NASA stands for? UNICEF? SEATO? If an editor were even moreso confused than you, then how would s/he find the answer? If it's important enough to her/him, then maybe a little digging would ensue and, while searching for the answer, s/he just might uncover other parts of the redirect categorization process besides shortcuts that are also useful to know.
If it's important enough to her/him, then maybe this happens. And if not, then they probably give up. I think we're supposed to aim for inclusion rather than exclusion, this being a wiki and all. I don't believe the goal with anything here is to intentionally keep instructional pages hard enough to follow that some readers will need to go to additional instruction pages just to make sense of what they're reading on the first page. I do realize that there's often no way around that, but in this case, there is a simple, clear alternative. (Using "from initialism" instead of "rinit".) Jdaloner (talk) 11:40, 26 December 2014 (UTC)
Edits like you made here and at {{This is a redirect/Comparison}} are completely insubstantial and provide no merit for readers and little to no help in the long run for editors, either.
Of course you're entitled to your opinion. I have yet to find any policy or guideline, however, that says an edit actually needs to be "substantial" or else it should be reverted. (Quite a few pages, however, discouraging reverts unless the edit in question caused actual harm and there's really no good way around it.) The edit at the other page absolutely provided merit for readers, since the page no longer used a term that it did not define. You yourself obviously recognized this, because when you reverted my change, you also added language explaining the term. And that's a perfectly fine alternative to the edit I performed. I addressed the issue in one manner, you addressed it in another, and that's fine. The issue got resolved. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
I used to edit like you do until I realized that I was not helping the project and might have even been hurting it a little. Shortcut redirects have a purpose and should never be altered.
So...on the instance in question at Template:Redirect template/doc, what exactly is the purpose of using "rinit" instead of "from initialism"? The entire issue depends on the answer to that question. I can't possibly fathom why it is better in that one specific instance to use "rinit" instead of "from initialism". That's why making the edit I did was an easy call. It provided benefit (even if only a little), and I weighed that against zero downside (again, in that specific instance). So if there was a specific reason why using "rinit" was better, despite being not what was "advertised" in the visible language on the page, please let me know. Jdaloner (talk) 11:40, 26 December 2014 (UTC)
When I needed to find out where a shortcut led, I either clicked on it or put tl| in front of the template name and then clicked on it. That's easy enough, and it would take me to everything I needed to know about the shortcut's target. Have a safe and happy holiday season with a prosperous New Year to follow! – Paine Ellsworth CLIMAX! 17:56, 25 December 2014 (UTC)
See comments within your response above. (I have split some of your sections up, so that I can comment piece by piece, in the hope that it will aid readability.) Jdaloner (talk) 11:40, 26 December 2014 (UTC)
I usually don't like it when posts are chopped up like that; usually as shown I prefer to quote certain passages and then respond to those specific issues. In this case it's not a big deal, so onward and upward (hopefully). At the very least it seems we can agree to disagree. There is one question you asked that should be addressed:
...what exactly is the purpose of using "rinit" instead of "from initialism"?
Of course, the obvious initial purpose was the same as for any shortcut usage – to save time while editing. Shortcuts have, I believe, a more subtle purpose after they've been used. I suppose the best way to put it would be to call it a learning experience. This is what you experienced when you first saw "rinit". Other shortcuts that are less intuitive may provide even better learning experiences, as I previously described. So your argument that...
But why should the reader need to stretch at all? Shouldn't the goal be to make it easier to follow, rather than harder? [...] And I did what I believe to be the natural, appropriate, and correct thing in that case. I made it easier for the next person to follow.
Two things to consider here are 1) this is code we're discussing, and not what the reader sees on the subject page, and 2) think about the fairly recent change to Lua usage in templates. It is better for the project, of course; however, if an editor is adept at wikimarkup and has not learned Lua, that usage certainly does not make editing any easier. I think that Lua is a perfect example of how we should see this edit-screen content dispute. Yes, there are things we can do to make it easier for new editors, but there should also be a balance between that and leaving things behind (like shortcuts) that will allow more and better learning experiences for editors. I sincerely believe that is what happens simply because of my own learning experiences with this unique encyclopedia. Shortcuts have a tendency to make editors dig deeper to learn what's going on, and that can lead to many new places those editors might never have seen had they not been subtly urged to question "why?"
So what we have here is a rather insubstantial gray area, I suppose. Some editors like myself would look at your edits and scratch their heads in wonder as to why you would feel it necessary to make such changes. Other editors like yourself (especially those who for some reason possess a loathing for shortcuts – I've come across a few of those) would also see your edits as improvements. Both types of editors would probably look at this keen discussion and LOL at the both of us for seemingly taking this issue so seriously. In any case, if I haven't convinced you that there is some good in leaving relatively small bits of items to question behind, sort of like bits of mental "food" on our trails as we move through this awesome encyclopedia and its improvement needs, then frankly I'm not sure how to proceed. – Paine Ellsworth CLIMAX! 13:31, 26 December 2014 (UTC)
Well you most certainly have not convinced me that there is any good or merit in intentionally trying to make editors work harder, nor will you. For every editor that is "inspired" by this sort of thing to work harder and have a "learning experience", I strongly suspect two or three are lost. Our purpose here is supposed to be building an encyclopedia, not building editors. Let people push and build themselves however far they want to--but leave it up to them. Don't intentionally put them in a tougher spot than they otherwise need to be. If a page can be easier for them, with no downside whatsoever, then it should be made easier for them. I note that you still have not cited why it is better for the encyclopedia to have used "rinit" instead of "from initialism", which I take as a concession from you that you realize it is not actually better for the encyclopedia. You just think it's better if the editors have to figure out what's going on with the instructions themselves. (The project should count itself lucky that they have bothered to come read the instructions in the first place.) Keep in mind, the issue here is not that a shortcut was used--it's that the visible code (code "a") tells readers and editors that what they see getting produced is being produced by code "a", when it is actually being produced by code "b". You want to use a shortcut? Fine! But use it both places. Don't hide the fact that you're doing it. I changed "rinit" to "from initialism", but there are probably other ways of addressing the issue, just like you did on the other page where you reverted my harmless edits. Yet here on this page, you see no problem--even after it's been noticed and pointed out--with providing instructions that are inherently misleading (claiming to show what code "a" produces, when actually showing what code "b" produces). It seems pretty clear that, ultimately, you would prefer fewer, better editors, as opposed to being more inclusive, which seems to fly directly in the face of what Wikipedia is supposed to be all about. (Lua is an entirely different matter, as it provides actual benefits to the functioning of the encyclopedia.) You call it "leaving ... bits of mental "food"" on a trail; I think "placing trip wires" on a trail would be a more accurate comparison--after all, those trip wires will teach them to look where they're going, and push them to be better trail-walkers. (Or, you know, they may just turn around and go back the other way.) You seem fine making it harder for editors to make sense of the instructions, thus increasing the odds of losing them entirely, and you obviously seem fine with reverting edits that caused no harm at all (such as mine), even when your only reason for doing so is to persist in making it harder for editors to make sense of the instructions--now increasing the odds of losing the editors who aren't going to spend that long trying to make sense of things and losing the editors like me who are trying to make it easier for them. I agree that we can "agree to disagree" on this. And, on this, I couldn't disagree with you more. Jdaloner (talk) 08:06, 28 December 2014 (UTC)
Well, then, it seems there is a choice to make! You feel that what I did by reverting your useless (ahem – harmless) edits makes worse editors or no editors at all, and I feel that by leaving the shortcuts in the code we make better editors and thereby we improve the encyclopedia two ways – both by our other edits and by the "learning" edits we leave behind, such as "rinit" instead of the long name. You fail to cede that when you discovered the "rinit" in the code, it showed that you are a better editor, an editor who has the capacity to put 2 and 2 together, an editor with potential. Okay, failing that is fine if you wish it to be. And if you feel so strongly about it, then there is always wp:dispute resolution for you to use. Please keep in mind that I defend the "status quo", and this template documentation is expected to remain at status quo until the dispute is settled. By the way, I see no reason to bypass the subtle learning experience by the use of "rinit" on the readable page with an explanation as I did at {{This is a redirect/Comparison}}. On that page the shortcut use on the readable page was already there and just needed an explanation. On this page it needs no explanation, because it's an easy find. You found it easily enough, and you learned something. It appears that all you have left to you is your inability to comprehend that you found and learned something, your groundless defense of the useless changes you made, and dispute resolution. Happy and Prosperous New Year to you and yours! – Paine Ellsworth CLIMAX! 13:27, 28 December 2014 (UTC)

Regarding bullets

Currently this meta template (at least under the Vector skin) puts a round blue bullet in to introduce the template. There's a problem here there because many of the actual templates using this meta template also use lists that have round blue bullets (to do things like remind redirect taggers about the proper way to use the templates). While these lists are indented, visually it's cluttered and confusing when multiple redirect templates are used on a single page. This is super ugly and hard to parse:

An example showing how things currently look
  • From a fictional character: This is a redirect from a fictional character to a related fictional work or list of characters. The destination may be an article about a related fictional work that mentions this character, a standalone list of characters, or a subsection of an article or list.
  • With possibilities: This is a redirect from a title that potentially could be expanded into a new article or other type of associated page such as a new template. The topic described by this title may be more detailed than is currently provided on the target page or in a section of that page.
    • When the target page becomes too large, or for any reason a new page would be an improvement, this redirect may be replaced with an article, template or other project page that is carved out of the target page. See also {{R to section}} and use together with this rcat when appropriate.
    • If the topic of the redirect is not susceptible to expansion, then use other rcats such as {{R to section}} or {{R to list entry}} when appropriate.
    • Since a new page may be created, links to this redirect should not be replaced with a direct link to the target page. To make redirects to this page, use {{R avoided double redirect}}.
    • {{R printworthy}} should be used together with this template when applied to a redirect in mainspace.
    • When used on a template redirect, it will automatically populate Category:Template redirects with possibilities.

I think the easiest remedy may be to replace the single outer bullet generated by Module:Redirect template with some other symbol, something like perhaps ► or some other blue geometric shape different from the same size blue circle Wikipedia normally uses for lists under Vector (this blue bullet appears to be set by CSS with via the list-style-image attribute).

Anyway, some different shape would go a long way to making redirects with many redirect templates easier to read and quicker to visually parse. Plus the current usage suggests each redirect template is a list of a single item which is semantically weird. Of course, any new scheme would have a work with {{Redirect category shell}} too (a template which I personally dislike and feel adds an unnecessary level of confusion but I digress). Jason Quinn (talk) 20:18, 4 April 2018 (UTC)

Agree that it is confusing. That looks nice enough of a character Galobtter (pingó mió) 14:24, 5 April 2018 (UTC)

Template-protected edit request on 21 December 2018

Please sync changes from the sandbox: mostly cleanup/simplification of the code.

I've explained the edits in the edit summaries (starting from this edit); some of the supporting statements are here:

  • This shows that |embed= parameter is not used anywhere with value other than yes.
  • This shows that |category= parameter is totally unused.
  • {{redirect template/core}} has 0 transclusions. And there's no reason why p.core function would be invoked from anywhere else, though a regex search results in a timeout.

The way in which the namespaceCategories table is used hardly looks efficient, though I've not tried to change it; I'll look into it later if time permits. SD0001 (talk) 08:05, 21 December 2018 (UTC)

 Done — Martin (MSGJ · talk) 09:59, 2 January 2019 (UTC)
Comment: I have undone this edit since it broke the formatting of Template:Redirect template in certain circumstances when a page contains multiple transclusions of this template. I have left a message on the edit proposer’s talk page regarding my undoing of this edit. Steel1943 (talk) 21:17, 2 January 2019 (UTC)

Discussion

Moved from User talk:SD0001
 – 10:22, 3 January 2019 (UTC)

I’m hoping I pinged you properly in my undos, but if I did not, I’m letting you know that I have undone your recent changes to Module:Redirect template since a change somewhere in the aforementioned module broke the way Template:Redirect template appears when transcluded multiple times on pages in certain circumstances. Please see Template:Redirect template/testcases#Test The Honeycombs (album) for further information. Steel1943 (talk) 21:13, 2 January 2019 (UTC)

@Steel1943: Thanks for creating those testcases. Are you sure you didn't accidentally change the substed text? Despite multiple attempts, I was unable to replicate the borked view at Template:Redirect_template/testcases#Test_1. Indeed, that is simply impossible because both {{R with history}} and {{R from album}} are wrapped in different <ul><li> ... </li></ul> containers, so it's not possible that indentation of one would be affected due to the other.
See Template:Redirect_template/testcases#Redirect_template/sandbox. The "from album" is indented correctly as I said, though there's still a problem that there are 2 bullets on the sub-bullet of R with history. This can be fixed by replacing ** → * in the template code. This, I think, should be done on all rcat templates that use sub-bullets, because it makes semantic sense, as well as facilitates the improvements that I made in the module - which is to replace * with <ul class="rcat rcat-name"><li>...</li></ul>, which makes the markup structured, allowing for bots and scripts to identify the rcat templates from the HTML markup of the page. This would be used in improving the functionality within Twinkle to add and remove rcat templates. (I have already implemented this for articles). SD0001 (talk) 04:24, 3 January 2019 (UTC)
  • @SD0001: In all honesty, I have no guarantee that the syntax I put on the test cases are the same as what was actually there. Since substituting the template returns the module only displaying "This is a redirect.", I had to manipulate what I saw the best I could. However, I did also notice the oddity with the double ** bullets: If you believe that you have found the fix with the indention of subsequent transclusions of {{Redirect template}} after versions with lines containing asterisks (**), and the only additional fix necessary is to change ** to * in the second line ... of all templates that have multiple lines ({{R with history}} is obviously only one of many such templates), sounds like a plan. (Pinging Paine Ellsworth in the event they by some chance have a list of Rcat templates with multiple lines that utilize double bullets in the second line, or if they can provide any further input.) Steel1943 (talk) 04:33, 3 January 2019 (UTC)
  • Those were temporary "fixes" on my part until I could figure out what was going wrong. Now that you and Steel have helped me figure that out, let me also add that the changes you made had other adverse effects, which I noticed at {{R from drafts}}, an rcat-in-progress. While your changes were in effect, a colon and non-breaking space had to be added after the entry in the |name= parameter. That has also since been fixed; however, it begs the questions, "Are these changes really necessary?" and if they are, then "Why can't they be implemented in ways that don't break so many rcats in more ways than one?" Paine Ellsworth, ed.  put'r there  12:02, 3 January 2019 (UTC)
To editors Steel1943, SD0001 and MSGJ: forgot to ping ya'll. Paine Ellsworth, ed.  put'r there  12:17, 3 January 2019 (UTC)
@Paine Ellsworth: thanks for pointing that out. Fixed in the sandbox. That was an oversight on my part. Sorry. Note that I made a series of edits to the module (which were implemented in the edit request). They are all mostly unrelated, and are simply code cleanup. Only one of those edits is required for the adding the said Twinkle feature. SD0001 (talk) 13:34, 3 January 2019 (UTC)
To editor SD0001: thank you very much for that, which is illustrated at Template:R from drafts/sandbox. Now, is there a way to massage the Lua code so as not to require cleanup of all the rcats that, like R from drafts, have double-bulleted notes? And forgive me for also wondering how extensive was your testing? Could there be other issues similar to the colon-space problem that might still need fixes? Again, please let me apologize, because I used to make a lot of improvements to {{Redirect template}} and had to stop when it was converted to Lua, since I am not well-versed in Lua. So I do respect your abilities, and I might be a little overly concerned that testing isn't exhaustive. Paine Ellsworth, ed.  put'r there  20:37, 3 January 2019 (UTC)
Yes! I just figured out a way, which wouldn't require edits to the templates. Regarding testing, I can't see any problems. But for something that has 4 million transclusions, I can hardly be sure. If at all there are any issues, I'm confident they'll be minor and fixable. I encourage you to learn Lua, it's an annoying language at first, but it can be used to develop powerful and efficient templates, and needless to say with code that's much more readable. SD0001 (talk) 07:19, 4 January 2019 (UTC)

Template-protected edit request on 4 January 2019

With the last few edits in the sandbox, I am certain that I have a bug-free version. Please incorporate. Changes have been extensively tested using the newly-created Template:Redirect template/testcases, armed with this wonderful script that I was recently informed about. SD0001 (talk) 19:53, 4 January 2019 (UTC)

 Done – and that does look like one awesome script! Paine Ellsworth, ed.  put'r there  01:50, 5 January 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Redirect_template/Archive_1&oldid=1233947420"