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)[reply]

{{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)[reply]

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)[reply]
• 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)[reply]
  • 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)[reply]
• 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)[reply]

• Support as nom. Fred Gandt (talk|contribs) 10:02, 11 May 2016 (UTC)[reply]
• 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)[reply]
• Support. A great idea and a great implementation! APerson (talk!) 05:02, 12 May 2016 (UTC)[reply]
• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

• 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)[reply]
• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

• @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)[reply]

• 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)[reply]

• @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)[reply]

• 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)[reply]

@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)[reply]

• 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)[reply]

• 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)[reply]

• 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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

---

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