The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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. Plastikspork _―Œ^(talk) 14:41, 22 May 2021 (UTC)[reply]

• Template:Taxonbar databases (talk · history · transclusions · logs · subpages)
• Module:Taxonbar databases (talk · history · transclusions · logs · subpages)

As per Wikipedia:Templates for discussion/Log/2021 April 24#Template:Authority control files. This one at least passes navbox criteron 2, as the articles do mention that they are some kind of database, and doesn't appear to be misused in situations where ((taxonbar)) was intended. However, several of the other concerns brought up in that TfD still apply, including fails of criteria 3 and 5 (brought up by me in the previous nomination) and being too self-referential (brought up by 86.23.109.101 in the previous TfD), and there is the new problem that many of the entries aren't even linked. * Pppery * _{it has begun...} 17:25, 2 May 2021 (UTC)[reply]

• Delete Since the databases included in taxonbars often relate to very different kinds of organism, there's no sensible "See also" use that covers them all, so far as I can see (why would the article at Plants of the World Online put the World Spider Catalog under "See also" or vice versa?). There are circumstances in which a more restricted set might make sense (e.g. a navigation template for plant-related taxonomic databases), but not the whole range available in taxonbars.
  There is a case for templates that extract and display "configuration" information relating to modules and templates, but these are better in Wikipedia space, for use only in purely internal pages, such as template and module documentation (an example for which I am responsible is ((Wikipedia:Automated taxobox system/checked ranks))). So another possibility is to move the template to "WP:Taxonbar databases". Peter coxhead (talk) 09:05, 3 May 2021 (UTC)[reply]

  I don't have any objection to this existing somewhere in Wikipedia namespace, but a list of all supported taxon identifiers is already available at Template:Taxonbar/doc#Taxon identifiers, so I'm not sure what this navbox would add to that. * Pppery * _{it has begun...} 14:20, 3 May 2021 (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(s) or module(s) 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 merge to Template:Infobox organization. Plastikspork _―Œ^(talk) 16:21, 22 May 2021 (UTC)[reply]

• Template:Infobox union (talk · history · transclusions · logs · subpages)
• Template:Infobox organization (talk · history · transclusions · logs · subpages)

Propose merging Template:Infobox union with Template:Infobox organization.
I see no need for this separate union template, as unions are a form of organization and almost all of the parameters are present in the organization template. The organization template is also much more widely used (roughly 30,000 transclusions compared to roughly 2000). Finally, there are also some random issues with the union template which have not been addressed despite comments in the talk page as there seems to be low traffic and not many editors interested in its upkeep (for example, the blue colour at the top of the infobox, despite there being no real link between the colour blue and unions as far as I can tell.) Merging would therefore make maintenance simpler as well. Elshad (talk) 15:58, 2 May 2021 (UTC)[reply]

In principle, this sounds like a good idea. When you say that almost all of the parameters are present in the organization template, are there any which couldn't be mapped across? I think a couple are barely used, but it would be a shame to lose useful information. Warofdreams talk 22:51, 4 May 2021 (UTC)[reply]

The two parameter that Infobox:organization doesn't seem to have are "members" (number of union members) and "head" (leading union of a union federation). Both are pretty important, but that problem could be solved by adding them to Infobox:organization.

Apart from that, I think there is also the question of whether unions are a distinct enough entity that they should have their own template. There are, for example, separate infoboxes for bus companies, companies (much more widely used than organization), universities, fraternities and institutes. If those get their own infoboxes, then I'd say that unions should have one, too. Benefits for distinct infoboxes would obviously be a distinct appearance and fitting parameter names (for example, "Head union" instead of a more vague "Head organization".) Zarasophos (talk) 07:53, 5 May 2021 (UTC)[reply]

There is longstanding acceptance that infobox merger proposals stand or fall on the parameter overlap; it's nothing to do with the significance of their subjects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 14 May 2021 (UTC)[reply]

• Merge per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 14 May 2021 (UTC)[reply]
• Merge provided that it is possible to retain the commonly-used parameters, especially "members", which is particularly important information for trade unions. Warofdreams talk 22:28, 14 May 2021 (UTC)[reply]
• Keep The State of NSW (where I live) is an organisation of a few million people, who conduct their collective affairs efficiently through a representative democractic organisation within the larger organisation that is the State of NSW. These two organisations are also part of a larger organistion, called Australia. The Body Politic of the organisation called Australia is the australian citizens. The Body Corporate of companies registered in this country are commonly refered to as shareholders. all are a form of organistion. as to why 'Trade Union' should retain its own infobox, the following are arguments applicable to australian trade unions, which is what i'm familiar with. I've taken these from the draft templates (or would be missing from the draft templates) of what was considered applicable to trade unions. It is also worth noting that from all the types of infoboxes listed under the generic term 'organisation', 'union' has the highest transclusion count of 1,631 which is twice number of the second highest in category of 'orgnisation' with transclusion count of 885.

Tax ID number The closest would be the ABN, which is used by companies, partnerships, individuals, community organisations, non profit organisations, for profit organisations, and trade unions, in conducting their operations.

Registration number We don’t have registration numbers for trade unions in Australia Companies have an Australian Company Number, or ACN, similar to a registration number. Unions don’t.

Owner The owner of all unions in Australia is the membership. No one else can own a registered trade Union.

Secretary General The key leaders are not always Secretary General (certainly none in Australia) they are either National Secretary, Federal Secretary, General Secretary, Secretary, or CEO. Some prefer to list the President (traditionally elected from the membership, and maintains their primary job) and not the Secretary, who they see as the ‘servant’ of the membership. Others prefer not to list anyone as they like to put the Union members at the top of the list.

Board of directors Unions don’t have a board of directors nor directors on the governing body. Legally trade unions that are federally registered, their governing bodies are the Committee of Management, though under each Union's constitution their Committee of Management is often called something else, like 'Council'. The States of Queensland, South Australia, Western Australia and New South Wales all have separate legal frameworks and government institutions that regulate state based trade unions. A Trade UNion constituted and registered in one jurisdiction is not automatically recognised as a legal entity in other jurisdictions. This has resulted in some very complex, and unique, structures

Motto Is something that is also valuable to a good number of unions and is what they brand themselves with

Successor This is very important as there have been so many amalgamations, transitions and changes to unions that tracking the successor unions is very important

Journal Is very important for many unions in Australia, as it’s their key ‘mouthpiece’ and key mode of communication for many many decades

Key people In Australia, every union is structured differently and is designed according to its constituent members. The “key people” is the best option as it leaves the details on how they’re described up to each Union

Red is used as a traditional “left wing” identification so the infobox should be red in colour. Not all unions are “left wing” but almost all of them are to the left of the current right wing politicians.

https://en.m.wikipedia.org/wiki/Political_colour

Union structure is also unique. Some are single national bodies. Some are ‘split’ into ‘Branches’ along State lines. Others are ‘split’ along occupations or professional lines. Some a combination of both. Some formally ‘split’ even further into workplace divisions.

These ‘splits’ are usually called ‘Division’, ‘Branch’, ‘Group’. The level of independence and autonomy vary significantly. Some operate so independently they are considered separate unions. Others have virtually no independence, while being called the same. None of the subsets are ‘owned’ by the parent. The subsets combined is what forms the parent. BlakeSydney (talk) 06:55, 19 May 2021 (UTC) BlakeSydney (talk) 06:58, 19 May 2021 (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(s) or module(s) 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 redirect to Template:Partly done. Plastikspork _―Œ^(talk) 22:34, 21 May 2021 (UTC)[reply]

• Template:Partly done-t (talk · history · transclusions · logs · subpages)

The template is a text version of ((Partly done)). The latest transclusion I found is from 2016. It has 17 transclusions that are not from ((Done/See also)). I could not find any recent substitutions onto talk pages. The template should be substituted and deleted. Terasail^[✉] 17:32, 3 May 2021 (UTC)[reply]

• Comment: I don't really understand, is the only reason for deleting it that no one uses it? ―JochemvanHees (talk) 22:33, 14 May 2021 (UTC)[reply]
• Merge add a switch to choose whether to use a Unicode character or file graphic checkmark; add the unicode character into the ALT code for the graphic-- 67.70.27.105 (talk) 02:08, 16 May 2021 (UTC)[reply]

  Merge with what? ―Jochem van Hees (talk) 22:21, 16 May 2021 (UTC)[reply]

  • Merge ((Partly done-t)) into ((Partly done)), the duplicate listed in the nomination by the nominator. -- 67.70.27.105 (talk) 06:40, 17 May 2021 (UTC)[reply]

• Delete/Redirect It's just a redundant and worse looking version of ((Partly done)). I would oppose merging this as there's no reason to use it and it would be a significant deviation from the simple structure of all other similar templates. --Trialpears (talk) 23:22, 20 May 2021 (UTC)[reply]
• Delete/Redirect per Trialpears. --Izno (talk) 16:00, 21 May 2021 (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(s) or module(s) 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. Izno (talk) 16:03, 21 May 2021 (UTC)[reply]

• Template:User article&talk ban (talk · history · transclusions · logs · subpages)
• Template:User article ban probation (talk · history · transclusions · logs · subpages)

This is a banner that is supposed to go on article talk pages judging from the categories informing users a user has been banned from editing an article before page blocks were a thing. Judging from this search the banner has basically never been used and is completely irrelevant now a days. --Trialpears (talk) 15:56, 5 May 2021 (UTC)[reply]

• I found ((User article ban probation)) as well which I will add. Basically identical and the same rationale applies. Another uneventful search. --Trialpears (talk) 20:51, 5 May 2021 (UTC)[reply]

• Delete per nom. CanadianOtaku ^{Talk Page} 14:49, 16 May 2021 (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(s) or module(s) 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 merge to Template:Talk header. A significant portion of editors agreed that ((Auto archiving notice)) was (in general) superfluous to other existing templates, including the merge target ((talk header)) as well as ((archives)). The target template can be modified in a way that does not include its visual size on the page. The primary replacement concern (from both sides) seemed to be pages where ((talk header)) is not currently present (in particular, user talk pages). The solution most often presented was for those instances to have ((auto archiving notice)) replaced by ((archives)) due to the this-is-only-for-archives (and to a lesser extent, this-is-not-a-banner) functionality. Obviously for user talk pages they will be able to decide (after having the template replaced) which template they wish to use, and any contentious changes elsewhere should be discussed at that page. Primefac (talk) 21:21, 3 June 2021 (UTC)[reply]

• Template:Auto archiving notice (talk · history · transclusions · logs · subpages)
• Template:Talk header (talk · history · transclusions · logs · subpages)

Propose merging Template:Auto archiving notice with Template:Talk header.
This nomination is part of an ongoing effort to consolidate and simplify talk page banners to combat banner blindness. Kudos are due to Aza24 and several others for helping prompt it. ((Auto archiving notice)) has existed since 2007, and it is a good candidate for merging (1) because it uses an entire banner to communicate what is really only one piece of important information, the auto-archiving period; and (2) because that piece of information would be fully appropriate in ((Talk header)), so there is a ready merge destination. A mockup of what these would look like merged can be viewed here at the talk header testcases page. It's not fully functional yet, but the final implementation can be completed subsequent to this nomination. The new design highlights the period (e.g. "7 days") while moving other less important information (e.g. the bot doing the archiving) to the tooltip, where it can still be viewed by any editor who cares about the details or is unfamiliar with auto-archiving and wants to figure out what it is. Nearly all of the 9700 pages with the auto archiving banner already have a talk header, and for any remainder it should not be a problem to add it as all pages with auto-archiving have at least moderate traffic. Once completed, this merge will mark a solid step in our efforts to reduce the distracting clutter at the top of so many talk pages, helping draw editors' attention to the most important information instead. ((u|Sdkb)) ^talk 21:57, 13 May 2021 (UTC)[reply]

• Support—when I see things like this, it becomes clear that it is too easy, and too often that we clutter the talk page to the point where important notices (arbitration, controversial etc.) are completely indiscernible. Here is a step in the right direction. This solution allows the notice to preserve the information, but minimizes any distracting or space-taking qualities. Aza24 (talk) 22:51, 13 May 2021 (UTC)[reply]
• Support. I don't have much to add other than that maybe there should also be |archive_bot= parameter to match the parameter of the ((Auto archiving notice)) template. ―JochemvanHees (talk) 22:54, 13 May 2021 (UTC)[reply]

  Actually, merge but don't delete. As others have pointed out, ((Auto archiving notice)) can still be useful in some situations, although it shouldn't be used if there is already a ((Talk header)). ―Jochem van Hees (talk) 11:33, 3 June 2021 (UTC)[reply]

• Support reasonable merge. No reason to have a separate banner for this. Elli (talk | contribs) 23:00, 13 May 2021 (UTC) On second thought, weak oppose. Elli (talk | contribs) 00:18, 14 May 2021 (UTC)[reply]
• Support makes things way simpler, plus the Talk header banner already has an archive index --Aknell4 (talk • contribs) 23:26, 13 May 2021 (UTC)[reply]
• Support ((Talk header)) will have to be added to a significant amount of talk pages but I don't see an issue with that. On the other hand there are many places where ((Archives)) is used to display the archive list and talk header would be redundant in that case. Would removal of ((Archives)) be the solution in those cases? --Trialpears (talk) 23:33, 13 May 2021 (UTC)[reply]

  Hell no. Consider the use of ((Archives)) and ((Auto archiving notice)) on user talk pages, where ((Talk header)) is unwanted. Hawkeye7 (discuss) 23:40, 13 May 2021 (UTC)[reply]

  Given that talk headers are the by-far de facto standard for active talk pages, I find it extremely unlikely that talk pages that warrant automatic archiving would not warrant a talk header. Aza24 (talk) 19:52, 15 May 2021 (UTC)[reply]

  I second Aza24 in that pages which have automatic archiving almost certainly need Template:Talk header as well. I deliberately chose to use it on my user talk page. Frankly, I didn't know about Template:Auto archiving notice until this discussion, and it would be good for Template:Talk header to include this. Bibeyjj (talk) 22:59, 19 May 2021 (UTC)[reply]

• Oppose These have nothing to do with each other. Bad programming practice to have multiple unrelated functions in the same code. Also: the test cases indicate an error; an archive box is displaying when there are no archives. Remove the archive box from the talk header template instead. Hawkeye7 (discuss) 23:37, 13 May 2021 (UTC)[reply]

  Hawkeye7, the talk header template already contains a bunch of different functions. Programming exists to serve users, not vice versa, and the best result for users is to not have an entirely separate box for just the one piece of auto archiving information. We can structure the underlying programming however we want, but that should be the end result.

  Re the test cases error, I'm not quite understanding what you're referring to, but the prototype is just a prototype, not something that's supposed to be fully functional. ((u|Sdkb)) ^talk 02:56, 14 May 2021 (UTC)[reply]

• Weak Oppose: I do think these templates should be merged and it is important to condense talk page banners (see: Template:Banner holder), but I don't like the example provided; I think the example's archive text is too difficult to see at a glance due to text-clutter in Header box. Curbon7 (talk) 00:41, 14 May 2021 (UTC)[reply]
• Oppose per Hawkeye7; not all pages that have archives are talk pages. Some of them have discussions on the base namespace page instead. Talkheader is not designed for user talk pages, since it is not about discussion of editing the userpage. -- 67.70.27.105 (talk) 01:45, 14 May 2021 (UTC)[reply]

  Looking at the list of those pages, all of them do include the ((Archives)) template. Perhaps ((Auto archiving notice)) could be merged into that one as well? ―JochemvanHees (talk) 16:55, 14 May 2021 (UTC)[reply]

  • That seems to make more sense. Archive templates merging with archive templates and not talkpage notice banners. -- 67.70.27.105 (talk) 01:48, 16 May 2021 (UTC)[reply]

    Well my suggestion is to merge it into both. Adding ((Archives)) to all pages that have archives doesn't solve anything. ―Jochem van Hees (talk) 22:35, 16 May 2021 (UTC)[reply]

  @Sdkb: is it an idea to add ((Archives)) to this TfD? ―Jochem van Hees (talk) 22:33, 16 May 2021 (UTC)[reply]

  Jochem van Hees, looking at the way this is going, I think the likely outcome is that for pages with ((talk header)) it'll be merged into that, and for pages with ((archives)) it'll be merged into that. This TfD should not be about the debate that seems to exist over where archives should go; it'd be a lot better to just agree we should get rid of auto archiving notice and then have a separate discussion to let the talk header and archives partisans battle it out in a dedicated space. ((u|Sdkb)) ^talk 04:58, 17 May 2021 (UTC)[reply]

• Oppose. I would support if these were joined in main space. However not all uses of the archive notice are in mainspace which results in the unnecessary inclusion of the talk page header (e.g. in user space, project space etc.), contributing to template clutter. So I do not support a merge at present. Tom (LT) (talk) 02:14, 14 May 2021 (UTC)[reply]

  Tom (LT), the total number of transclusions of the auto archiving notice in WP-space is currently only seven. It would be an utter shame to have this nomination regarding thousands of pages be foiled by such a tiny edge case. But it's true we can't just ignore it, so here's what I'd propose. First, let this go through, handling all the existing talkspace transclusions. Then, create a new template based on the existing ((Auto archiving notice)) code for use exclusively in non-talk spaces and which displays a warning/error if used in talkspace. That niche template could be applied to the seven project-space pages, taking care of their needs. Does that sound alright? ((u|Sdkb)) ^talk 03:08, 14 May 2021 (UTC)[reply]

  We could do that, but it would defeat the whole purpose of the exercise, which is to reduce the number of templates in use. Hawkeye7 (discuss) 05:26, 14 May 2021 (UTC)[reply]

  @Sdkb There are hundreds of translcusions in user talk space. ~~~~
  User:1234qwer1234qwer4 (talk) 15:18, 22 May 2021 (UTC)[reply]

  @Sdkb Do you mean by "non-talk spaces" all namespaces but namespace 1 or just all the even namespaces? I support this if my first assumption is correct. ~~~~
  User:1234qwer1234qwer4 (talk) 10:38, 25 May 2021 (UTC)[reply]

  I think users should have greater flexibility in their own space, so if allowing the successor template to be used in user talkspace would help, that's fine by me. I'd want it kept out of all the other talk spaces, though. ((u|Sdkb)) ^talk 19:17, 25 May 2021 (UTC)[reply]

• Support If it'll get rid of unnecessary clutter, I'm in. ~ HAL333 02:22, 14 May 2021 (UTC)[reply]
• Support. I think that consolidating these things is a really good thing. It condenses the information in a solid way. I also feel the same way Aza24 does, where there exist too many talk page notification templates that you just... glaze over the important info. SWinxy (talk) 02:26, 14 May 2021 (UTC)[reply]
• Support adding the functionality of ((Auto archiving notice)) to ((Talk header)). It will enhance transparency for readers and save the extra step of adding the notice manually. But keep separate ((Auto archiving notice)) template for talk pages that don't use ((Talk header)) for some reason, as is done with ((Archives)). Many talk pages use both ((Talk header)) and ((Archives)) redundantly. I make the effort to reduce such clutter manually when I see it. I think the same can happen in this case.--Sangdeboeuf (talk) 03:55, 14 May 2021 (UTC)[reply]
  • Re: the proposed template layout: I think it would be simplest to copy the existing output of ((Auto archiving notice)) onto a new line inside the yellow area, below the search bar. That should also ease any shock to users who are used to the current setup. --Sangdeboeuf (talk) 04:02, 14 May 2021 (UTC)[reply]

    I'd prefer not to create the possibility of redundant usage, as has happened with archives—there are quite enough gnoming tasks available already without us adding to the pile. ((u|Sdkb)) ^talk 04:26, 14 May 2021 (UTC)[reply]

• Correct and delete. Agreed with the sentiment that it is redundant and belongs nearest the archives search bar. However if the intent is to reduce banner blindness, I think this loses the forest for the tree: Start discouraging the bloated, unhelpful, and overused ((talk header)) if you want to reduce blindness. I'd wager that users more often look for an ((archives)) box (nearest the text) than they find the archives search box buried beneath all the talk header banners. It'd be nice if there was some usability testing to this effect. So, yes, merge this banner notice's info into any relevant template with a search bar but don't lose sight of the actual root problem—use the existing archive search template on each talk page and don't just slap a ((talk header)) on each of those articles if it's not already there. (not watching, please ((ping))) czar 04:53, 14 May 2021 (UTC)[reply]
• Support these two definitely could do with being together to make talk pages smoother --K. Peake 07:18, 14 May 2021 (UTC)[reply]
• Support replacing uses on mainspace talk pages but oppose full merging. I see this as a benefit for compacting banners, but replacing uses of ((Auto archiving notice)) should only occur once all behavior (including specifying the bot) can be copied over. I oppose replacing all uses of ((Auto archiving notice)) with ((Talk header)) automatically, but do support automatic replacement on mainspace talk pages only. I'd also support making ((Auto archiving notice)) usable only on non-talk pages and user talk pages, with a warning if it is used elsewhere. This would ensure that users can keep their usages on their talk pages and ensure that ((Talk header)) is not needed on non-talk pages. As such I oppose a full merge, as I would want to see this template be kept but limited to non-talk pages and user talk pages, but support replacing uses selectively. Dreamy Jazz ^{talk to me | my contributions} 09:39, 14 May 2021 (UTC)[reply]
  • ^Support this (my second choice would be a simple merge as proposed). I completely support the goal of merging these templates for mainspace talk pages, which will help improve the stated problem of cluttered talkpages/banner blindness. However, there's no reason to take away ((Auto archiving notice)) if users/projects prefer to use it on their own talk pages. -M.Nelson (talk) 22:34, 14 May 2021 (UTC)[reply]
• Oppose for now: The nominator does not even mention the functionality of ((Archives))! The statement that piece of information would be fully appropriate in Talk header, so there is a ready merge destination is demonstrably erroneous. Is this a back-door way of implementing everything into one mega talk header? I nominally support the idea to reduce clutter, and arguably Auto archiving notice is redundant, but this seems to rush head-long into a second, bigger headache. Please first fully resolve which functionality is to be served where, and make sure each such place (such as Talk header or Archives or perhaps other related templates) fully 100% supports every parameter. The problem of not being able to easily copy across all parameters from one place to another is definitely a bigger problem than talk header clutter. Know why? Because clutter can be fixed on those pages where editors see it as a problem. As I said, I don't dislike the core idea, it's just that this proposal is limited and incomplete. I will probably change my not-a-vote once the nominator expands the proposal to take the above into account. CapnZapp (talk) 10:31, 14 May 2021 (UTC)[reply]

  The parameters currently used at ((auto archiving notice)) are |age=, |bot=, |botlink=, |dounreplied=, |index=, |page=, |small=, |target= and |units=. |small= is obviously not applicable for ((talk header)), archive index links are already given in the lists of archives (for some reason it can't be manually specified though which should be fixed), target is once again unnecessary since the list of archives is given. The functionality described with |dounreplied=no is not used by the bots anymore and should be removed. |page= is barely used but |display_title= fills the same role for talk header if I am implementing this merger these would be dealt with manually. |botlink= can be used to link somewhere other than the bots user page. This isn't desirable for the current bots but was at times used to link User:Werdnabot/Archiver/Howto instead of User:Werdnabot or User:MiszaBot/Archive HowTo instead of User:MiszaBot. A merger is a prime oppurtunity to make sure the bot parameters actually are correct and would fix the remaining uses of obsolete bots being specified. Worth noting though that the current suggested implementation does not have a link to the bots userpage which I think is fine. That leaves the most important parameters: |age=, |bot=, and |unit=. These currently have an "archive_" prefix in the sandbox version, but I've also added the old names as aliases for backwards compatibility. I hope that satisfies the parameter part of the comment at least. --Trialpears (talk) 13:23, 14 May 2021 (UTC)[reply]

Trialpears: First off, please don't bring parameter support into this discussion. If you wish to merge two templates, fine. If you wish to add support for new parameters or remove obsolete ones, fine. But don't conflate one discussion into the other - that just allows editors to sneak in changes under the cover of support not-votes for a different thing. Second, you too talk as if ((Archives)) doesn't exist - when there are parameters implemented there that has not (yet) reached Auto archiving notice; it is going about it the wrong way to add incomplete functionality to Talk header. CapnZapp (talk) 11:33, 15 May 2021 (UTC)[reply]

CapnZapp My impression was that you wanted to know exactly how all relevant parameters were to be handled. (Please first fully resolve which functionality is to be served where, and make sure each such place (such as Talk header or Archives or perhaps other related templates) fully 100% supports every parameter.) My intention was to give a full rundown of all parameters that are used in ((Auto archiving notice)) to make sure that ((talk header)) 100% supports every parameter when warranted. I did forget about ((Archives)) though (thanks for telling me!) which does have |minthreadsleft= which should be incorporated into ((auto archiving notice)) and ((talk header)). I have now done this in the sandboxes.

I would usually take discussions about implementation details like this after the TfD was closed pausing to make sure that changes have consensus if anyone raises queries or objections, but my impression of your comment was that you wanted to start such a discussion now. --Trialpears (talk) 12:28, 15 May 2021 (UTC)[reply]

• Support In my opinion, they can be merged and it'll look a lot better. --Vacant0 (talk) 11:38, 14 May 2021 (UTC)[reply]
• Support merging. Auto archiving notices are extremely niche, and they don't deserve an entire banner for themselves. For the editors that still need them, they're still here, just not taking up a sizable percentage of screen real-estate now. JackFromWisconsin (talk | contribs) 13:02, 14 May 2021 (UTC)[reply]
• Merge per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 14 May 2021 (UTC)[reply]

  Just FYI, this is not a vote. ―JochemvanHees (talk) 22:24, 14 May 2021 (UTC)[reply]

  JochemvanHees, there's nothing wrong with "per nom" !votes. They're a lot better than !votes that make redundant points and cause discussions to spiral to extreme unreadable lengths. ((u|Sdkb)) ^talk 02:59, 15 May 2021 (UTC)[reply]

  Sdkb As an alternative take, yes, there's something wrong with "per nom" !votes, precisely because they literally just add +1 to something that isn't supposed to be a vote tally. Which is exactly what the linked essay explained. You are obviously free to argue these discussions should be counting votes for/against the proposal, which is what you are effectively saying when you say there's nothing wrong with "per nom" votes. Just an observation. Cheers CapnZapp (talk) 11:43, 15 May 2021 (UTC)[reply]

• Oh, I just remembered that there was some prior discussion here as well, so linking that for completeness, and courtesy pinging Terasail, the only editor who commented there but hasn't yet here. ((u|Sdkb)) ^talk 17:36, 14 May 2021 (UTC)[reply]
• Support pr nom and Aza24 example is the reason why. MarioSoulTruthFan (talk) 18:41, 14 May 2021 (UTC)[reply]
• Support with adding a link to the archive bot page. Funandtrvl (talk) 20:04, 14 May 2021 (UTC)[reply]
• Comment. Could I get a precise description of how ((Auto archiving notice)) would be merged in the following talk page situations? You can fill in the blanks, if you like.

1. Only ((Talk header)) exists:
2. Only ((Archives)) exists:
3. Both ((Talk header)) and ((Archives)) exist:

— Goszei (talk) 00:45, 15 May 2021 (UTC)^{I refactored to add numbers, hope you don't mind. ((u|Sdkb)) talk}[reply]

For (1), we'd move the information to display through talk header rather than the present banner, as displayed in the testcases. For (3), if there's redundancy (i.e. two archives boxes), we'd probably want to fix that by removing ((Archives)). If there's not redundancy, or for (2), that's trickier. Of the roughly 9700 pages with auto-archiving notice, roughly 1400 don't have talk header; choosing randomly from the list, Talk:Naples is representative. Speaking just personally (not characterizing the nom), I'd say that since every page with auto-archiving is at least mediumly-high traffic, it'd be fine for them to have talk header—it's a very useful template for newcomers, particularly the "for discussing improvements to" line which clarifies WP:NOTFORUM. But I see that some editors oppose having talk header on some pages, and the aim here is certainly not to force talk header on pages that don't want it. So we could easily decide to just have ((Archives)) handle the display of the auto archiving period for those pages. ((u|Sdkb)) ^talk 02:26, 15 May 2021 (UTC)[reply]

For (3) no we most definitely do not. There are editors trying to move bot param info out of Talk header and into Archives precisely because that is what saves space (since Archives can float to the right of the TOC). Best regards, CapnZapp (talk) 11:37, 15 May 2021 (UTC)[reply]

If I understand correctly, the point is not to take up less space, but to reduce the number of boxes right? ―Jochem van Hees (talk) 22:17, 16 May 2021 (UTC)[reply]

Support. I support the initiative as proposed, and hope it is the beginning of a larger talk page cleaning initiative. — Goszei (talk) 21:42, 26 May 2021 (UTC)[reply]

• Weak support because there are circumstances under which one would prefer using solely Auto archiving notice w/o Talkheader. A good idea would be to implement the features of Auto archiving notice into Talkheader and use that as a default, instead of merging them altogther. Casspedia (talk) 09:55, 15 May 2021 (UTC)[reply]
• Support The proposed new design makes a lot of sense, and helps cut down on the clutter substantially. Though effectively, this is adding functionality to ((Talk header)) and then ((Archives)) would be deprecated. — The Hand That Feeds You:^Bite 14:20, 15 May 2021 (UTC)[reply]
• Support No comment.StarshipSLS (Talk), (My Contributions) 14:42, 15 May 2021 (UTC)[reply]
• Oppose It's a very bad idea to merge templates simply because they are commonly - but not always - used in the same articles and pages when the two templates serve very different functions. This will not make things easier for readers and editors; it will make them worse. ElKevbo (talk) 17:05, 15 May 2021 (UTC)[reply]

  ElKevbo, I mostly agree with you in theory. For archiving, we're trying to wrangle a situation that is very far from the ideal. For starters, we have multiple auto-archiving bots, rather than just one. Adding on to that, the actual auto-archiving instructions are not in ((Auto archiving notice)), they're in either User:MiszaBot/config or User:ClueBot III/ArchiveThis; the notice is just a notice that is (hopefully) synced with the actual instructions. Hopefully someday we'll get to a point where we have a single template that both includes the instructions for the bot and displays the configuration at ((Talk header)) or ((Archives)) or elsewhere as appropriate. But for now, getting rid of the separate banner will be a step forward in terms of end display to users, and we'll still be able to pursue the ultimate end goal. ((u|Sdkb)) ^talk 19:27, 15 May 2021 (UTC)[reply]

• Oppose Talk header is used on many pages that don't use archiving, in addition the archiving template deletes the functionality of the header. Starspotter (talk) 17:45, 15 May 2021 (UTC)[reply]

  Starspotter, for pages that use talk header but don't auto-archive, they simply wouldn't add the relevant parameters and the header would display without any "auto-archiving period" notice. I'm not sure what you're referring to by "deletes the functionality", so you'd have to clarify. ((u|Sdkb)) ^talk 19:15, 15 May 2021 (UTC)[reply]

  Ok thanks for explaining. Starspotter (talk) 19:19, 15 May 2021 (UTC)[reply]

• Support, having this would make articles/talk pages less clunky and full. creamepuff 🏹 (talk • contributions) 02:07, 16 May 2021 (UTC)[reply]
• Support per nom and others, maybe this is the start of a talk page de-cluttering movement. CanadianOtaku ^{Talk Page} 14:44, 16 May 2021 (UTC)[reply]
• Oppose. I think the archiving ought to be split out of the talk header. The talk header is meant to provide help concerning talk page guidelines. --Bsherr (talk) 02:44, 17 May 2021 (UTC)[reply]

Merge with ((archives)) - Merging is the right idea, but to the wrong target. The talk page notice and the archive notice serve completely different purposes. Instead, add the notice text to ((archives)) Oiyarbepsy (talk) 04:35, 17 May 2021 (UTC)[reply]

• Oppose - There is a saying, if it ain’t broke don’t fix it. Here is such a case. This move would serve no purpose and would make it more difficult for editors rather than the opposite way around.BabbaQ (talk) 08:06, 17 May 2021 (UTC)[reply]

  I think the nominator explained why it is "broke" and does serve a purpose? Currently the box is part of a larger problem, namely banner blindness. ―Jochem van Hees (talk) 13:36, 17 May 2021 (UTC)[reply]

• Support Consolodating information so that all relevant parts of archive information are less spread across multiple banners is an advantage, reducing the spread of related information being seperated on a page. Terasail^[✉] 13:02, 17 May 2021 (UTC)[reply]
• Support the consolidation per the original rationale. An actual merge is probably not the solution, since pages that currently have both will need one removed, and there's probably these edge cases that require the current archive notice. The arguments about programming good practices have nothing to do with the UX. A subtemplate or submodule can be used where needed to modularize the code, that's a choice separate from the desired user interface. MarioGom (talk) 13:19, 17 May 2021 (UTC)[reply]
• Strongly oppose Auto archiving notice are majoritively not placed directly below talk header. Talk page that I have visited that following such format: talk header, deletion/translation/merger templates, wikiprojects, then archiving notice. In addition, I don't see why there is a need to merge either when it isn't broken. — Paper9oll (🔔 • 📝) 04:25, 18 May 2021 (UTC)[reply]
• Strongly support adding It would be great to have the duration of the archive (and maybe the minimum threads) in the talk header instead. Balon Greyjoy (talk) 15:34, 18 May 2021 (UTC)[reply]

  It looks like auto archiving notice doesn't actually handle any display of minimum thread settings, which is a little odd as that's actually useful information that we probably want to appear. It could be expressed succinctly within talk header, such as: Auto-archiving period: 7 days^{min: 4}. ((u|Sdkb)) ^talk 21:44, 20 May 2021 (UTC)[reply]

• Oppose per Hawkeye.   ~ Tom.Reding (talk ⋅dgaf)  10:27, 19 May 2021 (UTC)[reply]
• Support removes clutter and folds in well, per the sandbox. ProcSock (talk) 11:08, 19 May 2021 (UTC)[reply]
• Oppose - I don't agree with the "banner blindness" hypothesis as presented. Jusdafax (talk) 11:52, 19 May 2021 (UTC)[reply]
• Support, as a clear case for consolidation has been given. This would simplify the use of talk page templates. The test cases seen like a reasonable adjustment to Template:Talk header. Bibeyjj (talk) 22:43, 19 May 2021 (UTC)[reply]
• Support, if it cleans up and makes things easier, I'm in. ☎️ Churot ^DancePop 04:59, 20 May 2021 (UTC)[reply]
• Support; I've always thought Template:Talk header felt like clutter. Anything that can reduce the clutter without removing the benefits that some users find from the banner seems like a good idea. — OwenBlacker (he/him; Talk; please ((ping)) me in replies) 20:45, 20 May 2021 (UTC)[reply]
• Support per above. Reduces maintenance overhead and confusion, net positive. Reviewed the oppose !votes when deciding how to !vote myself and found them to be incredibly unconvincing. -FASTILY 22:03, 20 May 2021 (UTC)[reply]
• Support. ((Talk header)) is a great template that combines many common talk page banners. Adding ((Auto archiving notice))'s information to it (and impressively, in a way that does not increase its size) seems like a good improvement. I looked at the mock ups and they look good. Good idea all around. –Novem Linguae (talk) 06:22, 21 May 2021 (UTC)[reply]
• Support. Sure, add the ((Auto archiving notice)) functionality to ((Talk header)) so that the separate template may be removed from the 580K pages using ((Talk header)) – but don't require pages with only the ((Auto archiving notice)) to add ((Talk header)) clutter. The archiving templates aren't the problem causing banner blindness. It's all the boilerplate policy&guideline links anyone who's been around for more than a month should be familiar with that's causing blindness. wbm1058 (talk) 19:05, 22 May 2021 (UTC)[reply]

  Oddly enough after searching the more limited ((Auto archiving notice)) usage (<10K pages), I had trouble finding a single page where ((Talk header)) wasn't used. But I did find pages where ((Auto archiving notice)) was colllapsed under an Other talk page banners heading. So, counterintuitively, merging will make it more visible. It would be nice to have all info regarding archives residing in the same neighborhood of Talk Banner City. So, supporting without qualification. wbm1058 (talk) 19:25, 22 May 2021 (UTC)[reply]

  @Sdkb: So here is where I see an issue: e.g. Talk:Satan. It has an ((Archives)) box, which is in the same neighborhood as ((Auto archiving notice)). Can you also merge the same look into this template as well? This may be needed for pages that have ((Archives)) but not ((Talk header)); I think any redundancy is harmless. Also can you retain the blue link to User:lowercase sigmabot III, which leads to the instructions. wbm1058 (talk) 20:25, 22 May 2021 (UTC)[reply]

  I spoke to how we could handle pages like Talk:Satan in some other replies; in short, yes, that's an option.

  Regarding retaining the blue link, it'd be nice to find some way to do that, but the mixture of link and tooltip as with your edit here looks pretty odd to me and may make it harder for casual readers to find the info in the tooltip. So I'd prefer to have just the tooltip—editors advanced enough to want to adjust talk page archiving settings are also likely advanced enough to know how to find it. My second choice would be to have something like this, with a link over a question mark: Auto-archiving period: 7 days (?). ((u|Sdkb)) ^talk 06:19, 29 May 2021 (UTC)[reply]

• Weak support: I think consolidation is worth it, at least in some namespaces. (Side comment: It might be worth it to display information about the archiving period when archives don't yet exist, if the archive period is set up, though.) - Purplewowies (talk) 00:13, 23 May 2021 (UTC)[reply]
• Support - This is a good incremental improvement to a mishmash of archive notices. ~Kvng (talk) 13:25, 24 May 2021 (UTC)[reply]
• Support the mockup looks great. Talk page headers are already overwhelmed, so this is a good improvement. Thanks for working on this. Legoktm (talk) 17:14, 24 May 2021 (UTC)[reply]
• Support per nom. Thrakkx (talk) 21:40, 24 May 2021 (UTC)[reply]
• Support per nom, specifically Sdkb's solution "First, let this go through, handling all the existing talkspace transclusions. Then, create a new template based on the existing ((Auto archiving notice)) code for use exclusively in non-talk spaces and which displays a warning/error if used in talkspace. That niche template could be applied to the seven project-space pages, taking care of their needs." GeraldWL 03:02, 25 May 2021 (UTC)[reply]
• Support in mainspace per the above discussion. ~~~~
  User:1234qwer1234qwer4 (talk) 10:35, 25 May 2021 (UTC)[reply]
• Oppose Please can we avoid this move towards the all singing all dancing ((talk header)). I understand that some people are disgruntled with visitors to high traffic talk pages being met with a screen and a half of templates but these moves are going to end up meaning that pages that need one or two templates (perhaps a small page needing a find source template) will have to opt for the massive talk header that seems to be on course to take up a screen of space itself. This expands the size of talk header (even the ones without an archive list incorporate a large 'search archives' box) - the poposers mention that almost all of the pages with auto archiving notice also feature talk header, but what of vice versa? Indeed Auto archiving notice can display as a small box on the right hand side where it is barely noticeable. ~ El D. (talk to me) 11:50, 25 May 2021 (UTC)[reply]

  If there are no archives then that archives search box should indeed not be there, but you can fix that with the parameters. Also, if you look at the testcases, this change also doesn't make the archives part of the talk header any larger than it is now. ―Jochem van Hees (talk) 12:15, 25 May 2021 (UTC)[reply]

• Super Strong Support - per nom Ian9087 (talk) 21:16, 25 May 2021 (UTC)[reply]
• Weak Oppose - This seems like aggregation of functionality for no real benefit or functional sense. I'm all for the reduction of banners on talk pages, but this seems like a bad way to go about it. Better solutions would include: Adopting better policies and guidelines for the banners, when they're added, their size and format, etc; more use of editnotices for things that appear on many talk pages; better coding and component templates to make things merge better naturally. The problem is nobody agrees on the specifics, so consensus never evolves. Trying to get it done via merging into a talkheader that does everything seems like a broken approach to a broken situation. All that said, I don't feel that strongly about it. (Full disclosure: I've edited heavily on the talkheader template in the past.) —DragonHawk (talk|hist) 23:35, 25 May 2021 (UTC)[reply]
•  Support: Per nom, as well as the fact that merging these templates would significantly de-clutter the top of talk pages, particularly if there is important discussion going on on said talk pages. Also, as an aside, I do use the talk header template on my talk page, but I don't use Auto archiving notice because I feel it would clutter my talk page. Merging these two templates here would be quite helpful. --DL6443 (^Talk/_Contribs) 00:52, 26 May 2021 (UTC)[reply]
• Support - Banner blindness, indeed. Schierbecker (talk) 06:47, 26 May 2021 (UTC)[reply]
• Yes. This is an elegant solution in the best traditions of Wikipedia. It's good to see that some attention is being given to identifying and addressing such issues. SilkTork (talk) 09:03, 26 May 2021 (UTC)[reply]
• The example displayed at Special:Permalink/1023267364#Plain is a very elegant way to display the needed information while reducing the amount of banner messages on the page, both in the discussion page's source code and in the visible output. "Auto-archiving period: 7 days" – that's all we need. There is no need for the current full-size auto archival notice if this elegant way exists to convey the same information. ~ ToBeFree (talk) 21:00, 27 May 2021 (UTC)[reply]
  • Taking a second look, I too think that's the best and simplest option for readers. No extra space needed (unless the number of archives gets really big). —Sangdeboeuf (talk) 18:29, 28 May 2021 (UTC)[reply]
• Strong support - talk page banners need drastic reductions - really an information page should hold nearly all the crap - talk pages are for talking about the article. ɱ (talk) 22:43, 28 May 2021 (UTC)[reply]
• Oppose. I joined WP just over 6 months ago, and that auto-archiving notice was really helpful. Otherwise, if you leave a topic for a few days and it suddenly gets archived, it implies to a new user that the discussion was decided to be unimportant. If you don't know that a lot of small Wikipedia functions run off bots, it seems like it was a deliberate choice. It would deter me from re-opening that discussion, because it's hard to tell what constitutes consensus in WP and for all I knew, that could count. Although, it would be useful if the auto-archiving notice and the list of archives were in the same place - I would prefer that the list was placed under the notice rather than the notice moved into the header. Because honestly, to me the talk header was the clutter. I did also have a comment on the example header, this obviously isn't part of my actual response to the TfD, but feedback in case it does get used. The note about auto-archiving likely wouldn't get noticed by new editors, and even if it was, the bot's documentation would've been confused me. The owner of it refers to it archiving on their behalf, which really would've reinforced the idea that it was a choice by a person to archive that topic. --Xurizuri (talk) 03:13, 30 May 2021 (UTC)[reply]
• Support per Hal333. I was initially opposed but I believe this move makes sense. Sean Stephens (talk) 12:52, 30 May 2021 (UTC)[reply]
• Support with a single proviso: there's a tooltip thing on the word "period" in the new 'archives' section that mentions the name of the bot that will do the archiving. Can we change that to something like 'an automated account' or 'by a bot' or something? That would be more useful for new editors, who don't know who or what a lowercase sigmabot III (or whatever) is; and, less of an issue, it would save a server hit if we ever got a different bot or process to do the archiving and had to change the template again. ◦ Trey Maturin 20:50, 30 May 2021 (UTC)[reply]

  I hope that the word "automated" in the tooltip will communicate that it's not a human doing the archiving, even if new users won't know what lowercase sigmabot is. Some experienced editors may care which bot is doing the archiving because they have slightly different behavior (and ultimately, I hope that someday we merge them into a single ArchiveBot). ((u|Sdkb)) ^talk 01:04, 31 May 2021 (UTC)[reply]

• Support per nom.--Vulphere 12:20, 31 May 2021 (UTC)[reply]
• Support Per nom as it seems like a sensible move.Jackattack1597 (talk) 15:21, 31 May 2021 (UTC)[reply]
• For mainspace talk only, I support adding the functionality of ((auto archiving notice)) into ((talk header)) - it nicely does the purported job of reducing the number of banners in place on talk pages. However, I fairly strongly oppose removing ((auto archiving notice)) entirely; there are many usages of this template in places where ((talk header)) isn't the most ideal - user talk pages being the main one I'm thinking of. stwalkerster (talk) 23:35, 1 June 2021 (UTC)[reply]
• Oppose: I do not support this decision. It ignores that many people who use ((talkheader)) — if not most Wikipedians — are not technical, we are first and foremost editors. We place ((talkheader)) atop talkpages across all talkspaces simply to identify those pages as such for other editors, as well as to briefly present the etiquette of talkpages. Nothing more. We don’t avert to archiving, if we even know what that means. As it currently stands, it takes a matter of seconds to prepend to the top of a talkpage the ((talkheader)) template, save it, and move on. That’s how it should remain. For editors, talkpages are the forums where we discuss editorial matters. When and how those discussions get archived is a matter for the more technical among us. By keeping archiving and talkpage “headering” separate issues, it keeps it simple for editors, and leaves to those concerned with archiving the technicalities of setting up archiving timetables and affixing notices thereof. Let’s follow the KISS rule — keep it simple — which it currently is. This strikes me as a solution to a non-problem that will have the unintended consequence of making things more complex for writers/editors, and in effect, throw the baby out with the bathwater. Thanks! — SpikeToronto 10:28, 3 June 2021 (UTC)[reply]

  @SpikeToronto: the default behaviour of the talk header is still no archives. If you put a parameterless ((talkheader)) on a page, it will behave exactly the same in this proposal as it did before. By the way, archives are already in the talk header anyway, and it's already the case that the box is only turned on by those technical editors when necessary. The only addition to the talk header is the optional small note indicating the archiving period, and it won't make anything more complicated for non-technical editors. ―Jochem van Hees (talk) 11:26, 3 June 2021 (UTC)[reply]

  @Jochem van Hees: Thank you so much for clarifying that, Jochem van Hees! That is a weight and concern lifted from my mind. I had not fully understood that ((talkheader)) had become so complex. Nevertheless, if I understand you correctly, for those of us who use it as I do, to merely head up talkpages with, then nothing will change for us. Thanks! — SpikeToronto 13:02, 3 June 2021 (UTC)[reply]
  P.S. Based on Jochem van Hees's explanation, I have struck out my opposition above to the proposal. — SpikeToronto 13:02, 3 June 2021 (UTC)[reply]

• Support per norm. ― Qwerfjkl | 𝕋𝔸𝕃𝕂  (please use ((reply to|Qwerfjkl)) on reply) 11:25, 3 June 2021 (UTC)[reply]
• Support merging, which will improve the readability of most talkpages. Specification and control of archiving is a more technical editing skill, which interested editors can easily adapt to under the enhanced ((talkheader)) template. Reify-tech (talk) 17:42, 3 June 2021 (UTC)[reply]
• Support I had to think about this, and there probably are a few cases where an archiving notice is desireable but the normal talkheader is not, and we want to intrude onto userspace choices as minimally as practicable, but that can be fixed by creating a new template. Indeed, in principle talkheader itself code be coded to display only the archive stuff and nothing else by setting the parameter to some specific value. Of course more parameters do confuse newbies, but then again so do templates in general, so probably doen't make much of a differrence there, and taming talk page clutter helps everyone. Regards, 31.41.45.190 (talk) 19:05, 3 June 2021 (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(s) or module(s) 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. Plastikspork _―Œ^(talk) 22:27, 20 May 2021 (UTC)[reply]

• Template:BIA-Owner (talk · history · transclusions · logs · subpages)

Used once and that link leads to a 403 page. No documentation, so not even sure if the current website is the one originally used for this external link. Gonnym (talk) 18:36, 13 May 2021 (UTC)[reply]

• Comment there is a complementary template ((BIA)) for station callsigns -- 67.70.27.105 (talk) 14:12, 14 May 2021 (UTC)[reply]

• Delete per nomination. --WikiCleanerMan (talk) 19:57, 19 May 2021 (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(s) or module(s) 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. Plastikspork _―Œ^(talk) 14:10, 20 May 2021 (UTC)[reply]

• Template:Uw-yousuck (talk · history · transclusions · logs · subpages)

This seems to show specific types of vandalism. ((subst:Uw-vandalism1)) is a user warning message about vandalism in general. Doesn't really seem necessary or useful for a warning message. Also, the template uses a specific article on White & Nerdy for the "you suck" term. Seventyfiveyears (talk) 13:56, 13 May 2021 (UTC)[reply]

• Delete This is the reference. Agree that it's completely unnecessary. --Trialpears (talk) 14:00, 13 May 2021 (UTC)[reply]
• Delete; it's been made obsolete by the other warning templates. ―JochemvanHees (talk) 22:21, 13 May 2021 (UTC)[reply]
• Delete per comment above --Vacant0 (talk) 11:49, 14 May 2021 (UTC)[reply]
• Keep: This is referring to a specific part of Wikipedia history. The music video for White & Nerdy features exactly this vandalism, and inspired a spate of it across related articles. Accordingly, this template is targeted at the people who were engaging in that specific act, being more useful and precise for them than other warning templates -- think like the specialized templates for the TikTok vandalism earlier this year. It's not particularly common now, but it's a cute and harmless bit of wikihistory and chronicling it is strictly better than the alternative. Vaticidalprophet 13:36, 14 May 2021 (UTC)[reply]
• Keep or maybe move into Project/User space instead. I could understand the confusion with it being in template space. JackFromWisconsin (talk | contribs) 13:42, 14 May 2021 (UTC)[reply]
• delete, vandalism is vandalism. to pretend like we know the precise motivation is silly. Frietjes (talk) 23:29, 14 May 2021 (UTC)[reply]

  In this case, we do. It was a huge problem for years that ended in serious consideration of full protection because of how many autoconfirmed accounts were vandalizing (this was pre-ECP). Vaticidalprophet 00:06, 15 May 2021 (UTC)[reply]

• Move to userspace as I can see the history about the template somewhat worth to keep especially with the article having a screenshot of the action. Perhaps one of the first commercial appearances of Wikipedia as this was back in 2006. – The Grid (talk) 21:51, 16 May 2021 (UTC)[reply]
• Move to userspace. What kind of template is this? NYC Guru (talk) 01:00, 17 May 2021 (UTC)[reply]
• Delete. There's really no reason this should exist. It doesn't do anything that ((uw-vandalism1)) doesn't do, other than make vandalizing the page slightly more amusing for the vandal. – Frood (talk) 01:25, 17 May 2021 (UTC)[reply]
• Delete Created by a user who has been blocked indefinitly since January of this year for persistant disrupting editing and racism. This template counts as part of the former. It was created for no purpose other than for trolling. --WikiCleanerMan (talk) 20:02, 19 May 2021 (UTC)[reply]
• Delete Surely an admin could solve against the "YOU SUCK!" edits on said articles by using an AbuseFilter that prevents said edits from entering the article? Otherwise, use of the ((uw-vandalism1)) etc. would make more sense for just telling users to stop doing such edits. This particular warn template is far too specific and not useful at all. Qwertyxp2000 (talk | contribs) 01:11, 20 May 2021 (UTC) Qwertyxp2000 (talk | contribs) 01:12, 20 May 2021 (UTC)[reply]
• Delete the "You Suck" vandalism appears to be years ago, but the template was created late 2020 and a search shows just one substituted use. Cheers KylieTastic (talk) 10:31, 20 May 2021 (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(s) or module(s) 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 speedy deleted by Kirill Lokshin per WP:G1. (non-admin closure) Seventyfiveyears (talk) 16:46, 13 May 2021 (UTC)[reply]

• Template:JUNE 2094 END OF THE WORLD (talk · history · transclusions · logs · subpages)

Original research in the wrong namespace. —Bruce1ee^talk 10:19, 13 May 2021 (UTC)[reply]

Speedy delete via G1, G6, or some other criterion. – Jonesey95 (talk) 14:38, 13 May 2021 (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(s) or module(s) 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 relisted on 2021 May 21. Anarchyte (talk) 05:51, 21 May 2021 (UTC)[reply]

• Template:Usericons (talk · history · transclusions · logs · subpages)

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(s) or module(s) 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 Withdrawn. No reason for me not to close this. We all agree that the current situation is good and no one advocates for deletion anymore. (non-admin closure) --Trialpears (talk) 23:25, 20 May 2021 (UTC)[reply]

• Template:ISO 15924 number (talk · history · transclusions · logs · subpages)

Deprecated in favor of ((ISO 15924 code)) which does the same thing but returns the language code instead of a for almost everyone meaningless number. Only a handful of uses so conversion shouldn't be too hard. --Trialpears (talk) 09:28, 13 May 2021 (UTC)[reply]

• Keep. This is still a normative property in the ISO 15924 standard, and is NOT actually deprecated. It is just that most of the time the 15924 code is what would be intended. This template's usefulness has largely been subsumed by wikidata, but that does not change its status as part of a set of templates for 15924 normative properties, and until we have lua module for all the normative 15924 properties, these templates are not severable from each other. VanIsaac, MPLL ^cont_WpWS 15:41, 13 May 2021 (UTC)[reply]
• Keep. Although I advanced 'deprecation' &tc. last January, when updating all script definitions & descriptions (like here), I found that the template is useful. We need it for this situation:

The Phoenician alphabet is a stand-alone definition/article, and so the number code can be pulled from Wikidata (see its infobox). However, in ISO15924 (and in Unicode for that matter), a script like Paleo-Hebrew alphabet is considered included in (part of, incorporated in) the Phoenician alphabet. Then, to add the number code into its Infobox, we must add the Phoenician number somehow (cannot pull it from WD now or easily). This ((Infobox writing system)) feature has to be added yet (for the Paleo-Hebrew situations), and will use this number code template.

-DePiep (talk) 19:37, 19 May 2021 (UTC) (creator of this template)[reply]

• Comment As long as the documentation is updated to reflect that it isn't deprecated I'm happy with this being kept. --Trialpears (talk) 20:03, 19 May 2021 (UTC)[reply]

Tag 'depr' removed. -DePiep (talk) 20:32, 19 May 2021 (UTC)[reply]

Sorry for keeping up this confusion for months. Topic of Scripts was growing out of hand ;-) -DePiep (talk) 21:48, 19 May 2021 (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(s) or module(s) 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. Plastikspork _―Œ^(talk) 14:07, 20 May 2021 (UTC)[reply]

• Template:Hour-1 (talk · history · transclusions · logs · subpages)
• Template:Hour+1 (talk · history · transclusions · logs · subpages)

Unused template (zero transclusions). Use ((#time:H|-1 hour)) instead. Eyesnore 03:09, 13 May 2021 (UTC)[reply]

For ((Hour+1)), the only transclusion is in the page Wikipedia:Date math. It is recommended to use ((#time:H|1 hour)) instead. Eyesnore 03:11, 13 May 2021 (UTC)[reply]

• Delete per nomination. Unused. --WikiCleanerMan (talk) 15:54, 19 May 2021 (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).