Template:2020–21 Austrian Football Bundesliga Regular Season table
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 00:45, 14 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:Mitsubishi Canada timeline
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:2020–21 Liga II table
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 00:45, 14 August 2020 (UTC)[reply]
Note: This discussion has been included in WikiProject Football's list of association football-related deletions. GiantSnowman 14:30, 7 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:Bankura-Masagram branch line
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 00:45, 14 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:List of national instruments- start
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:Indent-fix-begin
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 01:20, 14 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:Handball table start
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 00:46, 14 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:Discography/start
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
This is a strange situation. These 3 templates are sub-pages of ((Discography)), but that template is a completely different one. They are used on 4 pages via ((D/start)), but ((D)) is yet another different template. Since there must be thousands of discography tables and these are only used 4 times, these are probably not needed can use a normal table. Gonnym (talk) 09:15, 6 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:HD Radio 2
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Primefac (talk) 00:47, 14 August 2020 (UTC)[reply]
Back in January, I proposed changes to ((HD Radio)), a template almost exclusively transcluded in infoboxes, to bring it in line with MOS:SMALLFONT. After consensus built in a discussion on the template talk page, these were implemented.
The creator of this particular template page reverted the changes despite not participating in the template, and I discovered an article they had edited using this—essentially the pre-2020 version of this template—which was created in July. (The involved editor did respond to a message I left on their talk page, but unfortunately I did not see that reply until now.)
This template is redundant to ((HD Radio)) and has further accessibility issues, and worse, it was created as an end-around of a discussion. Raymie (t • c) 06:21, 6 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:2009 swine flu genetic table
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was subst and delete. Primefac (talk) 22:47, 21 August 2020 (UTC)[reply]
Used once, this is a fantastic template. However, it should be placed within article space so that future editors have an easier time editing it. I propose substitute and delete. Tom (LT) (talk) 08:56, 28 July 2020 (UTC)[reply]
@Tom:, I see that most of your deletion requests are because "Used once". I'am part of the users who prefer to take rich summary table off the article so to be able to work on it peacefully. Another additional gain is to make multiple transclusions possible. But both aspect are valuable. The navbar (V-T-E) create a quick access to edit it. Is there a real gain to include these element back into the article ? Yug(talk) 09:21, 28 July 2020 (UTC)[reply]
Hey Yug, you'll notice I have not nominated all such templates. I personally feel there is a balance as to which should be merged and which should be kept separate from articles. Templates that are very long or highly active (such as mortality rate templates whilst a pandemic is active, or the worldwide count that is really long) benefit from being separated from articles. However, my opinion is that when the topic becomes historical, a template used once that is not too complex should be moved back into article space. In article space it's easier for others to edit (new and novice editors won't know about templates), and also is generally consistent with the way we hold most of our tabular or visual information, which is in article space. That said, I propose these here so that the community can input, and would be happy to hear variation with this opinion. Cheers --Tom (LT) (talk) 09:26, 28 July 2020 (UTC)[reply]
(ec) Re Yug: I support this approach Yug mentions (keep template, even if transcluded only once). The idea "should be placed within article space" is is not sensible. I myself have had much profit of these Category:Infobox element per element (0) in single-use, as it simplifies maintenance thoroughly. -DePiep (talk) 09:38, 28 July 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Primefac (talk) 01:30, 6 August 2020 (UTC)[reply]
Subst and deleteThe Template namespace on Wikipedia is used to store templates, which contain Wiki markup intended for inclusion on multiple pages* Pppery *it has begun... 14:17, 6 August 2020 (UTC)[reply]
@Bsherr: As simple information, none of the text in the template is copyrightable. The image is in the public domain (17 U.S.C. § 105(a)), and is attributed anyways. The page can be deleted. —Mdaniels5757 (talk • contribs) 16:12, 15 August 2020 (UTC)[reply]
The concern with templates is that the code is copyrightable. --Bsherr (talk) 13:58, 16 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Template:2009 flu pandemic in Asia table
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The result of the discussion was delete. Subst and delete. There are no copyright issues; facts are not copyrightable. (non-admin closure) —Mdaniels5757 (talk • contribs) 16:14, 15 August 2020 (UTC)[reply]
Used once. I propose substitution and deletion. Tom (LT) (talk) 08:55, 28 July 2020 (UTC)[reply]
Only being used once isn't alone a great reason for substitution and deletion. ((Syrian civil war infobox)) is also only really used once as well, but imagine having that in the article itself. Doesn't make sense to substitute this into the article itself. That said, I'm not sure why these kinds of one-template usages aren't just created as sub-pages of the article and embedded in that way, rather than added to the template namespace. ProcrastinatingReader (talk) 12:40, 4 August 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Primefac (talk) 01:29, 6 August 2020 (UTC)[reply]
Subst and deleteThe Template namespace on Wikipedia is used to store templates, which contain Wiki markup intended for inclusion on multiple pages (and yes, if you care, I also believe ((Syrian civil war infobox)) should be substed and deleted) * Pppery *it has begun... 14:19, 6 August 2020 (UTC)[reply]
substitute and delete, but if you want to preserve attribution, you can add the list of authors to the edit summary (User:JL 09, User:Debresser, User:Shin368, User:Juliancolton, User:70.29.212.226, User:124.105.208.255, User:Zararo, User:Sap00acm, User:Roman888, User:Whhalbert, User:WOSlinker, User:219.78.187.12, User:96.52.193.72, User:Ckjian, User:121.96.109.207, User:58.99.50.8, User:Epson291, User:121.96.121.26, User:Hariboneagle927, User:121.96.110.82, User:Rizalninoynapoleon, User:211.76.82.68, User:Rockysmile11, User:Moc09, User:70.29.208.69, User:Ponpan, User:58.69.63.208, User:121.1.48.2, User:212.174.34.186, User:58.69.4.200, User:219.78.163.19, User:Conti, User:58.69.182.59, User:201.76.140.193, User:94.71.188.124, User:58.69.198.248, User:Nomada18, User:Acolombo1, User:FHessel, User:122.162.80.31, User:Abhi2810, User:87.68.55.19, User:Nafis ru, User:HongQiGong, User:117.47.51.99, User:117.47.119.112, User:119.237.148.92, User:Xyz7890, User:Mediantiba, User:Kavas, User:95.30.117.223, User:Turkish Flame, User:121.96.121.68, User:71.140.145.201, User:95.30.245.161, User:95.30.122.77, User:71.130.210.236, User:121.96.125.127, User:119.152.89.157, User:71.140.64.141, User:71.140.103.184, User:AstroHurricane001, User:80.78.69.162, User:Arcadian, User:Jonesey95, User:Timrollpickering, User:Tom (LT), User:Primefac). some of these may not be significant edits, but that would cover any attribution issues. Frietjes (talk) 19:42, 11 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Propose mergingTemplate:Talk archive navigation with Template:Automatic archive navigator.
Templates are substantially identical aside from default parameter values, and the documentation explicitly acknowledges this (in the "see also" section). In fact, this template is probably eligible for T3, but not doing that because this has over 50,000 transclusions and was previously discussed at TfD. (Note: Template is currently protected, so I can't tag it. I placed or will shortly place an ((editprotected)) on the talk page.) NYKevin 19:17, 17 July 2020 (UTC)[reply]
Support The only differences between these two are the default value for number of links and whether there is a link to the first red linked archived. My preference here is for ((Aan)) because I find 7 links more convenient for navigation than 3, including on small screens. --Trialpears (talk) 22:59, 17 July 2020 (UTC)[reply]
For clarity, when I said "Don't merge anything" above, what I mean is that there isn't anything worth merging, especially considering that a "merge" happened back in 2013 and both templates invoke the same module and are thus both forks of the same code ... which is why I'm saying to redirect one to the other since it wouldn't break/remove anything that is necessary to retain. Steel1943 (talk) 16:08, 23 July 2020 (UTC)[reply]
I feel a bit iffy about altering other peoples personal User talk archives. For the other namespaces I'm completley fine with this solution, in fact I wouldn't mind a universal archiving solution for all article talk pages using the same handful of templates, but a proper replacement preserving appearences really should be done in userspace. --Trialpears (talk) 17:13, 18 July 2020 (UTC)[reply]
So, I've had ... umm, about 7 years to think about such things (I was the nominator of the aforementioned discussion, after all), and since the only major difference (I don't consider the amount of links an issue) is the red link switch, I see no problem doing this since the archive links are automated. And I also considered replacing the ((Talk archive navigation)) templates with their respective red link parameters, but that may end up getting too complicated since the two nominated templates have the red link parameter set up in the opposite fashion by default. If anyone needs to reenable the red links on their talk page archives agree such a redirects, they can do so by adding a |noredlinks=no parameter in each one. (I get it, having editors update their own templates as a result of discussions like this is highly not preferred since we want to merge al functionality as cleanly as possible so no one has to update transclusions, but this is the 0.0001% time of such instances where I say ... oh well, just get the redirection done since ... 7 years.) Steel1943 (talk) 17:24, 18 July 2020 (UTC)[reply]
...The only other option would be for a bot to add |noredlinks=no to all transclusions of ((Talk archive navigation)) with no noredlinks parameter prior to the redirection, but that would be it. This would work in this manner without breaking anything since both nominated templates invoke the same module: Module:AutomaticArchiveNavigator. Steel1943 (talk) 17:31, 18 July 2020 (UTC)[reply]
That is exactly what I think should be done, at least in userspace. --Trialpears (talk) 17:38, 18 July 2020 (UTC)[reply]
If a bot is going to be run anyway to correct the parameters, it should instead just straight-up replace those instances of ((Talk archive navigation)) (and any aliases) with ((Automatic archive navigator)) to bypass the redirect. This could even be done now since we have the 2013 consensus to merge. Also, we should avoid making (double-)negative and unnecessary plural parameters like |noredlinks=no and instead go with something like |redlink=yes. -- Netoholic@ 06:23, 20 July 2020 (UTC)[reply]
...Which I believe would require Module:AutomaticArchiveNavigator be updated to include a |redlinks parameter since from my knowledge, that named parameter is currently not built in the module. Steel1943 (talk) 12:03, 20 July 2020 (UTC)[reply]
No it already is. It's just called |noredlinks=. --Trialpears (talk) 12:06, 20 July 2020 (UTC)[reply]
@Trialpears: Please review the above statements: The existence of "noredlinks" is acknowledged ... I'm stating that "redlinks" (without the "no"), which I assume would be a new parameter that is being proposed which would be set up to do the exact opposite function as "noredlinks" ("yes" would make the red link appear with the red link being hidden be default ... the exact opposite function of "noredlinks", which hides the red link in ((Talk archive navigation)) when set to |noredlinks=yes since the aforementioned template displays the next red link by default), doesn't exist. Steel1943 (talk) 13:07, 20 July 2020 (UTC)[reply]
Oh, sorry should have reread the previous messages before replying. I can add that feature in the sandbox later today. --Trialpears (talk) 13:12, 20 July 2020 (UTC)[reply]
Redirect per Steel1943. I understand Trialpears's concerns, but disagree. Userspace isn't a personal blog and it isn't sacred. --Gonnym (talk) 10:04, 19 July 2020 (UTC)[reply]
@Pigsonthewing: That additional merge world require someone who knows how to edit Module:AutomaticArchiveNavigator to be ready to do so, and I don't think its primary editor has edited regularly in a while. I agree the merge should happen eventually (I think we have had a similar discussion in the past), but that's probably a discussion to have after the more-similar templates are merged first. I mean, consensus is consensus, but if that merge were to happen between the navigation templates and the templates with no automatic navigation ... umm, I'd want the text in the resulting template to be left-aligned. Steel1943 (talk) 19:38, 19 July 2020 (UTC)[reply]
We have plenty of people capable of editing that or any other module. We don't preserve code in aspic just because its original author is no longer active. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:44, 23 July 2020 (UTC)[reply]
Yeah, I'm not disagreeing with or debating that. Steel1943 (talk) 16:03, 23 July 2020 (UTC)[reply]
Redirect per most of above comments. There's a lot of work to be done in reducing the number of archive navigation templates. -- Netoholic@ 06:23, 20 July 2020 (UTC)[reply]
Merge per above comments. We have way too many archiving templates, let's start paring things down a bit. Nathan2055talk - contribs 23:07, 22 July 2020 (UTC)[reply]
Merge per above. Simpler for all involved to have the same template. I would even support replacing and deleting because that way people will be seeing a consistently-named and used template. --Tom (LT) (talk) 15:20, 23 July 2020 (UTC)[reply]
The consensus in the previous discussion was merge with the note: "Editors performing the merge, please try to retain functionality, shortcuts, etc. The name beginning "talk archive..." was favored, and it is also the most used template by a factor of 2:1, so I suggest merging Aan into Tan." This current discussion is attempting to change that into merging Tan into Aan, which loses some functionality. The most important is that Tan has a red link for the next archive, which makes it easier to create that archive. Without the red link, creating the next archive has to be done manually. As someone who frequently archives, I would find the loss of that red link to make archiving a little more tedious to the degree that I may be discouraged from doing it. Archiving is something I do now and again as I come upon a talkpage that looks cluttered and/or contains some very old and no longer relevant discussions. Making the task a little harder means it is less likely to be done. Indeed, if nobody is willing to do the work of merging properly and retaining functionality, then I would strongly oppose the merge as written as having two similar templates is not a problem, while loss of useful functionality is. SilkTork (talk) 23:09, 23 July 2020 (UTC)[reply]
SilkTork I think that displaying the red link should be the default as well for the reasons you gave and I think that is likely to be the community consensus from reading a few other discussions. I also think 7 links are easier to navigate with which looks like the consensus opinion in this thread. The issue with this is that the current defaults are such that ((aan)) has 7 links but no red ones while ((tan)) has 3 links while allowing red links making neither the best of both worlds. While this means that all pages using both aan and tan would have to be changed if we put these as the defaults and wanted to preserve the old appearance, but if we don't care about preserving appearances we could get basically all pages to use the options that are generally considered most useful by redirecting one to another (names doesn't really matter) and changing the defaults. What do you think about this last option? I'm personally starting to really like it. --Trialpears (talk) 23:36, 23 July 2020 (UTC)[reply]
If a merge is not going to happen, then either leave the templates as they are, or redirect the least used with the most used. The least used is aan, the most used is tan, so merge aan to tan. The multilink functionality is available on the talkpage, and can also be accessed via browser history (usually by clicking and holding the back arrow), so losing that wouldn't be as much of an inconvenience as losing the red link to create the next archive. SilkTork (talk) 00:52, 24 July 2020 (UTC)[reply]
The problem with redirecting one to other and then "changing the defaults" is that is what the consensus of the last discussion reached, but it appears that "changing the defaults" is a task that nobody has been willing to undertake for seven years. Is there anyone in this discussion who is able to edit one of the templates so it has the functionality of both? SilkTork (talk) 01:37, 24 July 2020 (UTC)[reply]
I am both willing and able to take care of the implementation. It wasn't completed last time because it was removed from the holding cell without completing the merger. Since it wasn't listed there no one knew about that consensus. --Trialpears (talk) 07:36, 24 July 2020 (UTC)[reply]
No red link if merged (which is why I stated "redirect") ... since in all honesty, redlinks serve to confuse those not trying to create an archive and are not technically savvy with how navigating through Wikipedia works (an editor navigating through the archives clicks on the red link, and could get lost when they have no way to click a link on the page to go back to the previous archive [except using the browser's "back" function, but we can't assume all editors will understand how to do that]), and those attempting to manually create archives should at least have enough competence to put the title of the new archive page into the Wikipedia search bar to locate create the nonexistent page; if an editor doesn't have the aforementioned competencies, they have no business creating talk page archives.Steel1943 (talk) 16:12, 24 July 2020 (UTC) (Strikeouts added for reasons in comment lower in this chain with this timestamp. Steel1943 (talk) 19:59, 31 July 2020 (UTC) )[reply]
...And no, if a merge happens, merge Tan to Aan ... because it's my stance, WP:CCC, and the closer of the previous discussion doesn't have total authority over controlling the outcome of a future discussion. (In fact, if I had paid attention to the previous close 7 years ago and wanted to pursue the following action, I would have questioned the close, and if I did not get an acceptable answer from the closer, I would have taken the discussion to WP:DRV.) Just because a template is used more than another template doesn't de facto make the template more "useful"... and this is definitely such a case where the lesser-used template is more practical in its current state. ... including the omission of the red link to the next archive page as I have stated for reasons in my previous comment.Steel1943 (talk) 16:16, 24 July 2020 (UTC) (Strikeouts added for reasons in comment lower in this chain with this timestamp. Steel1943 (talk) 19:59, 31 July 2020 (UTC) )[reply]
User:Steel1943, do you get involved much in archiving? Losing the red link would make creating new archives more awkward, and for many users who are not familiar with how to create a new archive very awkward indeed. I know I for one would consider the extra work to be not worth it. Your stance on this is really hard to understand. We have red links all over Wikipedia. Are you aware of Wikipedia:Red link? And are you aware that over 60% of users use the back button as their primary means of navigating the net and that it is the second most used means of navigating after hyperlinks. Saying that someone does not understand the back button is like saying that someone doesn't understand a hyperlink. Such is the common use of the back button that websites where you are making a purchase warn users not to use the back button to avoid errors. SilkTork (talk) 15:31, 31 July 2020 (UTC)[reply]
@SilkTork: "User:Steel1943, do you get involved much in archiving?" Yes, and probably more than most editors. For one, User:Steel1943/Orphaned archives is a work list I've been working on off-and-on for the past few years; many of the pages linked on there which still exist are the result of human error ... most being the result of editors not moving subpages correct and/or at all. And I also do a good amount of archive organizing when archives get misplaced; the most recent examples I can think of are archives of Talk:Spore (2008 video game), specifically archives 7, 8, 9, and 10 (and the edit that moved what was formerly at "7" to "11" so the correct "7" could be moved there [I also moved all archived talk pages of Talk:Spore (2008 video game) 7 and over up an additional 4 numbers to move the misplaced archives into their correct locations]) ... pages that were in the wrong location since the auto archiving template wasn't fixed until a considerable amount of time after the parent page was moved. Another example ... on Talk:Halloween, someone who does know how auto archiving templates worked performed this edit in 2015 which changed the archive subpage counter from "14" to "10", breaking the subpage configuration; this error went unnoticed until I discovered this a few weeks ago, and I fixed both the chronology of the archived contents (see 1, 2), and then fixed the auto archive template. (I've done even more complicated examples than these, but I've slept since then, so I'd have to dive through my edits a bit to find them.)
In my aforementioned work, I've found that a good amount of archived talk page issues are caused by ... none other than human error. Allowing these templates to retain the red link allows ... yep, human error. So, regardless of whether or not the percentages and statistics you state are correct ... from my experiences, human error has caused a rather large amount of work to help editors navigate through talk page archives if they so desire. The red links on these templates are a potential source of preventable human error that can easily be removed if they did not exist.Steel1943 (talk) 16:21, 31 July 2020 (UTC) (Strikeouts added for reasons in comment lower in this chain with this timestamp. Steel1943 (talk) 19:59, 31 July 2020 (UTC) )[reply]
Steel1943, is it fair to say that your main concern is that the red link makes it more likely that users inappropriately create archives when the page is automatically archived or are there some other concerns here as well? The auto archiving issue could be solves for the most part usingsome template magic to hide the red link if the last user to edit the page was an archive bot using the ((REVISIONUSER)) magic word. This would mostly alleviate the concern of users creating archives for auto archived pages while retaining the ease of creating new archives for manually archived pages. --Trialpears (talk) 17:28, 31 July 2020 (UTC)[reply]
@Trialpears:"Steel1943, is it fair to say that your main concern is that the red link makes it more likely that users inappropriately create archives when the page is automatically archived or are there some other concerns here as well?" In regards to "...[my] main concern is that the red link makes it more likely that users inappropriately create archives...", yes and no. Yes because I've seen it happen multiple times, and no because I also believe the red links cause navigation issues for users not technically knowledgeable about how Internet browsers work (as I alluded in my comment prior to my response to SilkTork). In regards to "...users inappropriately creat[ing] archives when the page is automatically archived..." I'm honestly not sure if I have an opinion about that, and consider that scenario somewhat unrelated to anything I have stated thus far. I mean, I'm not stating that editors are not capable of archiving a page themselves even when there is auto archiving set up, but I've seen so many cases of editors messing up the archives in scenarios both when auto archiving is set up and when auto archiving is not set up ... which is why I stated that at the minimum, an editor "...should at least have enough competence to put the title of the new archive page into the Wikipedia search bar to locate create the nonexistent [archive] page.". I'm hoping I'm answering your question/concern adequately: Most of my previous statement's purpose is to illustrate how involved I am with the talk page archives, and my main concern is that the red links for future pages cause more trouble than they are worth regardless what their utility may be intended to be. (Also, I'm not familiar with ((REVISIONUSER)), but if it works in the method which you explain, it would no longer function correctly the moment immediately after a non-bot editor edits the page ... which, as you can probably guess, would affect a lot of pages I have edited since I'm not a bot ... so I don't see that being a feasible fix due to the possibility of not functioning as intended if the "newest" archive page was most recently edited by a human for any reason.) Steel1943 (talk) 18:22, 31 July 2020 (UTC) (Strikeouts added for reasons in comment lower in this chain with this timestamp. Steel1943 (talk) 19:59, 31 July 2020 (UTC) )[reply]
I struck out a bunch of my statements above after I had a the following thought: I'm not sure which one of the following has more of a chance for human error ... creating an archive page via a red link, or misspelling and/or not using the proper naming convention/title for the new archive page when creating a new archive page when a red link isn't provided. At this point, I think I'm apathetic about the red link (but still believe the navigation should contain as many links as ((Automatic archive navigator)) contains.) Either way though, I believe the red link should only be viewable/linked when viewing the page titled ".../Archive [-1]" from the redlink's title ... since that seems to be the intent of the red link. Steel1943 (talk) 19:59, 31 July 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus. Relisting comment: I realize there's a clear consensus to merge, but no consensus on which direction. If a general direction isn't garnered here, it will probably be another seven years before this merge is actually complete.
Please add new comments below this notice. Thanks, Primefac (talk) 01:16, 6 August 2020 (UTC)[reply]
Merge all As said, there are too many archive templates. ((3125A|talk)) 13:32, 6 August 2020 (UTC)[reply]
Implementation discussion Alright, as Primefac said in the relist comment there's a clear consensus to merge but currently it looks like we have fourish different proposals on how to do it. I will list the four most prominent options below and give some pros and cons as well as some of my personal opinions below that.
Option 3: Redirect ((aan)) to ((tan)) or vice versa and update the template to have what the community thinks is the best set of options in terms of number of links and whether or not a redlink is displayed. 7 links and displaying the redlink seems the most likely choice if this option was chosen, but further discussion could be started at the talk page if this isn't settled when this discussion is closed.
Option 4: Redirect ((aan)) to ((tan)) or vice versa and update around 50,000 transclusions to ensure the appearance (amount of links given and whether a redlink is displayed) is retained.
Options 1 and 2 are very easy to implement but would change around 50,000 transclusions, possibly for the worse by either forcing all transclusions to either have 7 links and no redlinks or 3 links and redlinks. My personal opinion is that either of these scenarios would be worse than option 4 where we make sure the defaults are what the community considers the best which based on the discussion above doesn't seem to be either of the two current defaults. There is also option 4 which would ensure that the current appearance is maintained, but would require a lot of work to update all the transclusions. It would also not take advantage of the opportunity to apply a better configuration than the current one as almost all of these templates were placed without any thought about which would be the most convenient for readers and probably without the knowledge of potentially better alternatives. For me option 3 looks like a clear winner (disclaimer: I am the main person responsible for making it), but I can definitely see the case for option 4 and initially even advocated for it. I'll ping all previous participants here so we can hopefully get a consensus on the implementation. @NYKevin, Steel1943, Netoholic, Gonnym, Pigsonthewing, Nathan2055, SilkTork, and 3125A: Please excuse me if you already have expressed your preferred implementation, but I would rather avoid this looking like canvassing. --Trialpears (talk) 21:25, 6 August 2020 (UTC)[reply]
@Trialpears: FWIW, I oppose "Option 3" as written, specifically the "... but further discussion could be started at the talk page if this isn't settled when this discussion is closed." part, since trying to collaborate and have more discussion occur after the related TFD is over is partially what reinitiated this merge discussion 7 years after the previous one. At this point, I think it's like a similar saying goes: "What happens in [TFD], stays in [TFD]." Steel1943 (talk) 21:36, 6 August 2020 (UTC)[reply]
...And if the red link needs to be displayed, I strongly believe that it should only be displayed when viewing the page that ends with ".../Archive [-1]" in respect to the red link's title. Steel1943 (talk) 21:39, 6 August 2020 (UTC)[reply]
Steel1943, FWIW we've had follow up discussion after TfDs before such as Template talk:Football squad player#Redesign RfC. The reason this wasn't done was it being removed from the holding cell, not follow up discussion while being in the holding cell. Requiring follow up discussion certainly sounds better than a no consensus close. I also absolutley agree with you about the "/Archive [-1]" thing. --Trialpears (talk) 21:40, 6 August 2020 (UTC)[reply]
Oh wow, that RfC was open for 3 months. I don't have that amount of energy to focus on one discussion (especially a supplemental one) for that period of time; in fact, I was hoping this TFD would have been closed already, considering it had already been open for three weeks prior to the relist, and this discussion is almost like a rerun from 7 years ago of something I started. Whatever controversial aspects of the merge should be discussed can be hashed out here ... since as stated below, there is no guarantee the participants of this discussion will or care to discuss this again on a new talk page. Steel1943 (talk) 23:06, 6 August 2020 (UTC)[reply]
I would prefer options 1 and 2 in that order (i.e. with a very weak preference for 1), followed by option 3 (I share Steel1943's concerns about endless discussions, and also I don't really see the point of having this particular discussion anyway) and option 4 as least preferred (because it would be a lot of work for not much benefit IMHO - most people won't care, and those that do will only need to change a few transclusions each). Of course, if someone else wants to start a discussion after the redirect is complete, I would have no objection to doing that (but I'd probably ignore it, because I don't really care which version ends up "winning"). --NYKevin 21:50, 6 August 2020 (UTC)[reply]
Option 1 preferred, and "weak" Option 3 as a secondary (as long as there is not a need to have more discussion(s) after this TFD, as I stated above). I oppose Option 2 per reasons already explained prior to the relist, and I oppose Option 4 if ((aan)) redirects to ((tan)), but weak oppose Option 4 if ((tan)) redirects to ((aan)) since it creates unnecessary work exclusive from this discussion and updating the template pages themselves. Steel1943 (talk) 22:43, 6 August 2020 (UTC)[reply]
Option 1 - for the amount of default links, that can be changed later in the module. I think the default of one red link for the next page can be beneficial, but since I don't work on fixing red links, I don't know how bad an issue that is for those who do. --Gonnym (talk) 00:45, 7 August 2020 (UTC)[reply]
I'm OK with any option that retains the red link for easier creation of the next archive. I would prefer just a forward and back link as in tan rather than a set up of several links as in aan, but I can live with the multiple links as long as there is a red link to create the next archive. SilkTork (talk) 01:22, 7 August 2020 (UTC)[reply]
Option 1, though Template:Talk archive navigation is a better name. So, I guess "Option 1.5": keep the code of AAN (merge in any feature of TAN that AAN lacks, if the feature is genuinely useful), but use the name of TAN, presumably via a round-robin move. I arrived here because I was about to propose this merge/redirect myself! Weird timing. The features of AAN are better, and it is smarter (it doesn't create a pointless redlink, which in many cases would be red forever, e.g. on the archived talk pages of things that have been merged out of existence and their talk pages moved to archive pages). It just ends up looking like an error, even on pages that will eventually have a follow-on, new archive page. I do not agree with the idea that we should preserve the exact appearance of both templates as options, much less go on some kind of tens-of-thousands-of-pages tweaking spree. That fails WP:ENC and WP:NOT#WEBHOST; we are not here to screw around endlessly in fine-tuning the appearance of navigation widgets (especially not on the basis of "I want to customize my userspace stuff"). The very fact that we have too many of these templates already is the whole point of this TfM. This is very similar to the merger of all the compact-strip table of contents templates (at least 8 of them) into what is now ((CompactToC)) (I would know, since I did most of it.) The same arguments were made to preserve tiny formatting and display variances, and that idea was rejected. We kept the useful functionality of them, and normalized them all to a single, consistent display style. We've done the same with many other clusters of templates. E.g., recent normalization of various "decorative" quotation templates to output the same code as ((Quote)), at least when used in mainspace. Another example is that the entire reason WP:WikiProject Inline templates was created was to give all maintenance/dispute templates of that sort a consistent appearance and code, and merge away the several dozens of duplicative ones. — SMcCandlish☏¢ 😼 11:51, 7 August 2020 (UTC)[reply] PS: I would not object to a parameter for "red link to create the next archive" for use in user_talk space, but it's not appropriate for broader use, in which these pages are generally created by archiver bots, and in which the redlink is more confusing than helpful. — SMcCandlish☏¢ 😼 11:57, 7 August 2020 (UTC)[reply]
A round-robin move isn't necessary, since both templates use the same Lua module, which could be easily updated to include either set of functionality under either name. * Pppery *it has begun... 13:45, 7 August 2020 (UTC)[reply]
Option 1 -per User:Gonnym. ((3125A|talk)) 17:21, 7 August 2020 (UTC)Option 1 most preferred, since my archives use this template, Option 2 is fine for me, but we can also change all the bots to use the preferred option. ((3125A|talk)) 19:15, 8 August 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).