Template talk:Rfd2

RfC: Proposal to simplify the substituted output of Rfd2

{{subst:Rfd2}} requires substitution to freeze time-sensitive data, among other things. The resulting substituted code motivated a refactor. The sandbox result appears visually identical, equivalent in functionality, with possible minor improvements. Folks who !voted oppose were concerned about breaking current bots parsing daily logs, and that {{Rfd2/links}}, if unsubstituted, changes "would be reflected in the transclusions", which is undesirable.

There is a majority support (4 clear support votes and 3 clear opposes by my count), but to me, this does not suggest a clear consensus, or much of a rough consensus.

I'm closing this RfC as no clear consensus for a change right now. The benefits of the change would have been a much "more user-friendly output" that eased navigation through the discussions. Folks remained unconvinced for the change. There's general agreement that old XfD discussions should not be affected by template changes, and substitutions are the most reliable, consistent, and practical solution. The technical reasons against the change: given that RfD has run smoothly with current procedures/instructions, it is difficult to enforce {{subst:Rfd2/links}} at the end of closes, even with updated instructions. In the discussion, it is unclear if any bot is able/willing to handle substitution of archived discussions, and a more thorough discussion of instruction changes also did not happen.

If I may inject my own thoughts, the syntax simplification, which I believe is quite well-done, is absolutely worth the change if technical problems are worked out. It is worth it to hold onto this sandbox revision for later discussion. I recommend looking into WP:BOTREQ and asking if anyone is willing to do conditional time-sensitive substitutions for the subtemplate. I may also suggest making the unsubstituted {{Rfd2/links}} spit out a red error after 7 days that the template needs substitution. For now, RfD appears to be able to continue running without the change. (non-admin closure) — Andy W. (talk · ctb) 02:11, 17 June 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Per Oiyarbepsy's request to simplify the raw wikitext result of substituting rfd2, I worked to build {{rfd2 links}} and have implemented its use in {{rfd2/sandbox}}.

When substituted, this sandboxed version of {{rfd2}} leaves {{rfd2 links}} unsubstituted in place of what is usually a large and complex mess of wikitext markup for various links.

• It is proposed to make this the default configuration for {{rfd2}}.

There is a concern that whilst {{rfd2 links}} is transcluded in use, any changes to the template would be reflected in the transclusions, which at any time may be many. It is thus proposed that if this method is employed, {{rfd2 links}} should be template-protected from the start, and possibly automatically substituted by bot once it's archived. Anomie who operates AnomieBOT (which is currently utilised for auto substitutions) may like to advise? Fred Gandt (talk|contribs) 10:02, 11 May 2016 (UTC)

Examples

{{subst:rfd2|redirect=Foo|target=Bar|text=Reasons.}} currently produces:

====<span id="Foo">Foo</span>====
*<span id="Foo">{{no redirect|1 = Foo }}</span> → [[:Bar]] <span>&nbsp;<span class="plainlinks lx">([[Special:WhatLinksHere/Foo|links]] '''·''' [//en.wikipedia.org/w/index.php?title=Foo&action=history history] '''·''' [//tools.wmflabs.org/pageviews#start=2016-04-11&end=2016-05-10&project=en.wikipedia.org&pages=Foo stats])</span></span></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<small>[&nbsp;Closure:&nbsp;{{#ifeq:{{FULLPAGENAME}}|Wikipedia:Redirects for discussion|''(@subpage)''|<span class="plainlinks">''[{{fullurl:Foo|action=edit&summary={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as keep}}}} keep]/[{{fullurl:Foo|action=edit&summary={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as retarget}}}} retarget]/[{{fullurl:Foo|action=delete&wpReason={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as delete}}&wpMovetalk=1}} delete]''</span>}}&nbsp;]</small>&nbsp;

Reasons.

Whereas {{subst:rfd2/sandbox|redirect=Foo|target=Bar|text=Reasons.}} currently produces the proposed:

====Foo====
{{rfd links|Foo|Bar|2016-05-11}}

Reasons.

which is functiionally identical. Fred Gandt (talk|contribs) 10:02, 11 May 2016 (UTC)

Change log

Changes applied affecting the issues raised since the discussion started.

• I have moved {{rfd2 links}} to {{rfd2/links}} for continuity since it's a sub template, and created {{rfd links}} as a redirect to it for a user friendly raw appearence.
• I've implemented the use of {{#time:Y-m-d}} instead of {{CURRENTTIMESTAMP}} to store the submission date/time argument, again, for a more user friendly raw appearence. Fred Gandt · talk · contribs 23:38, 12 May 2016 (UTC)
• Added code to link the word "subpage" of the "(@subpage)" markup in the transclusion on Wikipedia:Redirects for discussion. This works by using the required and already present date argument in the unsubstituted call to {{rfd links}} and is only possible (without converting to Lua - possibly) with this proposed configuration. Fred Gandt · talk · contribs 11:40, 16 May 2016 (UTC)
  • Improved code for linking "subpage", which should now work whether links are substed or not. Fred Gandt · talk · contribs 20:04, 16 May 2016 (UTC)
• Minor: Some output examples in this discussion may not match the current reality of the template output since a request to perform this edit. Fred Gandt · talk · contribs 17:16, 1 June 2016 (UTC)

RfC

• Support as nom. Fred Gandt (talk|contribs) 10:02, 11 May 2016 (UTC)
• Support obviously, as the guy who started this whole process. Thanks to Fred Gandt for doing the heavy lifting. Oiyarbepsy (talk) 23:18, 11 May 2016 (UTC)
• Support. A great idea and a great implementation! APerson (talk!) 05:02, 12 May 2016 (UTC)
• Comment I support this idea in principle, but before we go through with it we need to make sure that this proposal won't make WP:RFD go over the post-expand include size. We need to work out what the maximum number of entries at RfD might be in the future, multiply that by the average post-expansion size of the template, and check that it's not over the limit, otherwise the bottom entries at RfD won't get any links.

  Also, I don't think we need the <span>...</span> tags in the heading, as headings are automatically anchored to their names. This seems to be a remnant from the time that the heading looked like [[:{{{redirect}}}]] → [[:{{{target}}}]], as the anchors didn't work properly with headings like that. I don't think that the <br> is necessary either - the two newlines should be enough separation between the links and the reason. But those are minor details - overall this move is a big plus. — Mr. Stradivarius ^{♪ talk ♪} 09:32, 12 May 2016 (UTC)

The <span> in the heading holds the id of the first {{{redirect}}}, where the actual heading was changed by the use of |header= - which may be important.

There's also |anchor= (undocumented) which sets yet another <span> id! I started to tidy all that up before I realised what Oiyarbepsy was really driving at.

The <br> is a replacement for a   used to keep the (parser dependent) newline formatting from collapsing. There were loads of   which I got rid of (in the sandbox) almost immediately (so overused!).

The template limits occurred to me too, but surely the numbers can't be that high? Like you say though, probably best to do the math ahead of time, rather than flying by the seat of our pants. Fred Gandt · talk · contribs 12:00, 12 May 2016 (UTC)

I don't think the span needs to be in the header, but I'm not sure what it's for. Stradivarius is probably right that it's an historic remnant. As for the include limit, what is the limit? The template would be transcluded once for every redirect nominated, which is once per log page, but the log pages themselves are transcluded onto the main log at WP:RFD, and with some multi-nominations (especially but not exclusively due to Neelix) that page can presently include thousands of redirects (with one substitution of {{rfd2}} per redirect) at a time. Not to mention {{rfd2}} also transcludes {{pagelinks}} which itself transcludes several modules. How many is too many? Ivanvector 🍁 (talk) 13:13, 12 May 2016 (UTC)

I've reworked the sandbox code to avoid the need for the <br> tag. Feel free to play around with it and/or revert it as you see fit. — Mr. Stradivarius ^{♪ talk ♪} 15:58, 12 May 2016 (UTC)

• Do it for now. If transclusion limits occasionally cause a problem, substitute some of them and problem solved. If transclusion limits is a constant problem, we can go back later. Oiyarbepsy (talk) 13:27, 12 May 2016 (UTC)

I agree, as far as I can tell this shouldn't be a serious problem. If it is, then we'll know better how to fix it. Ivanvector 🍁 (talk) 15:09, 12 May 2016 (UTC)

I've just added 480 substitutions of {{rfd2/sandbox}} (as is) to User:Fred Gandt/test "test" test and it's just about fine with a little wiggle room. I searched the previous month of real listings and ~24 was the highest number I saw for a day. {{rfd2 links}} is now ready for substing, and as a side effect, so now is {{no redirect}}. Fred Gandt · talk · contribs 15:30, 12 May 2016 (UTC)

I had just run the numbers and come up with the same conclusion. The post-expand-include-size limit is currently 2097152 bytes, and a {{rfd2 links}} transclusion with fairly long page names comes to about 4000 bytes. This makes for around 500 transclusions before we go over the limit. As Ivanvector points out, the daily logs are transcluded onto WP:RFD itself, so that shouldn't actually be affected appreciably by the change. The daily logs are where the difference would be biggest, but it doesn't look like we are anywhere near 500 nominations a day. So I'm satisfied now that the post-expand include size won't be a problem on the daily logs, and if it becomes a problem on the main RfD page, then it probably would have happened anyway without this change. — Mr. Stradivarius ^{♪ talk ♪} 15:54, 12 May 2016 (UTC)

@Mr. Stradivarius: Can we safely assume that AnomieBOT (or another) can be tasked to subst {{rfd2 links}} in only closed submissions? Bots must be parsing the page to target the transclusions, so establishing if they're in open or closed submissions shouldn't be too difficult, right? And, can we change |text= to |reason= with a fallback to {{{text}}}? I know I can, but upon your toes I'd be 'shammed to tread. Fred Gandt · talk · contribs 16:15, 12 May 2016 (UTC)

It's certainly possible, but I couldn't say how hard it would be without looking at AnomieBOT's code, plus Anomie is a busy man these days. In any case, I wouldn't do this if it can be avoided - I think substitution should be more of a last resort than a regular occurrence. And yes, feel free to rename the parameters or do whatever else you feel like with the template. You were here first, after all. :) — Mr. Stradivarius ^{♪ talk ♪} 16:33, 12 May 2016 (UTC)

Pure happenstance; If I were first on scene at a train wreck, I'd not expect or want emergency personnel to defer to me. F**k that! But, sure, I'll do that then. I like your fixes BTW, very elegant. Fred Gandt · talk · contribs 16:41, 12 May 2016 (UTC)

• Support per the conversation above, so long as Mr. Stradivarius' point is not fatal to the proposal. I don't think it is. Ivanvector 🍁 (talk) 12:57, 12 May 2016 (UTC)
• Strong oppose. Good concept, but I cannot support a workaround that results in a transcluded (as opposed to substituted) template being added to a daily subpage. The proposed solution causes some problems. There are issues in case a bot or code is created that needs the text to look a certain way to run its task, especially if it cannot find the aforementioned text because it is encapsulated in a transcluded template. Also, say this fix is implemented today: At the end of this year, the amount of transclusions of {{Rfd2 links}} would be 232 times how many nominations are on each page (though the transclusion list would only show 232 transclusions.) This method has too high of a chance to break things if {{Rfd2 links}} is edited erroneously, not to mention the fact that every page that uses this template will need to be purged when this template is updated. And then, let's saw down the road new consensus is to substitute every transclusion of {{Rfd2 links}} anyways due to WP:RFD being redesigned somehow: There are too many opportunities in that example for something to get erroneously broken by trying to fix false positives in the template transclusions. So no, any resolution that adds a template transclusion is not an advised one. Steel1943 (talk) 19:44, 12 May 2016 (UTC)

However, with that being said, I am curious how the current contents of Template:Rfd2/sandbox would function if it were merged into the current version of Template:Rfd2. For one, it looks as though the multi and header parameters function differently in the sandbox than they currently do in the parent template. Steel1943 (talk) 19:55, 12 May 2016 (UTC)

Agreed - one way or another, {{rfd2}} will end up better for the attention.

Good points, well made; things to ponder. Fred Gandt · talk · contribs 20:23, 12 May 2016 (UTC)

I pondered whilst walking my dog, and have reached the following conclusions:

• Bots yet to be created to read these pages will be created in the knowledge that they must expand the templates; this is trivial. Any current bots reading these pages will need to be updated, but change is the status quo here, and we must adapt.
• The number of transclusions is never going to be alarming. If we take an average of 10 submissions a day for 10 years, we get 36,525. 20 a day would be 73,050 and 50 = 182,625 ... The numbers are just not a problem.
• Templates are redesigned all the time, and high visibility/crucial templates are typically protected and (like this procedure) discussed carefully and sandboxed tests conducted so that accidents don't happen, but even if they do (which they do), a couple of clicks fixes it all - which isn't the case for substitutions with unnoticed errors. In that case, a bot may be required to fix all the raw markup one by one.
• It is unlikely that the result of the links code will change much, if at all, but if it does, why would purging be needed if substituted markup could be acceptable to leave as is? If we subst everything, it's more difficult to update if in fact updating past submissions is ever needed.
• Again, what's "down the road" is down the road and not really our concern. We are down the road from 10 years ago, and muddling along just fine.
• One issue I will apply a fix for tonight or tomorrow, will be to replace the timestamp with a clearly formatted date, so it's less confusing in the call to {{rfd2 links}}, and thus "erroneous fixes" will be less likely. It may also be advisable to name the arguments.

So, in conclusion, although they are points worth note, I think none stand up to scrutiny. I remain confident that there's no danger or trouble likely to be caused by this change. Fred Gandt · talk · contribs 23:09, 12 May 2016 (UTC)

• @Steel1943:I think it's safe to assume that the rfd2links template will be template-protected, which goes a long way to stop damage. Also, in the future, if we want to change this template while leaving old discussion the same, we can mass-substitute first, then change it. Oiyarbepsy (talk) 02:12, 13 May 2016 (UTC)

• Oppose. I don't really see the point, that is, if the point is just to simplify the raw substituted code of one template, then I have to be concerned about setting a trend to simplify all the other substituted templates that place complicated raw code by use of partial transclusions when used. If it ain't broke...! I think Steel1943 is on the right track. Having said all that, I really do appreciate all the work that's gone into this so far, and would of course be happy to go along with consensus if contrary to my opposition. For other reasons that I can't quite put my finger on yet, this whole idea rubs me reddish.  Stick to sources! Paine  15:15, 15 May 2016 (UTC)

• @Paine Ellsworth:Here's the point: Imagine someone nominates a redirect called redirect for deletion. Then, a couple hours later, or even the next day, someone discovers a redirect called redirects to the same target. Obviously the one called redirects should be added to the nomination instead of being a new nomination. With the proposed rfd2links template, you simply copy, paste, and change redirect to redirects. With the current implementation of the template, adding a second redirect to an existing discussion is a herculean task. And that's what's broken, that something that is routinely done, that should be simple and easy, is instead obnoxiously difficult. Oiyarbepsy (talk) 15:32, 15 May 2016 (UTC)

• Don't think that dog hunts too well, Oiyarbepsy, because in the example you use, it is very easy to just start over by copy/pasting the first two multi lines over the existing raw code just above the already existing rationale. You started with:

{{subst:rfd2|redirect=Redirect|target=TargetArticle|text=The action you would like to occur (deletion, re-targeting, etc.) and the rationale for that action.}} ~~~~

...which produces the raw code upon saving the page. And a couple hours later you copy and paste the following over all that raw code and leave the rationale intact:

{{subst:rfd2|redirect=Redirect|target=TargetArticle}}
{{subst:rfd2|multi=yes|redirect=Redirects|target=TargetArticle}}

...make a quick notation of the added redirect in the rationale and, if it's been more than a few hours, then adjust your sig's timestamp (I would strike through the old timestamp (<s>(old timestamp)</s>) followed by 5 tildes). The only thing that has to be done with the raw code of the initial nomination is to paste over it. Maybe it's me, but I still don't see a problem, and even if there were a problem, this is one of the simpler raw codes I've seen (on my edit screen it's only ten lines of code in largest print, nine lines of code at medium sized print). With all due respect, even if you've been doing this by altering the raw code, how can it possibly be such a "herculean task"?  Stick to sources! Paine  18:03, 15 May 2016 (UTC)

@Paine Ellsworth:You're completely wrong. What I really have to copy and modify is this:

*<span id="Foo">{{no redirect|1 = Foo }}</span> → [[:Bar]] <span> <span class="plainlinks lx">([[Special:WhatLinksHere/Foo|links]] '''·''' [//en.wikipedia.org/w/index.php?title=Foo&action=history history] '''·''' [//tools.wmflabs.org/pageviews#start=2016-04-11&end=2016-05-10&project=en.wikipedia.org&pages=Foo stats])</span></span></span>     <small>[ Closure: {{#ifeq:{{FULLPAGENAME}}|Wikipedia:Redirects for discussion|''(@subpage)''|<span class="plainlinks">''[{{fullurl:Foo|action=edit&summary={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as keep}}}} keep]/[{{fullurl:Foo|action=edit&summary={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as retarget}}}} retarget]/[{{fullurl:Foo|action=delete&wpReason={{Urlencode:[[{{FULLPAGENAME}}#Foo]] closed as delete}}&wpMovetalk=1}} delete]''</span>}} ]</small> 

Because that is what's actually on the page since it is a substituted template, after all. A person who nominate with Twinkle well, of course, not have the original subst text that produced that. Neither will a person who is not the original nominator. A copy/paste/modify technique should always work, without having to visit the stinking template documentation page to figure out how it was done in the first place. Oiyarbepsy (talk) 21:12, 15 May 2016 (UTC)

• Well, I agree that a copy/paste/modify technique should always work without having to visit the stinking template documentation page to figure out how it was done in the first place. I gave you that technique in my previous response to you. As I said below, don't take my word for it, because S H O C K !!! I have been known to be wrong. Just test it in your sandbox as I instructed above. When I tested it in my sandbox I found it to be just about the same ease to add multis whether the {{Rfd2}} template were substituted or transcluded. There is no technical restriction against transcluding this template as there is in the case of {{Rfd}}. All of those {{{|safesubst:}}} code entries help with that. We may also note that this template is already template-protected. So the only reason to substitute this template is because that's what the instructions tell us. Then maybe it's the instructions that we should be discussing instead?  Stick to sources! Paine  21:41, 15 May 2016 (UTC)

• Apart for a personal aversion being a weak argument against something, this RfC is not about how we should should edit any other template; "we shouldn't do this because someone else might do something else later" is codswallop. It is worth considering why it was ever decided to substitute this template in the first place, and only one technical reason exists that I can see (apart from the section heading noted below), which has been addressed by substing the date into the new call for the links. Please read my critique of Steel1943's opposition. Fred Gandt · talk · contribs 16:22, 15 May 2016 (UTC)

• Oh, it probably gets worse, friend Gandt, so I shall try to stay focused. The central reason for this RfC seems to be that the raw code is so difficult to handle. That was refuted in my response above to Oiyarbepsy. And the reason this code has been substituted in the past is that it's pretty much not necessary to be concerned about how new changes will affect past usages, and that often-used templates really should be substituted wherever possible to decrease the effects of vandalism. I know – yada yada. We've all probably read WP:SUBST a million times, and by the way, this template is not one of those listed that absolutely must be substituted. For me, the difficulty of adding one or more multis to the list is actually a little easier about the same or similar if the template's been substituted rather than transcluded. But don't take my word for it, test it yourself.  Stick to sources! Paine  20:04, 15 May 2016 (UTC)

PS. I should add that if an editor were to transclude Template:Rfd2, another editor will likely come along and substitute it for them. Perhaps we should address whether or not to remove the substitution requirement in the instructions? PS added by  Paine  20:45, 15 May 2016 (UTC)

• Oppose per Steel1943. If it ain't broke, don't fix it (which Paine Ellsworth alluded to as well). Short and blunt rebuttals to statements above, without explicitly clarifying which statements, as I have little time: Old closed discussions shouldn't be updated or changed, so I have no problem with that task being difficult; down the road is a valid concern; I don't find adding similar redirects to an existing nomination to be a "herculean task".—Godsy^(TALK_CONT) 03:27, 18 May 2016 (UTC)

The "if it ain't broke ... " argument against change doesn't carry. This is a proposal to alter the functionality of a template to output something easier to read, understand and thus use. This is not a proposal to fiddle with the template for the sake of it, and end up with no discernable change. This isn't like fixing a redirect in an article, that doesn't need fixing.

The rendered functional output is hardly likely to change over time, but if it's a concern that it might, and that change should not affect old transclusions, it would be trivial to have a bot substitute uses in closed submissions. Fred Gandt · talk · contribs 06:01, 18 May 2016 (UTC)

Actually, auch an argument carries very well, because the more such things are "tinkered with", the more chance we take of breaking things. It makes sense not to want to take that chance with a perfectly working template. The output does not have to be easier to read. This entire RfC is based upon the premise that the raw code is sooo difficult to work with that doing so is a "herculean task". That has been soundly rebutted by a simple copy-and-paste method of adding multiple proposals. That means that for all intents and purposes, this RfC is essentially over, and the proposer should end it by withdrawing their proposal. End of story.  Stick to sources! Paine  07:16, 19 May 2016 (UTC)

Absolute nonsense. Without change, we'd be throwing our effluence out the windows and dropping dead of old age at 35. Wikipedia and MediaWiki are constantly evolving by incremental change, for a multitude of reasons, many of which are driven by a desire to improve user experience. An argument against change, rather than an argument against the change is weak, lazy and inevitably doomed to failure - unless of course those who wield it propose we lock the project up in a vault and all go and do something else.

As I see it, there is one relatively valid argument against this proposal, which is technical in nature and simply solvable by bot.

The argument in favour is simple, but strong - the output is easier to work with, functionally sound and slightly improved. Fred Gandt · talk · contribs 07:48, 19 May 2016 (UTC)

Of course you are entitled to your opinion, whether or not it is overly dramatized. This is not an argument against general change, which would be anathema for this encyclopedia project. To clarify, "if it ain't broke, don't fix it" applies to this template at this time, and it is not a general "argument against change". Is yer back feeling better?  Stick to sources! Paine  08:28, 19 May 2016 (UTC)

Evidence of a real problem is provided by the request to change the behaviour, and the proposed changes are significant. This is not a bunch of fluff or my opinion, it's a proposed change with a request for comment. Without reasoned objection to the proposed implementation, rather than opposition to proposing a change to the implementation, this will be boldly done (once the one (so far) technical concern is addressed); this is not a vote.

Thanks for asking; my back's fine. My cold is nearly over, and the abscess leaking puss into my mouth is slowly getting better (I think), and my knees only hurt as much as usual, so that's relatively good ;-) How's yours and feet? Fred Gandt · talk · contribs 15:07, 19 May 2016 (UTC)

Evidence of a real problem is provided by the request to change the behaviour, and the proposed changes are significant.

There is no real problem save for a proposer (and other editors such as yerself) who did not know the easy way to add multiple entries, which is the only example given where the proposer had perceived a "herculean task".

This is not a bunch of fluff or my opinion, it's a proposed change with a request for comment.

Secret path to wisdom: never state the obvious.

Without reasoned objection to the proposed implementation, rather than opposition to proposing a change to the implementation,...

Neither of us gets to make that call, since we are both involved in this RfC. Reasoned objection results from the fact that an easy method of adding multiple nominations has been provided, so the proposed change is not needed, not wanted, not an improvement to this template, no matter how much and how hard anyone has worked to modify this useful template that works just fine as it is.

...this will be boldly done (once the one (so far) technical concern is addressed); this is not a vote.

I don't recall saying this is a vote or even a !vote. And I sincerely hope that by "boldly done" you don't mean that you will make a significant, disruptive change to this template while the RfC is still ongoing. No, of course you don't mean that; it's absolutely silly of me to even suggest it, even though I cannot for the life of me think what else you might have meant. It would be so good of you to elaborate.

It's a pleasure, and thank you for asking as well! As for my pain, thank the heavens for Percocet!

 Stick to sources! Paine  22:59, 19 May 2016 (UTC)

I'm a little offended that you'd even consider that I might mean to ignore the RfC and go ahead with the proposed change anyway - before or after. Not my style, which I'd have thought is pretty obvious to be honest. I am merely making it clear (or not, apparently) that if only one reasonable concern (about possible future changes affecting closed submissions) is on the table, and all other opposition is unreasonable when this RfC is tired, I will address the concern and go ahead with the update. That is my style. If I am not convinced that I shouldn't do this, I will.

I dunno 'bout you, but passing middle age is part of the reason my bits hurt. No pills for age yet, and I don't fancy rattling ;-) I thank heaven for Anime on Netflix and vaping strong nicotine solutions with plenty of tea to wash it down. Fred Gandt · talk · contribs 23:27, 19 May 2016 (UTC)

Wrapping up

Since there's been no discussion or further input for 10 days, I think we can consider wrapping this up. Clearly there is majority support for the change, but there is a technical concern that should be addressed:

• Older transclusions should not be affected by future changes to the template.
  • I suggest simply adding to the instructions for closing submissions, that the editor should also substitute instances of {{rfd links}}, should suffice. If it is considered too much to ask (sarcasm), we can always contract a bot to do it.

The only other oppositions raised have been countered. However, there has not been any explicit agreement between the parties involved. So a final decision will require a review of the discussion, considering what seems most reasonable baring all that's been said in mind.

• Closing comments
• It is my personal opinion that the arguments against are without merit, and I continue to consider the proposed changes as potentially beneficial. Fred Gandt · talk · contribs 03:07, 30 May 2016 (UTC)

• Interesting that you have completely neglected the fact that it is this proposal that was "countered" by a simple procedure that negates the need for this change, and I might add that nobody has actually disagreed that the proposal to copy and paste new code over the old code, which means that the old code does not need to be altered, merely deleted and pasted over, meets the needs of the editor who first saw it to be a herculean task... only you. Only you continue as if there is still a need for this proposal to go through, and there is no need for it. Minor changes you want to make as discussed in the next section aside, the function of this template should not be tampered with, and you should know better than to ignore the obvious truth of this!  OUR Wikipedia (not "mine")! Paine  12:46, 31 May 2016 (UTC)

Transcluding instead of substituting

user:Paine Ellsworth has suggest a couple of times above that the real answer my be to just transclude Rfd2 instead of substituting it. Perhaps that makes sense. In my view, though, the heading and the reason should not be within a template, which makes user:Fred Gandt's proposed change the best answer - substitute the heading and reason, and transclude everything else. Oiyarbepsy (talk) 21:50, 15 May 2016 (UTC)

For two very good reasons, we need to substitute the wrapper of the links {{rfd2}}:

1. So we don't have this problem. i.e. Sections can be edited, and differentiated.
2. So the dated links are stable. i.e. One of the links is dated, which will change every 24 hours if it's not substed.

The guts of the template do not need to be substituted, but the section heading does, and because of the |multi= param, it's simplest to also subst the |reason=.

I'd not take Paine Ellsworth's commentary too seriously; there's no logic or reason to it; it started out as a personal opposition to transclusion in agreeance with Steel1943's initial opposition, then rapidly switched to an argument to transclude the everything without switching to support!? No, if you want the template to function correctly and be elegant in the raw, then the proposed method is pretty much ideal. Fred Gandt · talk · contribs 03:53, 16 May 2016 (UTC)

The best answer is to leave this viable template alone and let it continue to work well as is. There is much logic and reason to discovering a much easier way to perform a task such as adding a second entry or multiple entries without having to deal with a substituted template's wikimarkup (other than to overwrite the raw code with new substituted code). I stand by previous opposition and see absolutely no reason to make any changes to Template:Rfd2.  Stick to sources! Paine  07:50, 16 May 2016 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

span id again

I've been trying to write some RfD scripts today and found that this template create two instances of <span id="Redirect name">. I don't think this is appropriate? HTML 4.01 and HTML 5 both says this is officially wrong[1] (but obviously doesn't break things until a user tries to write a script to parse them). Deryck C. 22:08, 31 May 2016 (UTC)

The <span>s will be removed shortly, but as a contentious RfC (above) is ongoing that involves those edits (which may be made in one of two proposed ways), I'd ask that you please wait for the outcome; it'll be only a matter of days. Fred Gandt · talk · contribs 05:20, 1 June 2016 (UTC)

@Fred Gandt and Deryck Chan: Actually, the set in the section header can be removed with no issues, so done. Steel1943 (talk) 16:06, 1 June 2016 (UTC)

• @King of Hearts and Tavix: Please check that this change doesn't break your RfD scripts. Deryck C. 17:48, 1 June 2016 (UTC)

There's nothing to worry about from my end. What a fascinating discussion above though, I'm disappointed that I missed it. -- Tavix ^(talk) 17:56, 1 June 2016 (UTC)

@Tavix: You haven't missed it; if you have anything to add, please do. Fred Gandt · talk · contribs 20:50, 1 June 2016 (UTC)

Add a talk link to the redirect talk page

Per a request at WT:RFD, can this template be modified to include a link to the redirect's talk page?

@Tavix: the template is protected so I can't do it, and I'm not sure I could see my way through the template code anyway. Where do you think a talk link would be most useful? Ivanvector (^Talk/_Edits) 20:56, 9 November 2016 (UTC)

I'd do it if I knew how to, but the code seems too complex for me, and I'm too afraid to try and figure it out. I think it should be added somewhere in the "(links · history · stats)" area, but I don't care what order it's in. -- Tavix ^(talk) 21:11, 9 November 2016 (UTC)

I'll ping Steel1943 as he's done some work on this template in the past. -- Tavix ^(talk) 01:00, 10 November 2016 (UTC)

@Tavix and Ivanvector: I've added a talk link to {{rfd2/sandbox}}. For an example, see the test cases. Does that look ok? — Mr. Stradivarius ^{♪ talk ♪} 05:38, 10 November 2016 (UTC)

@Mr. Stradivarius: Beat me to it. Looks perfect to me. I'd say sync it. Steel1943 (talk) 22:14, 10 November 2016 (UTC)

I agree, it looks fine to me as well. -- Tavix ^(talk) 22:18, 10 November 2016 (UTC)

Concur.— Godsy ^(TALK_CONT) 22:20, 10 November 2016 (UTC)

 Done — Godsy ^(TALK_CONT) 23:19, 10 November 2016 (UTC)

Closure @subpage not needed

Currently, the closure links don't display when viewing the main Wikipedia:Redirects for discussion page, as they depend on the FULLPAGENAME magic word.

This is no longer necessary due to a new lua module that returns the page it is used on, even when transcluded. I have coded a proposed update in the sandbox that allows the closure links to work when transcluded, and does not need updating after a relist. Thoughts about this change?

Pinging Steel1943, who introduced the "@subpage" link feature a while ago. Pppery 03:50, 22 January 2017 (UTC)

• @Pppery: Yeah, that is current intentional due to the way {{FULLPAGENAME}} works. However, I'd be weary to use the fix you're proposing, but do not straight up "oppose" it. To allude, I'd think a better long-term solution would be to have the magic word created that I recommended at Wikipedia:Village pump (technical)/Archive 147#Magic word question. But, eh, who knows about that one since it's been seeming to take a while to implement ideas through Phabricator or as gerrits these days... Steel1943 (talk) 04:01, 22 January 2017 (UTC)
  • @Steel1943: What is the advantage of a magic word over my five-line lua module, which implements the exact same functionality? Pppery 14:05, 22 January 2017 (UTC)
    • @Pppery: I never claimed that there was one... Steel1943 (talk) 02:02, 6 February 2017 (UTC)

Why subsubsections?

This template creates new subsubsections (====) instead of sections (==). On a page with multiple Rfd entries, they kind of run together. I tried replacing ==== with == on Wikipedia:Redirects for discussion/Log/2018 January 2 to see. Maybe I shouldn't have. (See if it gets put back?) Then I realized that the ==== weren't a tradition, they were the doing of {subst:rfd2|...}, so every new page and every new entry will have ==== unless someone adjusts this template. What is the norm? (On talk pages, it's new sections.) - A876 (talk) 23:19, 2 January 2018 (UTC)

To make the section hierarchy right on the main Wikipedia:Redirects for discussion page. {{3x|p}}ery (talk) 02:42, 3 January 2018 (UTC)

In other words, they have to be subsubsections because the log pages are designed to be transcluded onto another page (the <noinclude> tags hint this), within an existing section on that page.

Okay, my change broke something, so it promptly got undone (with an incomplete statement of what it broke, and preachy advice).

I did not know (should I have known?) that Wikipedia:Redirects for discussion transcludes Wikipedia:Redirects for discussion/Log/2018 January 2 (and 8 other sub-pages) (at present - the lineup changes) under its final section, namely ==Current list==. The transcluded sub-pages contain ===Date=== (with a self-link) and then multiple ====Items====, making a workable hierarchy in both places, while keeping detailed history confined to each log sub-page.

These pages add up to an interesting "application" built on multiple-page "programming" that runs on a server designed for hosting wiki content. I wonder how it is all supposed to stay together without way finders. I tried adding one - let's see where that gets. Update: though it broke nothing, it got reverted with a crabby "Please do not adjust the standard page formatting without consensus" - as if there were some other place to seek consensus on "standard page formatting" of a multi-page application. I didn't think lack of pre-consensus was grounds for reversion - though others chant "BRD" as if revert simply-because-it's-a-change (or simply-because-you're-not-me) is a given. There's theory ("anyone can edit"), and then there's practice ("please never edit"). Anyway, here's the idea in case anyone is interested.

Lastly, as great as this bulletproof user-friendly scheme is, other departments naturally use different schemes:

• Wikipedia:Requested moves transcludes one sub-page (Wikipedia:Requested moves/Current discussions) that is updated 20 times a day by a bot to echo active move discussions from multiple talk pages.
• Wikipedia:Requested moves/Technical requests has editors manually add requests and comments on one page; after which "closers" (who make decisions way before 7 days) manually delete each entire discussion (appalling?) upon closure either way, leaving records only in the [unsearchable] revision history. -A876 (talk) 22:31, 3 January 2018 (UTC)

Template-protected edit request on 5 March 2018

Please wrap the delete link in <span class="sysop-show">...</span>, because it produces an error for non-admins. {{3x|p}}ery (talk) 15:37, 5 March 2018 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. — Martin (MSGJ · talk) 15:58, 5 March 2018 (UTC)

 Done {{3x|p}}ery (talk) 16:35, 5 March 2018 (UTC)

 Done — Martin (MSGJ · talk) 16:52, 5 March 2018 (UTC)

Linter error fixes and (@subpage)

As I mentioned in the edit summary of the undo I performed which resulted in reverting WP:LINT errors that were present in the template, I am starting this discussion to resolve this. For some reason, this series of edits on Template:Rfd2 caused formatting issues with the way the phrase "(@subpage)" appears on Wikipedia:Redirects for discussion. (This text will only appear on Wikipedia:Redirects for discussion and not the daily subpage since on the daily subpage, the text is replaced with closure links.) Around the transclusion of the December 11, 2018 subpage on Wikipedia:Redirects for discussion, I noticed that something was odd/different about the formatting of the "(@subpage)" text; for some reason, the text went from appearing as (@subpage) to appearing as '(@subpage)'. So, I looked at Template:Rfd2 and noticed that Jonesey95 had performed tre aforementioned series of edits to fix lint coding issues. So, I tested transcluding {{Rfd2}} after undoing the edits, and the issue with (@subpage) was reverted and appeared as (@subpage). Then, I restored the edits to fix the lint coding errors, and once again, (@subpage) appeared as '(@subpage)'. I looked the template and the edits, and cannot figure out where the two additional commas are appearing in the code, causing the italics to turn into bolding and adding an additional comma to both sides. So ... is there any way to fix the lint errors without breaking the code itself? Steel1943 (talk) 18:49, 14 December 2018 (UTC)

Once this discussion is resolved, I will fix all of the problems that I caused with formatting over the last four days or so. – Jonesey95 (talk) 19:03, 14 December 2018 (UTC)

Fixing Linter errors

The above edit-requested change resulted in the template starting to produce Linter errors. I attempted to fix the problems on December 11, and the Linter errors went away in subsequent days' log pages, but my changes have been reverted with an explanation that Wikipedia:Redirects for discussion was broken in how it renders the "@subpage" text.

I see that the entries prior to my edits show "[ Closure: (@subpage) ] and the entries after my edits show "[ Closure: '(@subpage)' ]". If that is the only problem, I believe that inserting a self-closed nowiki tag after "Closure: ''" may fix the code that existed pre-revert. I have put that code in the sandbox and will test it. – Jonesey95 (talk) 18:51, 14 December 2018 (UTC)

@Jonesey95: That’s the only issue I saw. I would have fixed it myself if I could have figured what was causing it, but I couldn’t figure it out. Hope this works since I know fixing the linter errors is an ongoing task project-wide. Steel1943 (talk) 18:57, 14 December 2018 (UTC)

Yes, this template is a complex little hairball. I believe that I have fixed it in the sandbox, and I have substed the sandbox version onto today's log page. Do the log page entry and the full RFD page entry look right to you? My fake nomination is called "foo". Thanks for your patience. – Jonesey95 (talk) 19:02, 14 December 2018 (UTC)

From what I can see, the substitution that you created has the (@subpage) text appear as (@subpage) on Wikipedia:Redirects for discussion, and I do not see any additional formatting issues on either the aforementioned page or the subpage. If that version also fixes the linter issues, I’d say it’s ready to go live. Steel1943 (talk) 19:09, 14 December 2018 (UTC)

 Done. Thanks again for your patience. Reverting was the right thing to do, since my intention was to preserve the formatting while fixing the Linter errors, and I clearly failed to do so. I will tidy up the four or five days of pages that I broke. – Jonesey95 (talk) 19:13, 14 December 2018 (UTC)

@Jonesey95: Wow, that was it? I suspected that the problematic commas were elsewhere. Dang, mind blown. Thanks for the fix! Steel1943 (talk) 19:18, 14 December 2018 (UTC)

The problem was that I had moved a misnested '' (italic formatting, two of ') so that it ended up right next to the italic formatting for "@subpage". That resulted in four ' in a row, which renders as bold (three ') plus an extra '. Sneaky, and it happens only on the main page, not on the daily log page or in the sandboxes where I was doing all of my testing. Extra sneaky. – Jonesey95 (talk) 19:26, 14 December 2018 (UTC)

Protection

Is there any reason to keep this template protected? It was indefinitely protected in 2014 as "highly visible", but that doesn't seem relevant now: the template is not used directly, but it gets substituted in new RfD nominations, of which there aren't usually more than a dozen or so a day. If someone cocks up something with the template, this will only affect any new rfd nominations made until the edit is reverted, and reader-facing parts of the encyclopedia won't be affected at all. – Uanfala (talk) 13:44, 16 May 2019 (UTC)

Have you looked at the code for this monster? I am an experienced template editor, and I want to run away screaming. See above for an example of a tiny change that bollixed up everything, after which I had to go through multiple pages of RFDs and clean up after myself. I recommend keeping protection in place; there is no need for inexperienced editors to make changes to this template, and the sandbox and testcases pages are always available to people looking to improve things. – Jonesey95 (talk) 13:50, 16 May 2019 (UTC)

Makes sense. But if it weren't protected, I think I might have been tempted to insert a couple if html-commented out newlines to make it a bit more readable. – Uanfala (talk) 14:04, 16 May 2019 (UTC)

Feel free to make your changes in the sandbox. I'm all for making it more readable. It's a hairball. – Jonesey95 (talk) 19:25, 16 May 2019 (UTC)

Template-protected edit request on 10 November 2020

Please copy the contents of the sandbox, which adds an option to close a RFD as "dab", to the main template page. JsfasdF252 (talk) 04:44, 10 November 2020 (UTC)

I don't really see the point. The template text is exactly the same, it just changes the edit summary (and a 'dab' close is technically a keep I'd think, although I'm not active at RfD). I think this should go for discussion at Wikipedia talk:Redirects for discussion first. ProcrastinatingReader (talk) 18:38, 10 November 2020 (UTC)

To editor JsfasdF252:  Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. P.I. Ellsworth  ed. ^put'r there 00:38, 11 November 2020 (UTC)

Position of links

Hello. It seems to me that the links (talk · links · history · stats) should be positioned after the first link (redirect) and not the second (target). This is because they relate to the redirect and currently it seems like they relate to the target. It seems striking when the talk page link next to a well visited target page is red.

Example:

Suffusion → Hematoma  (talk · links · history · stats)

It would make more sense to have this as:

Suffusion  (talk · links · history · stats) → Hematoma

Comments?

--TadejM ^{my talk} 13:24, 16 February 2021 (UTC)

• Good idea. While we're at it, I've been thinking of suggesting adding a link to the search engine for the title of the redirect, as searching for mentions in Wikipedia articles is often useful for investigating alternative targets for redirects. Thryduulf (talk) 15:28, 16 February 2021 (UTC)
  • If we're going to spread out the redirect and target links and add another in between, it might help to add some formatting that would draw the eye to them. We could try making the redirect and target links bold. - Eureka Lott 18:00, 16 February 2021 (UTC)
    • Or maybe move the links to a new line below? That would also allow space to add links to the target history and talk if desired (which are sometimes relevant, although less often than other links) if desired (but don't let this suggestion derail the whole thing). Thryduulf (talk) 20:08, 16 February 2021 (UTC)
      • @Thryduulf: Moving the links to a new line might get a bit messy when looking at combined nominations with more than 1 redirect. In addition to a link to Wikipedia search can I suggest that a link to google search would also be useful to have?

If you're concerned about length I would suggest that the talk page link is fairly useless, as 90% of redirects don't have talk pages and the ones that do it will generally either be a redirect from a page move, blank except a wikiproject redirect banner, or containing some comments from an article that hasn't existed for years. The only time it's really relevant is if there's been a recent disagreement on the talk page, in which case it is normally mentioned or linked in the nom statment. You could also nest the search links using Template:Su to make the thing more compact, perhaps like this? Might make the links difficult to click on mobile devices though. 86.23.109.101 (talk) 21:14, 16 February 2021 (UTC)

Suffusion  (links · history · stats · ^{Search Wikipedia}
_{Search Google} ) → Hematoma

That's a good point. I don't like the stacked text (I'm also not sure how screen readers deal with it). A better solution for length would just be to abbreviate - talk → t, history → hist, etc. but the point wasn't line length but separation of redirect and target. Thinking again the original issue might be resolvable by keeping all the links at the end but prefixing them with a label like "redirect: ". @TadejM: how would that be for you? Thryduulf (talk) 21:40, 16 February 2021 (UTC)

Another option (thought it would take some serious getting used to) would be to swap the position of the target and the redirect. 86.23.109.101 (talk) 22:24, 16 February 2021 (UTC)

Hematoma ← Suffusion  (talk · links · history · stats)

Thank you all for your comments and suggestions. Both solutions are fine for me, though in my opinion, keeping the links with the discussed redirect(s) and spelled out makes things more intuitive, more tidy, and easier to understand. I'd keep the order as it is since we usually read from the left to the right and this eases the work. Regarding further links, I would support adding Wikipedia search and would keep things as simple as possible (to avoid clutter and rendering issues). The red link may be hidden though if the talk page is empty. --TadejM ^{my talk} 23:46, 16 February 2021 (UTC)

As there has been no further comment and there has been general support, I'm going to implement this in the following day(s). --TadejM ^{my talk} 02:40, 21 February 2021 (UTC)

Please make your changes to the template's sandbox and demonstrate them on the testcases page. Thanks. – Jonesey95 (talk) 17:16, 21 February 2021 (UTC)

Bug report

Resolved

Colons in redirect names screw with the pageviews link in RfD nominations (example diff). –LaundryPizza03 (dc̄) 01:18, 1 August 2021 (UTC)

This was down to a recent change to {{page-multi}}, and it appears to have already been fixed: see Template_talk:Page-multi#Broken. – Uanfala (talk) 19:35, 2 August 2021 (UTC)

Equals sign in titles

Redirects beginning and ending with an equals sign are handled improperly by this template. I got:

Plain = sign
U [[:]] → Ustaše  (talk · links · history · stats)     [ Closure: keep/retarget/delete ]  Lorem ipsum dolor sit amet, adipscing integer et elit.

Even with the template {{=}}, the template is generated without the auxiliary links about the redirect:

With template {{=}}
=U= =U= → Ustaše       [ Closure: keep/retarget/delete ]  Lorem ipsum dolor sit amet, adipscing integer et elit.

What was expected is:

Expected output
=U= =U= → Ustaše  (talk · links · history · stats)     [ Closure: keep/retarget/delete ]  Lorem ipsum dolor sit amet, adipscing integer et elit.

–LaundryPizza03 (dc̄) 03:54, 27 March 2022 (UTC)

Further tests revealed that all titles with two or more equals signs cause this problem. –LaundryPizza03 (dc̄) 04:20, 27 March 2022 (UTC)

Also, one equals sign causes the same problem, except when a page begins with 1=, in which case this happens:

–LaundryPizza03 (dc̄) 04:27, 27 March 2022 (UTC)

Template-protected edit request on 28 March 2022

Handle equals sign in parameters. Fix Wikipedia talk:Twinkle#Title beginning and ending with an equals sign. Patch provided in the sandbox. Xiplus (talk) 01:15, 28 March 2022 (UTC)

 Done. Thanks for catching this; it was something I'd overlooked when switching from {{no redirect}} to the custom {{Rfd2/-r}}. -- Tamzin^{[cetacean needed]} (she/they) 09:57, 28 March 2022 (UTC)