Wikipedia

Wikipedia:Templates for discussion/Log/2020 October 25

< Wikipedia:Templates for discussion | Log
< October 24 October 26 >

October 25

edit

Template:Chief Ministers of North Eastern Province

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. Based on minimal participation, this uncontroversial nomination is treated as an expired PROD (a.k.a. "soft deletion"). Editors can request the page's undeletion. (non-admin closure) ProcrastinatingReader (talk) 16:50, 1 November 2020 (UTC)[reply]

We don't need a navigation template with a single entry and no possibility of expansion - there was only one chief minister in the history of the North Eastern Province. Obi2canibe (talk) 14:19, 25 October 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Current events portal

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. — JJMC89 (T·C) 03:46, 4 November 2020 (UTC)[reply]

A single usage that can be substituted. Duplicates {{portal|Current events}} (which is transcluded at the bottom of 2020, btw), except that {{Current events portal}} is visible on the mobile version. —⁠andrybak (talk) 12:44, 29 September 2020 (UTC)[reply]

  • As you wrote yourself: that other template is not visible on mobile. In addition to that, I hope that the template can later be improved so that it transcludes parts of the Current events portal. The existing templates can't be aligned to the right. --Prototyperspective (talk) 15:05, 29 September 2020 (UTC)[reply]
  • Prototyperspective, could you please clarify what you mean by The existing templates can't be aligned to the right.? {{portal|Current events}} is aligned to the right by default. Adding |left=true aligns it to the left. —⁠andrybak (talk) 14:16, 19 October 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Primefac (talk) 00:16, 16 October 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, ProcrastinatingReader (talk) 12:16, 25 October 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Russia national football team matches

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 2020 November 5. Primefac (talk) 01:41, 5 November 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Film date

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 keep. Community consensus clearly does not see any benefit to merging these two templates, and I do not foresee any supportive input incoming. I also do not see things WP:CALMing down, so it would be best to wrap this up so the community at large can move on to more productive matters. I hope no one sees any disrespect directed at them in me making this move, because that is certainly not my intent. (non-admin closure) Zeke, the Mad Horrorist (Speak quickly) (Follow my trail) 20:38, 4 November 2020 (UTC)[reply]

Propose merging Template:Film date with Template:Start date.
This template is used in 100,000 articles. It includes functionality useful for television films that is not used in the TV project because the TV project uses {{start date}} in nearly 50,700 articles. ({{infobox television film}} was merged into {{infobox television}} over 5 years ago.) It seems prudent to consolidate the two templates since they have similar functionality. AussieLegend (✉) 09:42, 25 October 2020 (UTC)[reply]

  • Oppose: The template is used mainly by articles in the scope of the Film project, the intention two-fold. First, it provides automatic categorization for articles into year categories (e.g. Category:2020 films). Second, it provides consisting formatting for multiple dates in different locations (see use in The Death of Stalin). It seems that the concern proposed is its use in television articles, which was not the intent of the original template. Merging a template because one project does not advise its use does not seem productive to the thousands of articles that are using the template as intended and as advised by the film project. BOVINEBOY2008 10:31, 25 October 2020 (UTC)[reply]
It seems that the concern proposed is its use in television articles - No, not at all. My concern is that the functionality of {{film date}} is missing from {{start date}} and merging the two would enhance the functionality of the latter. I don't propose that the functionality be lost to the film project at all, which is why I proposed a merge, not a deletion. --AussieLegend (✉) 12:43, 25 October 2020 (UTC)[reply]
You haven't actually stated why you oppose a merge that would enhance the functionality of another template. As for the infobox merge, that was "both broad and unanimous". --AussieLegend (✉) 12:43, 25 October 2020 (UTC)[reply]
If there's functionality in "film date" that would improve "start date", then why not just copy that functionality and add it to "start date" instead of demanding that they be merged? Bearcat (talk) 14:29, 25 October 2020 (UTC)[reply]
With the added functionality in {{start date}} there will be no need for {{film date}}. I thought that would be obvious. --AussieLegend (✉) 14:57, 25 October 2020 (UTC)[reply]
Other than the need to make "start date" somehow know whether it's on a television film or a television series, so that it autocats television films as films but doesn't autocat television series as films? Unless you can figure out a way to make the merged template automatically make that determination on its own, with absolutely zero opportunity for any form of human error to ever cause even one single solitary television series to ever get miscategorized as a film at all (or any film to ever get miscategorized as a television series), the templates still won't be redundant. Bearcat (talk) 15:30, 25 October 2020 (UTC)[reply]
Do you think autocategorisation is completely automatic now? It's not. In order to categorise TV films you need to include |TV=yes or |TV=y. If an editor forgets to do this, the article is added to Category:YYYY films instead of Category:YYYY Television films. --AussieLegend (✉) 16:02, 25 October 2020 (UTC)[reply]
In the film template, autocategorization is completely automatic: every film with the "film date" template on it is automatically added to "YYYY films" for the YYYY specified in the template. Bearcat (talk) 20:17, 25 October 2020 (UTC)[reply]
In the film template, autocategorisation is not completely automatic. It's only automatic for film articles. If a TV article uses it without |TV=yes, TV articles will be automatically categorised as theatrical films, which is not correct. If you use the film template in the wrong article, which I have seen done, it automatically categorises the article as a film article, even if it's about dinosaurs or rockets. --AussieLegend (✉) 04:06, 26 October 2020 (UTC)[reply]
You do realize you're literally contradicting yourself here, right?
In the film template, autocategorisation is not completely automatic. [...] If you use the film template in the wrong article, which I have seen done, it automatically categorises the article as a film article, even if it's about dinosaurs or rockets.
Yes, it does. That's exactly my damn point: if you use the film template in an article, then that article is automatically categorized as a film even if the topic is not actually a film. In other words, the template automatically categorizes the topics, exactly as I've been saying. And the fact that it's not correct to automatically categorize non-films as films is precisely the problem here — if you merge a template that's meant for films, and thus automatically categorizes its topics as films even if it's been used errroneously on non-films, with a template that is not meant for films in the first place, then a lot of things that are not films start getting miscategorized as films. Bearcat (talk) 13:50, 27 October 2020 (UTC)[reply]
You're missing the point. Wthout switches, the template automatically categorises any article that it is used in as a film, whether or not the subject is a film. If you want to categorise a television film as a television film then it is a manual process, through the use of a switch.
if you merge a template that's meant for films, and thus automatically categorizes its topics as films even if it's been used errroneously on non-films - The template really shouldn't automatically categorise EVERY article as a film. That's running afoul of WP:TCAT. Switches should be used. --AussieLegend (✉) 17:54, 27 October 2020 (UTC)[reply]
Yeah, no, I'm not missing the point at all. I'm not talking about television films, I'm talking about television SERIES. You know, ongoing things with regular episodes, which are NOT FILMS. The fact that you keep replying to me by repeating this irrelevant point about how {{film date}} handles the distinction between theatrical films and television films is getting tiresome, because THAT IS NOT THE ISSUE: this has nothing to do with how film date handles that distinction, and everything to do with the fact that film date is for films while start date is for television SERIES.
I keep repeating over and over again that the problem is about television SERIES, and you keep responding with this irrelevant blather about television films, even after I've pointed out several times already that television films are not what I'm talking about. That doesn't make me the person who's "not getting it". Bearcat (talk) 13:23, 28 October 2020 (UTC)[reply]
I'm not missing the point at all. I'm not talking about television films, I'm talking about television SERIES. - Yes, you are missing the point. Television series are not relevant at all. Nor are Adelaide, Apollo program, Anti-Ballistic Missile Treaty, Effigy Mounds National Monument or any of the many other articles that use "start date".
I keep repeating over and over again that the problem is about television SERIES, - Believe me, it's getting frustrating. --AussieLegend (✉) 16:56, 29 October 2020 (UTC)[reply]
It doesn't fucking matter how many other types of things use {{start date}}. You kept harping on television films as if they had anything to do with anything, even when I said I wasn't talking about television films — for one thing, television films are supposed to be getting categorized as films anyway, so the categorization of television films has nothing to do with anything. The problem is that if we merge the templates, a lot of things that are no type of film at all, such as television series, Adelaide, Apollo program, Anti-Ballistic Missile Treaty, Effigy Mounds National Monument or any of the many other articles that use "start date", are vulnerable to getting miscatted as films if an editor makes the slightest error in template syntax — and conversely, things that are films will fail to get categorized as films if an editor makes the slightest error in template syntax. If there's one thing I've learned in my years as a Wikipedia admin, it's that no matter how simple and foolproof something may seem, people will still find a way to mess it up.
So, the bottom line is this: if you're so bound and determined that these templates have to be merged that you're willing to make up your own strawmen about television films to argue with, then it is your job to be constantly on top of every individual transclusion of "start date" to ensure that every error which causes a non-film to get miscategorized as a film, and every error which causes a film to fail to get categorized as a film, gets corrected immediately.
But you don't want to be locked into having to constantly do that every second of every day for the rest of your natural life, you say? Guess what: neither does anybody else. But if you merge these templates, then somebody has to take on the permanent job of miscategorization police, because people can, do and will screw up.
So unless you can come up with a solution that prevents any non-film from ever getting misfiled as a film, and prevents any film from ever failing to get categorized as a film, without the use of optional yes/no flags that people will fuck up, I'm not the one who's missing the point. Bearcat (talk) 02:45, 30 October 2020 (UTC)[reply]
It doesn't fucking matter how ... Dude, you need to calm down. If you can't control yourself there's little point in continuing with this thread.

You kept harping on television films as if they had anything to do with anything, - Television films are at the very heart of this proposal. You even said Other than the need to make "start date" somehow know whether it's on a television film or a television series, which is a complete non issue as it is easy to do. ou also said so that it autocats television films as films but doesn't autocat television series as films? That's also easy. for one thing, television films are supposed to be getting categorized as films anyway, - No, they're supposed to be categorised as television films, which is what {{film date}} does when you include |TV=y per the template instructions. It actually categorises TV films as Category:YYYY Television films. I've already explained this. if we merge the templates, a lot of things that are no type of film at all, such as television series, Adelaide, Apollo program, Anti-Ballistic Missile Treaty, Effigy Mounds National Monument or any of the many other articles that use "start date", are vulnerable to getting miscatted as films if an editor makes the slightest error in template syntax - No, that won't happen because you will have to use a switch. As I explained, fully automatic categorisation falls afoul of WP:TCAT. I've already explained that as well. you're willing to make up your own strawmen about television films to argue with - I find this offensive, especially when you don't seem to be following the discussion. So unless you can come up with a solution that prevents any non-film from ever getting misfiled as a film, - I've already explained how to do that. --AussieLegend (✉) 14:52, 31 October 2020 (UTC)[reply]

"No, they're supposed to be categorised as television films," Yes, that's true, but it's not in conflict with what I said. The base "nationality films" categories are deemed all inclusive, which means that all films are supposed to directly appear in the parent category even if they're in other subcategories. If a film is in Category:Canadian drama films, it still has to be filed in Category:Canadian films alongside that; if it's in Category:Spanish comedy films, it still has to be in Category:Spanish films alongside that; and if it's in Category:American television films, it still has to be in Category:American films alongside that. So television films, even if they're already categorized as television films, most certainly are supposed to be categorized as films as well.
"No, that won't happen because you will have to use a switch." And as I've already pointed out, using a switch does not work, because editors can, do and will mess switches up. If they miss the switch, the thing gets filed wrong. If they mistype the switch, the thing gets filed wrong. If they use the wrong switch, the thing gets filed wrong. So manual y/n switches are not the answer — they're the problem that needs to be answered, because they are not foolproof and do not prevent things from getting miscategorized.
" As I explained, fully automatic categorisation falls afoul of WP:TCAT." Be that as it may, changing it has to be done extremely carefully, to make sure that none of the affected articles get pulled out of their correct categories at all: the last time I can recall a template that was autocatting articles having that function removed from it arbitrarily, the entire Category:Populated places in Austria tree got completely decategorized — and no, I'm not making that up: every single city, town or village in all of Austria really did get thrown into the uncategorized articles queue by the template change, and it took over a week to put all the articles back where they were supposed to be. So no, regardless of whether it's right or wrong for the Films tree to be populated that way, you are not touching that function until you have personally gone through all of the approximately 100,000 articles we have about films to make sure that they're all directly categorized appropriately, so that removing the categorization funtion from the template does not pull a single article about a film out of its appropriate Year films category — regardless of whether it's right or wrong, there's a lot of due diligence that has to be done before the function can be removed. Bearcat (talk) 18:49, 31 October 2020 (UTC)[reply]
It certainly won't hurt the film project editors to only have to be using one template, no matter whether what article they are editing. --AussieLegend (✉) 14:57, 25 October 2020 (UTC)[reply]
  • Oppose. In addition to all the reasons that have already been pointed out, it also bears mention that "start date" is not only used for television films, but also for the premiere date of ongoing television series — which means that if they're simply merged willy-nilly, then we start getting TV series autocatted as films (which is not desirable). If there are functions in "film date" (other than auto-catting as films) that would improve "start date", then anybody can copy and paste them into "start date" at any time so that "start date" gains that functionality — but it doesn't necessitate merging them into one. Bearcat (talk) 14:33, 25 October 2020 (UTC)[reply]
A merge would not be "willy-nilly". The merged template would be tested thoroughly, as is done and as should be done with merges. Importantly, {{film date}} already contains TV functionality and is already used in many TV articles where it auto-cats TV films. However, not all TV films use the template now so there are a lot of sub-categories of Category:Television films by year that are incompletely populated. --AussieLegend (✉) 14:57, 25 October 2020 (UTC)[reply]
And how exactly do you propose to make the target template autocat television films as films, while making it not autocat television series as films? Again, the start date template is not used only for television films, but also for television series — and a merged template would have to somehow be able to differentiate films from television series all by itself, without ever introducing any opportunity for human error to result in any topic getting miscategorized — so the only way I can think of (adding some kind of extra "series-vs.-film" flag that would have to be manually turned on or off by an editor) simply doesn't cut it. If you can't figure out a way to make a merged template automatically know whether it's transcluded in a film or a television series all by itself, with no opportunity for anybody to ever make any form of error that ever causes any film or television series to get miscategorized as the wrong thing, then the templates still aren't redundant no matter how similar their functionalities are or aren't. Bearcat (talk) 15:22, 25 October 2020 (UTC)[reply]
And how exactly do you propose to make the target template autocat television films as films, while making it not autocat television series as films? - How about exactly the way it is done now? Do you think autocategorisation is completely automatic, because it's not. In order to categorise TV films you need to include |TV=yes or |TV=y. If an editor forgets to do this, the article is added to Category:YYYY films instead of Category:YYYY Television films.
the only way I can think of (adding some kind of extra "series-vs.-film" flag that would have to be manually turned on or off by an editor) simply doesn't cut it. - That's exactly how it is done now to "make the target template autocat television films as "television films", while making it not autocat television films as films?" --AussieLegend (✉) 16:02, 25 October 2020 (UTC)[reply]
How the TV template does things is irrelevant, because I'm talking about the film template. The film template does autocategorize films as "YYYY films" for the year specified in the template — and a merged template would have to retain that function, because it fuckers the film categories if it doesn't. So you merge them, and the slightest editor error gets a film categorized as a TV series and vice versa. It has to be completely impossible for that error to even be possible for anybody to ever make at all: just saying that it's fixable when it happens is not good enough, because somebody has to notice the problem before it can be fixed — it has to be absolutely impossible for any such error to even get made in the first place.
And by the way, you're still missing the actual point: the issue isn't about television films vs. theatrical films, it's about all films versus television series, because the "start date" template is also used for the premiere dates of television series. Bearcat (talk) 19:35, 25 October 2020 (UTC)[reply]
What TV template are you talking about? Whatever it is, I wasn't talking about that. I was explaining how "film date" categorises articles. Sure the template autocategorises films but if you don't add a switch in a TV article it also gets categorised as a film, not a television film, so the template is flawed already based on your arguments. --AussieLegend (✉) 03:59, 26 October 2020 (UTC)[reply]
Which, again, just proves that you're missing the point. Why do you keep harping on the difference between how "film date" handles theatrical vs. television films, when I've been exceedingly clear that the problem is not with that, but with the fact that you're trying to merge it with a template that's primarily used for television SERIES? The problem here is not "theatrical films" vs. "television films" — it's "all films regardless of the theatrical vs. television distinction" vs. "things that are not films at all". If you merge the templates and take the autocategorization of films function away, then you break the film project — and if you merge the templates and don't take the autocategorization of films function away, then things that are not films at all start getting categorized as films. Bearcat (talk) 13:26, 27 October 2020 (UTC)[reply]
you're trying to merge it with a template that's primarily used for television SERIES? - {{start date}} isn't predominantly used for television series. It's a general template. There are nearly 50,700 TV series articles that use it with a total use of 359,301. Many of those articles have nothing to do with TV.
If you merge the templates and take the autocategorization of films function away, then you break the film project - That won't happen. At worst, the categorisation will become "opt-in" with a switch, and a bot can easily update any affected articles. Then we can start getting TV films categorised properly. If we use a switch like |type= the categorisation can be expanded to cover other types of articles as necessary. --AussieLegend (✉) 17:54, 27 October 2020 (UTC)[reply]
  • Oppose without a specific plan for dealing with the multiple conflicting unnamed parameters in these templates. Start date accepts HH|MM|SS|TimeZone, while Film date accepts multiple dates and locations, all as (Cthulhu help us) a long list of up to 20 unnamed parameters. How would a merged template work? If Film date is useful in TV articles, use it instead of Start date. – Jonesey95 (talk) 15:15, 25 October 2020 (UTC)[reply]
  • Oppose Not sure why what is used for TV article infoboxes has to be imposed on film article infoboxes. This isn't broken so it does not need fixing. MarnetteD|Talk 19:08, 25 October 2020 (UTC)[reply]
That's not at all what is proposed. --AussieLegend (✉) 19:17, 25 October 2020 (UTC)[reply]
Really? Replacing "film date" which is used in film article infoboxes with "start date" which is used in tv article infoboxes seems to be the proposal. Perhaps you are not clear on what it is you are asking for. This does confirm my reasons for opposing. MarnetteD|Talk 19:43, 25 October 2020 (UTC)[reply]
{{start date}} is used in over 359,000 articles, not just TV articles. It's not a TV template, it's a general template. I am perfectly clear on what I am proposing, it appears that you are not. --AussieLegend (✉) 03:59, 26 October 2020 (UTC)[reply]
Neither of those apply, especially WP:SLOP! There is a problem that has been ongoing for some time and that is the improper categorisation of television films, which has been explained more than once. --AussieLegend (✉) 17:54, 27 October 2020 (UTC)[reply]
Merging Template:Film date with Template:Start date still doesn't seem to solve this "problem" you're on about. As Cobaltcigs has pointed out, made-for-TV films are still films, not TV series, so there is no realistic problem with the categorisation. Also, a look at Category:Television films shows (to me) that there really isn't anything wrong with the current system. Quahog (talk • contribs) 00:33, 28 October 2020 (UTC)[reply]
Yes, it will fix the problem because {{start date}} doesn't include the semi-automatic categorisation that {{film date}} does so articles aren't being added to the categories. Clearly, you haven't looked hard enough because the categories are missing a lot of articles. --AussieLegend (✉) 00:43, 28 October 2020 (UTC)[reply]
As everyone else is trying to point out, you're proposing to merge Template:Film date into a template that's used for TV series, which is why I still think WP:SLOP applies here. This merger isn't much beneficial at all. Also, if there are any missing articles in Category:Television films, just add the categories to that article, simple as that! Quahog (talk • contribs) 15:39, 28 October 2020 (UTC)[reply]
As everyone else is trying to point out, you're proposing to merge Template:Film date into a template that's used for TV series, - I don't see why people are so fixated on TV series. {{start date}} is used by many articles. It isn't just for TV series. I've just had to provide some examples to Bearcat above, as he seems confused as well. Once again, TV series are irrelevant.
just add the categories to that article, simple as that! - Easier said than done, and it's separate problem altogether that would be made easier by a merge. --AussieLegend (✉) 16:56, 29 October 2020 (UTC)[reply]
WP:SLAP certainly applies. ―cobaltcigs 11:08, 29 October 2020 (UTC)[reply]
I know Template:Start date is used by many articles, the point I'm trying to make is that there's a reason why television films use Template:Film date, and it's that they're still films, not TV series (which don't have a dedicated template and as such uses Template:Start date), and it would certainly be a lot more useful if they use the film date template. As such, I'm still not convinced this merger will actually solve this "problem" you're on about. Quahog (talk • contribs) 20:58, 29 October 2020 (UTC)[reply]
the point I'm trying to make is that there's a reason why television films use Template:Film date, - But they don't. Because TV films are now handled by {{infobox television}} instead of {{infobox television film}} and have done for over 5 years, they use "start date". That's where the problem lies. --AussieLegend (✉) 14:58, 31 October 2020 (UTC)[reply]
  • AussieLegend, I might have time next week to take a look at this and we can work together to see what functionality from film date we can use for the television template. I will say that start date is also used in episode list templates which makes it seem like not a good target. This might need a more deeper look. Please remind me next week if I forget. --Gonnym (talk) 22:18, 25 October 2020 (UTC)[reply]
as I've pointed out above, {{start date}} is used in over 359,000 articles. I don't get why everyone thinks it's a TV template. --AussieLegend (✉) 03:59, 26 October 2020 (UTC)[reply]
  • Oppose. There is a difference between Television films and theatrical films of which the former is made for television broadcasts like Atomic Train, Thrill Seekers, Polar Storm, and others, while theatrical films may do almost the same thing, but it was the date when it was first released to selected or wide theaters in selected regions first before releasing to DVD's or by video-on-demand sometime later, and it can be broadcasted by television, but it is not considered a television film because it doesn't have the original television network like Syfy to premiere it to television viewers, like Atomic Train (which was premiered on TV by NBC), and Polar Storm (whose the original network is the Sci-Fi Channel [now Syfy]) (I'm not experienced actually, but I refer to keep it that way. not to be merged into one another.) ROBLOXGamingDavid (talk) 23:59, 25 October 2020 (UTC)[reply]
  • Oppose per all the opposers. This is a solution to a problem that doesn't exist. Lugnuts Fire Walk with Me 07:58, 26 October 2020 (UTC)[reply]
If you actually read the discussion you'll see that there is a problem in that categories are not being populated. I've explained it above. --AussieLegend (✉) 10:30, 26 October 2020 (UTC)[reply]
I have read the discussion, actually. Lugnuts Fire Walk with Me 12:52, 26 October 2020 (UTC)[reply]
You don't think that categories not being populated is a problem? --AussieLegend (✉) 14:19, 26 October 2020 (UTC)[reply]
I must admit, Aussie, it is slightly amusing seeing you on this side of a TfD. Some sympathies, of course. That being said, isn't {{Film date}} just a wrapper around the latter template. Admittedly, I think you've a valid point somewhere here, but a clearer nomination might've been better, or a demonstration, because it is admittedly slightly hard to see what is being proposed from this side (without one digging deep into this themselves). ProcrastinatingReader (talk) 21:52, 26 October 2020 (UTC)[reply]
It's clearly a merge discussion so that is what is being proposed and I thought It seems prudent to consolidate the two templates since they have similar functionality made it clear why it was being proposed. You especially should get that as a WP:INFOCOL supporter. There are a lot of side issues, such as incomplete population of categories, and in some cases depopulation of categories that are minor but essentially it's that the two templates serve so very similar purposes that it doesn't make sense to have two separate templates. It's clear to me from some of the responses that people are making assumptions about what does and doesn't happen. I can't do anything about that. As a side note, it shouldn't be amusing. I support or oppose template discussions based on what I think is best for the project. --AussieLegend (✉) 10:34, 27 October 2020 (UTC)[reply]
@AussieLegend that's why I haven't voted oppose (or support) :) -- I haven't had the chance to vet the nom. What I mean is, being clear on how the final template will look (and what is being merged, and where) might've generated a better response. As far as I can see currently, the proposed template is already a wrapper with additions. Should those additions be moved into the infobox, or into start date, or what? If into start date, isn't this loading up start date a bit (to chuck the categorisations into there)? If into the infobox, well, that may well make sense but it hasn't been clearly proposed. As I say, your proposal may well be valid, but I think the issue here is that it hasn't gotten through to people. Making it simpler for non-TPEs to understand may yield better results -- heck, I'm not even completely able to visualise what this will look like afterwards and I am a TPE, same seems true of Jonesey above. Try explaining the proposal better (or creating a mock in sandbox) and I think we may be able to move the ball forwards? ProcrastinatingReader (talk) 14:33, 30 October 2020 (UTC)[reply]
that's why I haven't voted oppose (or support) :) -- I haven't had the chance to vet the nom. - That's exactly what everyone should have done, instead of diving straight in without asking a single question. Thankyou.
What I mean is, being clear on how the final template will look (and what is being merged, and where) might've generated a better response. - I'm still not sure where the problem lies. The functionality of {{film date}} will be merged into {{start date}}. The final template will look just like both templates merged. There will be some minor changes, e.g. Instead of |TV=y it will probably be |tvfilm=y to avoid errors and |flm= will be added. The nomination really should be clear to anyone with an understanding of how templates work and a simple grasp of the English language. If someone needs clarifcation all they have to do is ask, instead of just running in with an oppose.
If into start date, isn't this loading up start date a bit (to chuck the categorisations into there)? - I really can't see that as a problem. There are far more complicated templates around.
If into the infobox, well, that may well make sense but it hasn't been clearly proposed. - Merging the templates means that start date would have additional functionality that other types of articles may find useful, which is why I didn't propose the infobox option. The infobox option also doesn't fix the problem with television films.
I'm not even completely able to visualise what this will look like afterwards and I am a TPE, same seems true of Jonesey above. - I looked at it and it all seemed clear just looking at the code. I asumed that it would be easy for others too. --AussieLegend (✉) 15:14, 31 October 2020 (UTC)[reply]
We need to keep the film date template, not merge it. Call me when you get the chance 17:25, 2 November 2020 (UTC)[reply]
This isn't an argument, you're just stating that you're opposed. Remember this is not a vote, you must have an argument. El Millo (talk) 17:49, 2 November 2020 (UTC)[reply]
Well, what movies are shown in cinemas and what movies are exclusive to television are two different things. How's that for an argument? Call me when you get the chance 20:49, 2 November 2020 (UTC)[reply]
You should really take some time to read the proposal and some of the other opposing !votes. El Millo (talk) 20:57, 2 November 2020 (UTC)[reply]
I already read the proposal, but some of the other opposing votes are TLDR. Call me when you get the chance 22:49, 2 November 2020 (UTC)[reply]
As I pointed out above, the film project editors won't have to use one tempate for films and another for every other article that they edit. Having one template instead of two is an improvement from a maintenance point of view. When infoboxes (a type of template) are nominated for deletion or merging, supporters often cite WP:INFOCOL. The principles of that essay really apply to "normal" templates as well. Strictly speaking, since {{film date}} is only used in the film project, there is no need for it at all as the functionality could be incorporated into {{infobox film}} and that would certainly make things easier for the film project. Whichever way you look at it, {{film date}} is not needed. --AussieLegend (✉) 06:25, 28 October 2020 (UTC)[reply]
Now you're muddling this proposal even further. Are you now suggesting that the categorization on Category:YYYY films should be handled by the infobox instead of the template, or are you suggesting that the date should all functionalities of {{film date}} should be incorporated into infobox film, therefore not using {{start date}} either? In any case, I suggest you veer your proposal towards enhancing and upgrading the {{start date}} in order to be as good or better than {{film date}} already is for film articles, and then you might get more support. El Millo (talk) 06:55, 28 October 2020 (UTC)[reply]
Now you're muddling this proposal even further. - I was trying not to. I thought this would be a simple discussion but so many people have got the wrong end of the stick. Why are so many opposers against TV series articles that use {{start date}} but not the thousands of other articles that use it? --AussieLegend (✉) 16:56, 29 October 2020 (UTC)[reply]
I'm sorry, but do you actually understand what this proposal is about? As I have had to explain to others, {{start date}} is not just used for TV series. It's used in many articles that have nothing to do with TV. You are of course welcome to your opinion but you really need to explain why merging a template used for films into a template that's used for TV series is not a good idea. I'm of the opinion that merging a template used for films into a template that's used in over 300,000 articles, eleiminating one and simplifying editing for is a very good idea. You need to rebut that with facts. --AussieLegend (✉) 16:56, 29 October 2020 (UTC)[reply]
  • Comment - It is rather frustrating that none of the opposers are template editors except for Jonesey95. Bearcat is an admin but a look at his contributions shows mostly editing of navboxes etc, not templates like {{film date}} and {{start date}}. (Please accept my apologies if this is incorrect!) The strange obsession with TV series that represent a minority of articles using "start date" by opposers seems to demonstrate a distinct lack of familiarity with coding of these type of templates. To use an analogy, it's like the opposition to 5G and WP:IDONTLIKEIT. --AussieLegend (✉) 17:12, 29 October 2020 (UTC)[reply]
It is rather frustrating that you are now straying into WP:ASPERSIONS territory since you seem to be saying that only template editors have the ability to comment on your proposal. As to the diatribe in this edit summary why are you so obsessed with forcing something on film articles when the template in current use works just fine. As to your 5g comment that is a straw man which works for Halloween but not this RFC. MarnetteD|Talk 17:25, 29 October 2020 (UTC)[reply]
I've clearly explained why I have the opinion that I have. why are you so obsessed with forcing something on film articles itself is a WP:IDONTLIKEIT argument. It's not a case of forcing anything onto film editors.
As to your 5g comment that is a straw man which works for Halloween but not this RFC. - Ignoring that this is a TFM discussion, not an RfC, your claim demonstrates what I have been saying. Editors seem to be afraid of change more than concerned with the technicalities. The 5G analogy is right on point. People are scared of 5G because of misinformation and because they don't understand it. That seems to be what is happening here. Of course, I'm happy to be proven wrong. Let's forget a merge or that you're being forced into something (which you are not by the way). please explain why implementing the functionality of "film date" into "start date" is not a good idea? --AussieLegend (✉) 17:39, 29 October 2020 (UTC)[reply]
@AussieLegend: You should've expected that the majority of !voters would come from the film project, since it is about a template used in film articles and only film articles. Why are so many opposers against TV series articles that use {{start date}} but not the thousands of other articles that use it. You seem to be really misunderstanding everybody's point here. No one is against TV series articles using {{start date}}, not even close. Most of the opposers, myself included, are against merging the two because it seems to be in detriment of {{film date}} rather than in general benefit of everyone. Regarding your answer to my first comment above, where I asked you if there will be an improvement over {{film date}} for the film project in any way: having to use different templates across different topics isn't a problem for editors, and in any case isn't about the film project but about editors editing outside of it. While I understand that, from a maintenance standpoint, it would be better to have just one template, it would be in detriment of a template for a specific topic which already works quite well. That's why I suggested you tried to first improve {{start date}} to the point which it would be no different to using {{film date}}, and then aim for the merger. I suggest this !voting be put on hold and we move to a Discussion section where we can get everything clear, as some !voters also seem not to understand the details of the proposal, which were rather confusing to begin with and made even more confusing as the discussion progressed. Should this Discussion section be a sub-section of this one or should we move to the talk of the template in question? El Millo (talk) 17:51, 29 October 2020 (UTC)[reply]
it is about a template used in film articles and only film articles. - That's not entirely correct. It is still used in a lot of TV film articles, many of which haven't been converted to use {{Infobox television}}. It is also used in some articles that have been converted so it affects the TV project as well.
You seem to be really misunderstanding everybody's point here. No one is against TV series articles using {{start date}}, - That's not what I said. People seem to be against TV articles in general. The point is, they're pretty much irrelevant to the proposal, even though they would benefit.
against merging the two because it seems to be in detriment of {{film date}} rather than in general benefit of everyone. - Nobody has explained why that would be the case. Yes, "film date" would be obsolete, but what is the issue with using a version of "start date" that incorporates the same functionality. Well, almost the same. There would be one very minor change, which I have explained above.
That's why I suggested you tried to first improve {{start date}} to the point which it would be no different to using {{film date}}, and then aim for the merger. - The entire point of the merge is to "improve {{start date}} to the point which it would be no different to using {{film date}}". Once that happens there would be no need for a merge. "Film date" could be deleted after a bot has updated all articles. The end effect on film editors is essentially zero. They would just have to make sure that |film=yes (or whatever the switch is) be included in the {{start date}}.
I suggest this !voting be put on hold and we move to a Discussion section where we can get everything clear, as some !voters also seem not to understand the details of the proposal, - The proposal isn't really a complicated one. I assumed that anyone able to edit Wikipedia would understand something so simple. Apparently I was wrong. --AussieLegend (✉) 18:12, 29 October 2020 (UTC)[reply]
@AussieLegend: Gonnym has offered to help working on it with you starting next week. Perhaps you could both work something up in the sandbox of either of these two templates, and then we can discuss more easily if it will be beneficial or not, since we will have something tangible to look at. I offer my help as well, though I'm not exactly an expert on infoboxes. El Millo (talk) 18:29, 29 October 2020 (UTC)[reply]
I offer my help as well, though I'm not exactly an expert on infoboxes. The offer of help is greatly appreciated. That you are not "an expert" is irrelevant. You're an end user and end users are always important in the development process. --AussieLegend (✉) 15:24, 31 October 2020 (UTC)[reply]
Claiming that editors are somehow "afraid" of merging these templates without a shred of evidence is classic straw man nonsense with a healthy dollop of sophistry thrown in. Plenty of reasons for opposing have already been given. MarnetteD|Talk 19:42, 29 October 2020 (UTC)[reply]
AL since you have devolved the conversation to personal attacks I will finish by saying that I've seen 1000's of wikipedia discussions over the years and casting aspersions like these rarely get you to the outcome that you are looking for. MarnetteD|Talk 20:01, 29 October 2020 (UTC)[reply]
Based on the speed with which the opposes came after the listing, the arguments being used, and the fact that nobody asked for clarification, the only conclusion is that people are afraid of change. Nobody is casting aspersions and the fact that you've taken this (at)tack, rather than take up the challenge of xplain[ing] why implementing the functionality of "film date" into "start date" is not a good idea only convinces me that I am correct. I expected better from you. --AussieLegend (✉) 15:21, 31 October 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Abnormal clinical and laboratory findings for blood

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 split. Primefac (talk) 22:28, 4 November 2020 (UTC)[reply]

Hi all - another nomination at this central venue regarding a medical template here.

I propose that this template is deleted, with relevant content moved to a new template, {{Blood film findings}}, some content moved to {{Infectious blood tests}}, and the rest of the content moved into relevant templates in this category: Category:Medicine procedure templates.

The reason is that this template is currently a higgledy-piggledy mess of findings. There are heaps of links relating to blood film findings here - but so many others that don't really have any logical links. For example - how are hyperglycaemia elevated alpha-fetoprotein and dacrocyte meaningfully related? We already have the excellent navbox {{Clinical biochemistry blood tests}} which lists WHAT blood tests there are - I think this navbox is better off deleted with more relevant or specific navboxes used on the child articles. It goes without mentioning that there are a lot more blood tests that could potentially or randomly be added here... in my mind I think it is better deleted / split.

Happy to hear what other editors think though. Ping to Spicy who has just written the featured article Full blood count and might have an opinion here. Tom (LT) (talk) 08:00, 25 October 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:WBCstartfem2

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. (non-admin closure) ProcrastinatingReader (talk) 16:55, 1 November 2020 (UTC)[reply]

Originally nominated for speedy deletion by @Squared.Circle.Boxing with the reason "Redundant (and currently blank) template. Appears to have been created after WBCstartfem was updated. WBCstartfem has been nominated for T3 and replaced with WBCstart" FASTILY 05:31, 25 October 2020 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Wt

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 redirect to Template:Wikt-lang after the issues mentioned in the discussion (in particular, that of nested templates and any missing functionality) are dealt with. Primefac (talk) 01:43, 5 November 2020 (UTC)[reply]

This template is an almost identical version of Template:Wikt-lang, with the difference being that this template does not add the html Lang="" attribute and does not italicize Latin words. This isn't a question of user preference as the MoS has already stated what should be done:

All usages should be replaced with {{Wikt-lang}}. Note that wikit-lang already handles non-latin text correctly and does not italicize it (فارسی) Gonnym (talk) 13:16, 12 October 2020 (UTC)[reply]

Or just redirect it? Would there be any issues with that? Headbomb {t · c · p · b} 04:25, 20 October 2020 (UTC)[reply]
@Headbomb: No, this should not cause any issues as both templates take the same arguments, and also means that Module:Language can be tidied up somewhat by removing the p.wikt function. -Einstein95 (talk) 13:33, 20 October 2020 (UTC)[reply]
Yes it would cause issues. Some of the usages of {{wt}} are placed inside {{lang}} templates so if you redirect you'll have a lang inside a lang. Such situations should be handled in a clean replacement and not rushed with a redirect. --Gonnym (talk) 14:12, 21 October 2020 (UTC)[reply]
  • Keep when it is surrounded by a HTML tag with a lang attribute, as when it's used within {{lang}}. That was my intention when I created the current version of the template. An example of correct usage is in Syncope (phonology): {{langx|grc|{{wt|grc|συγκοπή}}|{{grc-tr|συγκοπή}}|cutting up}}. {{lang-grc}} already language-tags the first parameter and using {{langx|grc|{{wikt-lang|grc|συγκοπή}}|{{grc-tr|συγκοπή}}|cutting up}} would create nested HTML tags, both with lang="grc". Replace with {{wikt-lang}} where there is not an enclosing tag with a lang attribute. Apparently some people figured it was a shortcut version of {{wikt-lang}}, as in Contraction (grammar): short, common and often [[Syllable|monosyllabic]] words like {{wt|nb|jeg}}, {{wt|nb|du}}, {{wt|nb|deg}}, {{wt|nb|det}}, {{wt|nb|har}} or {{wt|nb|ikke}}. That should be {{wikt-lang|nb|jeg}}, etc. Maybe it should be renamed to something extremely clear like {{wikt-inside-lang-template}} or {{wikt-without-lang-attr}} so people are less likely to misuse it. — Eru·tuon 05:24, 23 October 2020 (UTC)[reply]
    • Since the template is only used 160 times and most are incorrectly using it, it seems that the correct intention while good, has failed. Probably a better solution would be to add a parameter |tag=no or similar, which disables the language tag. Another option is that Module:Lang can check the parameter if it already has the lang tag which is a very simple check as it's passed as a string (which come to think of it, might be a worthwhile check anyways). --Gonnym (talk) 09:58, 23 October 2020 (UTC)[reply]
      Perhaps {{wt}} doesn't get deleted but instead, {{wikt-lang}} gets a |tag=no or |html=no or some such parameter so:
      {{wikt-lang|grc|συγκοπή|html=no}}
      gives:
      [[wikt:συγκοπή#Ancient Greek|συγκοπή]]
      {{wt}} accepts exactly the same parameters as {{wikt-lang}}. {{wt}} calls {{wikt-lang}} with the parameters that it received along with an unconditionally set |tag=no or |html=no. This mechanism is akin to the {{convert}} and {{cvt}} templates where |abbr=on is preset in the {{cvt}} call to {{convert}}.
      The other thing that needs looking into in Editor Erutuon's example is {{grc-tr}}. The example:
      {{langx|grc|{{wt|grc|συγκοπή}}|{{grc-tr|συγκοπή}}|cutting up}}
      produces this output: 
      [[Ancient Greek language|Ancient Greek]]: [[wikt:συγκοπή#Ancient Greek|συγκοπή]]</span>, <small>[[Romanization of Ancient Greek|romanized]]:&nbsp;</small><i lang="grc-Latn" title="Ancient Greek-language romanization"><span title="Ancient Greek transliteration" lang="grc-Latn"><i>sunkopḗ</i></span></i>, <small>[[Literal translation|lit.]]&nbsp;</small>&#39;cutting up&#39;
      Module:Lang produces 
      <small>[[Romanization of Ancient Greek|romanized]]:&nbsp;</small><i lang="grc-Latn" title="Ancient Greek-language romanization">...</i>
      where ... is produced by {{grc-tr}}: 
      <span title="Ancient Greek transliteration" lang="grc-Latn"><i>sunkopḗ</i></span>
      Nested <span>...</span> tags; each with its own lang= and title= attributes. Nothing wrong with that really. But, shouldn't the title= attributes be the same so that they match the static text 'romanized' in the rendered output?
      —Trappist the monk (talk) 13:43, 23 October 2020 (UTC)[reply]
      I'm a bit lost here. Is the second part of what you describe a problem with lang and wt templates or with grc-tr nested in a lang template? --Gonnym (talk) 22:57, 23 October 2020 (UTC)[reply]
      The title= attributes produces by {{lang}} and {{grc-tr}} are different from each other; cf.:
      title="Ancient Greek-language romanization" – {{lang}}
      title="Ancient Greek transliteration" – {{grc-tr}}
      In the rendered example, I think that the tool-tip at sunkopḗ in the rendering should use the same terminology as the visible static text: 'romanized':
      Ancient Greek: συγκοπή, romanized: sunkopḗ, lit. 'cutting up'
      —Trappist the monk (talk) 10:18, 24 October 2020 (UTC)[reply]
      Ah, I agree. Ideally we should have one module which handles the html tagging and everyone else calling that function. --Gonnym (talk) 22:02, 24 October 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Primefac (talk) 01:49, 25 October 2020 (UTC)[reply]

I agree with User:Gonnym that ideally {{wikt-lang}} and Module:Language would use Module:Lang for language tagging and italicization, and ideally {{wikt-lang}} would allow IETF language tags. I didn't attempt this because it's a bit complicated to handle both IETF language tags and Wiktionary language tags, which both can contain hyphens, but in entirely different ways. If anyone wants to take this on, I could at least help because I'm familiar with Wiktionary's language infrastructure.

I had ignored {{grc-tr}} in the {{lang-grc}} example. It also shouldn't be generating HTML when it's nested inside {{lang-grc}}. I like the suggested solution of a parameter that tells {{wikt-lang}} not to add HTML, and {{grc-tr}} could have the same feature.

Having {{wikt-lang}} omit language tagging when it contains lang attributes only works when its input is one span of language-tagged text. That's true in the {{lang-grc}} example. But it does not work if individual words are Wiktionary-linked inside a longer span of language-tagged text. That happens in Bai Mudan though {{wt}} or {{wikt-lang}} is not involved: {{zh|c={{linktext|白|牡|丹}}|p=bái mǔdān|w=pai2 mu3-tan1|l='''white [[peony]]'''}}. Here each individual parameter to {{linktext}} is linked (unfortunately not to the Chinese header, as {{wt}} would do) but not language-tagged and {{zh}} applies language-tagging. {{wt}} could also be used here to link to the Chinese sections of the Wiktionary entries: {{zh|c={{wt|zh|白}}{{wt|zh|牡}}{{wt|zh|丹}}|p=bái mǔdān|w=pai2 mu3-tan1|l='''white [[peony]]'''}}. {{linktext}} has a lang parameter that applies language tagging but does not link to the language's section of the Wiktionary entry; using it here would duplicate language tagging. Similar case with {{wt}} in Rhododendron pachysanthum: {{lang-zh|s={{wt|zh|台湾}}{{wt|zh|山地}}{{wt|zh|杜鹃}}|p=Táiwān shāndì dùjuān}}. There may be other cases where {{wt}} is used inside longer runs of language-tagged text in which not all words are linked, but I haven't spotted any.

Another idea is to have {{wikt-lang}} convert link syntax to link-to-header-in-Wiktionary-entry syntax (which wikt:Module:links does in templates such as wikt:Template:m). That is, {{wikt-lang|zh|[[白]][[牡]][[丹]]}} would be converted to something like <span lang="zh">[[wikt:白#Chinese|白]][[wikt:牡#Chinese|牡]][[wikt:丹#Chinese|丹]]</span>. But that might be too counterintuitive by Wikipedia conventions.

Looking at a complete list of all instances, {{wt}} seems to also be used to link individual English words to Wiktionary, in English text where the words don't need to be language-tagged. — Eru·tuon 10:48, 25 October 2020 (UTC)[reply]

@Erutuon: could you explain the issue with it's a bit complicated to handle both IETF language tags and Wiktionary language tags? As far as I can tell from the module code and from the tests I've ran with all languages in the /data sub-module, this isn't an issue at all. Here (in en.wiki) a user would enter the language tag as used by IETF or one of the supported private-use ones (in essence, anything that Module:Lang) supports. This module would then convert any names in the /data files to the section headers used in Wikitionary. Am I missing another step here? --Gonnym (talk) 14:22, 25 October 2020 (UTC)[reply]
I gather that Wiktionary have made up their own IETF-like tags (following in the footsteps of MediaWiki). For example, in Wikt:Module:wikimedia_languages/data, there is a translation of ISO639-3 language code ksh (Kölsch) to gmw-cfr; gmw is ISO 639-5 West Germanic languages and cfr is I-don't-know-what ({{ISO 639 name|cfr}} → error: cfr not found in ISO 639-1, -2, -2B, -3, -5 list (help)). Module:Lang rejects gmw-cfr because extlangs are not supported even were cfr defined in the IANA subtag registry as an extlang ({{#invoke:lang|name_from_tag|gmw-cfr}} → Error: unrecognized language tag: gmw-cfr). Module:lang does not support extlangs because all of the currently registered extlangs have preferred primary language tags.
This suggests to me that combining the tag-decoding is not to Module:lang's benefit because it does not want language tags that are not IETF compliant. That does not mean that Wiktionary can't use the IETF decoder to decode IETF tags if it benefits them.
—Trappist the monk (talk) 15:09, 25 October 2020 (UTC)[reply]
But again, the code here, in Module:Language does not care what the witkionary code is. The link produced by this module creates it like this [[wikt:" .. entry .. "|" .. linkText .. "]]. The entry value it gets from the name value of a language code in the /data sub-module or if a name is not found, it uses mw.language.fetchLanguageName(languageCode, 'en'). So as I said above, wherever there is a difference between the name used here (en.wiki) and the name used there, it's just a matter of adding it to the /data sub-module (as it's already done now). Also cfr is invalid here also, as {{wikt-lang|cfr|dog}} does not work either. --Gonnym (talk) 16:26, 25 October 2020 (UTC)[reply]
I'm pretty sure that I was attempting to answer your: could you explain the issue with it's a bit complicated to handle both IETF language tags and Wiktionary language tags? question which is referring back to Editor Erutuon's statement that it would be ideal if {{wikt-lang}} and Module:Language would use Module:Lang for language tagging and italicization which descends from your reply to me: Ideally we should have one module which handles the html tagging and everyone else calling that function.
You wrote: it's just a matter of adding it to the /data sub-module (as it's already done now). Which ~/data module are you talking about? Module:Lang/data does not now, nor should it ever, support non-IETF compliant tags like gmw-cfr. If Module:Language/data wants to do that, I have no objection except that I don't think much of the notion of making up non-standard language tags because those tags can't be used where compliance with IETF is required. Different codes for what is ostensibly the same language is just another cause for confusion.
I think that mayhaps I wasn't sufficiently clear about gmw-cfr. MediaWiki have created tags that look like IETF language subtags with extlang subtags but these pairings are not valid as IETF language tags. They have the proper form: <subtag>-<subtag> but both are language subtags so the second is not a valid IANA-registered extlang subtag. Examples of these are:
{{mw lang|bat-smg}} → Samogitian
{{mw lang|cbk-zam}} → Chavacano
{{mw lang|fiu-vro}} → Võro
{{mw lang|map-bms}} → Banyumasan
{{mw lang|roa-rup}} → Aromanian
I wondered if gmw-cfr followed the same pattern as these; it does not. The code cfr is not a valid ISO 639 language code nor is it a valid IANA-registered extlang subtag.
—Trappist the monk (talk) 17:45, 25 October 2020 (UTC)[reply]
Sorry if I was unclear, I was talking about the Module:Language/data module when I mentioned /data. Also, that module in how I explained above, does not need to make up language tags even if Wiktionary does as it does not use the language tag for anything other than in the Module:Language/data to access the relevant data. The only reason to edit Module:Language/data is if the displayed name in the anchor in Wiktionary is different than the display name we use on en.wiki. That does not change the lang tag, just the wiktionary link. The /sandbox already supports it mostly (I haven't edit Language/data to fix some of the custom languages there). --Gonnym (talk) 18:47, 25 October 2020 (UTC)[reply]
Wiktionary language codes aren't related to these MediaWiki language codes, which I wasn't aware of. Wiktionary has two classes of languages: those with language headers and those that are subvarieties of such languages. Most Wiktionary language codes for languages that have language headers are composed of two to three lowercase ASCII letters, which are often ISO language codes, but some are two to three sequences of two to three lowercase ASCII letters each, separated by hyphens. There are currently only three hyphenated codes in which one of the segments is two letters long (according to the census of hyphenated codes); I think these are the only ones that could be identical to an IETF language tag. Codes with three segments of three letters are significantly less common than codes with two segments, and most are proto-languages with the -pro suffix. Wiktionarians prefer to use ISO two- or three-letter codes when those are available, and sometimes hyphenated codes have been replaced with ISO codes when those have become available.
Etymology languages have a much wider variety of weird code formats. Some are ISO codes (kjv for Kajkavian), some have similar hyphenated formats to non-etymology language codes (though two-letter segments are much more common), a few are language names or abbreviations thereof (Late Latin and LL.), and a few are valid IETF tags (en-US). I'd be glad if we got rid of the two-letter-segment and language-name ones.
Hyphenated non-etymology language codes are all found in wikt:Module:languages/datax and are not related in any way to IETF language tags as far as I know. They are an indivisible unit, not a language code plus one or two subtags. I haven't done much language code creation myself (User:-sche and User:Mahagaja and User:Metaknowledge do more), but my understanding is that often the first segment is a language or language family code and the second segment is an abbreviation of a name of the language. For instance, in gmw-cfr, the code for the Central Franconian language, the first segment gmw is the code for the West Germanic language family and the second segment cfr is from C for Central and Fr for Franconian.
In response to User:Gonnym, my desire was to have {{wikt-lang}} fully support both Wiktionary language codes and IETF language tags in the first parameter. The module would figure out which IETF tags map to which Wiktionary language codes, and in each template instance, it would use the Wiktionary code to create the anchor in the link and put the IETF tag in the HTML. Fortunately, from a cursory look at IETF tag formats in Module:Lang, there can be at most three ambiguities between Wiktionary codes and IETF tags, because all but three hyphenated Wiktionary codes have segments of three lowercase letters long and IETF language tags can only have second and third segments of two or four letters (region and script) or an x and 1-8 alphanumeric characters. So that's good, but the mapping might have to take subtags into account because there is not a one-to-one mapping between ISO codes and Wiktionary languages. Some ISO codes might map to different Wiktionary languages depending on which subtags are added to them.
Perhaps {{wikt-lang}} could support the IETF-tag-like etymology language codes, but dispense with the more bizarre categories of etymology language codes that I listed above. — Eru·tuon 01:11, 26 October 2020 (UTC)[reply]
Guys, please look at the actual code. Module:Language does not use the language code for links. It uses a table in Module:Language/data to fetch the data["languages"][code]["name"] and with it, build the wiki-link anchor. This is done in the linkToWiktionary() function in line 186 (live version). Stop bringing in Wikitionary codes into this disscussion as it's irrelevent, as are what other templates do or act. It's making a mess out of this one. --Gonnym (talk) 01:18, 26 October 2020 (UTC)[reply]
The Wiktionary language codes are involved because {{wikt-lang}} currently accepts them (well, at least some of them). They uniquely correspond to a Wiktionary language name, which is used in the output of {{wikt-lang}}. I guess it also accepts IETF tags with just a language subtag or a language subtag and private use subtag. The two- and three-letter Wiktionary codes are often valid IETF tags but the hyphenated Wiktionary codes aren't. For example, grk-pro is the Wiktionary code for Proto-Greek (which is called Proto-Hellenic on Wiktionary). There is no IETF tag for this language, though we could add some kind of extension tag as we have for some other reconstructed languages like Proto-Celtic (Wiktionary code cel-pro, IETF tag cel-x-proto). So {{wikt-lang}} creates a link to wikt:Reconstruction:Proto-Hellenic/dzéus#Proto-Hellenic (*dzéus). That's how Wiktionary codes are involved. — Eru·tuon 01:33, 26 October 2020 (UTC)[reply]
Wiktionary language codes also uniquely correspond to one language name that has headers in entries whereas ISO language codes do not. Many of these details are documented in Wiktionary:Language treatment. For instance, Albanian (sq) has headers in entries while its subvarieties Arbëresh (aae), Arvanitika (aat), Gheg(aln), and Tosk (als) are classified as etymology languages. All of these are valid ISO languages but they map to just one Wiktionary header. That is why my version of Module:Language/data placed the Wiktionary language name under the Wiktionary code, such as ine-pro, rather than the Wikipedia IETF code, ine-x-proto. But perhaps another organizational scheme, such as putting the language data under one of the several corresponding IETF tags, will work. — Eru·tuon 01:45, 26 October 2020 (UTC)[reply]
I'm really struggling here to understand if you are just not reading my comments. Wiktionary codes aren't involved in the creation of links - there isn't some kind of api call to that site to fetch data. The codes were written (possibly by you) to be keys in a table in Module:Language/data, which in turn provides the header text anchor that is used in the link. Using wiktionary language codes as keys here was a very bad design decision from the start. Readers aren't expected to know what some random website on the web decides to use. They should however know (if they choose to use codes in the first place), what the real ISO 639 language codes are for what language. Regardless of the conclusion of this discussion, that will be fixed and changed, as this is English Wikipedia and not Wiktionary. --Gonnym (talk) 02:18, 26 October 2020 (UTC)[reply]
I have been reading your comments but apparently I didn't grasp what you're saying and how it relates to your recent edits to Module:Language/sandbox and Module:Language/data. Yes, I was the one who created Module:Language and Module:Language/data (and {{wikt-lang}} and {{wt}}) and am perfectly aware that they are not making API calls to Wiktionary modules, especially because that's impossible, and that the Wiktionary language code, when it is used in the template, does not appear in the template output whenever Module:Language/data has an ISO language code or IETF tag to replace it with. Yes, when I created Module:Language/data, the keys to the data table were Wiktionary language codes because that made it easiest to add the corresponding 1. language name used on Wiktionary and 2. entry name replacements ("replacements") field) derived from Wiktionary's language data modules. And allowing these Wiktionary codes as input in {{wikt-lang}} and {{wt}} seemed a natural thing since I am a Wiktionarian. (Furthermore it was easier because not all Wiktionary languages have ISO codes, for instance most or all of the proto-languages whose Wiktionary codes end in -pro.) But I get now that that was a bad idea. I'm still not clear on how you plan on organizing the Wiktionary language names and entry name replacements in Module:Language/data by IETF tag while accepting arbitrary subtags though. It seems to me that it would be easier to have an internal data module with the necessary data from Wiktionary language data modules indexed by Wiktionary language code and another data module that maps from IETF tags to Wiktionary code. — Eru·tuon 03:13, 26 October 2020 (UTC)[reply]
This TfD is not about Module:Language but is about {{wt}} which you propose to replace with {{Wikt-lang}} ostensibly because {{wt}} does not add the html Lang="" attribute and does not italicize Latin words. The lang= attribute must not use Wiktionary-specific language tags if those tags are not valid IETF language tags.
—Trappist the monk (talk) 11:19, 26 October 2020 (UTC)[reply]
Comments: 1) combining the templates by adding a parameter to the main one to allow suppression of redundant / nested tags seems like a good idea, once the other differences (pertaining to language code handling) are worked out; 2) to avoid having to accommodate Wiktionary's language codes, could the template(s) just accept the "header name" as a parameter in cases where it differs from what would be expected based on the ISO code, or where a language has not yet been encoded by the (still incomplete) ISO? For example, Gheg text could be tagged with the ISO code for Gheg but then accept a parameter "Albanian" since it should be linked to the #Albanian section of the relevant Wiktionary page, or indeed in that case the mapping of "ISO code aln" to "Wiktionary header Albanian" could be handled by the module without anyone needing to set a parameter each time they use the template, but a parameter might still be needed when linking to Wiktionary's entries on words in languages the (incomplete) ISO has not encoded yet. -sche (talk) 18:27, 27 October 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Pp-move

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 remove the icon at the very least for non-confirmed users, though if this is impractical/impossible then remove the icon altogether. Primefac (talk) 22:21, 4 November 2020 (UTC)[reply]

At a recent Village Pump discussion, there appeared to be desire to stop using this template since it's not useful for readers, but Barkeep49 (reasonably) declined the request for a formal closure at WP:ANRFC due to low participation, so I'm bringing it here.

As I see it, the case for deletion is that these icons are essentially bloat that do not add value in the same way as FA/GA icons and do not address a common action users might want to perform the same way as normal protection icons. For those who really do want to know, the move protection status of an article is listed in the "page information" sidebar link. They are also inconsistently and sparsely used (less than 2000 transclusions).

Pinging prior participants from the pump: @ProcrastinatingReader, GhostInTheMachine, and Amorymeltzer: {{u|Sdkb}} talk 04:29, 11 October 2020 (UTC)[reply]

Support not usefull for readers our purpose. That said in 2011 we talked about having all editor info icons only there for registered logged-in users..... I would support this even more.--Moxy 🍁 04:43, 11 October 2020 (UTC)[reply]
  • Support removing the icon in template There are two issues here. The first, using {{pp-move}} for indef move protection ({{pp-move-indef}} should be used instead, which only categorises rather than showing the lock). That's the first stage, which cleans up much of the issue. A bot can do that. The second is whether the remaining temporary few should have locks. I think no, since the indicator is useless for any purpose. It's just bloat. The template should be kept for categorisation purposes (Petscan can't filter by protection), but the icon should be removed. ProcrastinatingReader (talk) 16:14, 11 October 2020 (UTC)[reply]
  • Delete The icon does not add anything. As a reader, I don't care. As an editor, I do not see a move option on the menu and that is enough of a clue. — GhostInTheMachine talk to me 10:09, 12 October 2020 (UTC)[reply]
Perhaps best to advertise this talk on the policy noticeboard. The isolation of the deletion board from the wider community may not hold water in cases like this.--Moxy 🍁 01:07, 16 October 2020 (UTC)[reply]
Moxy, when I originally proposed suppressing the icon it was at VPR with a bunch of advertisements on talks. Discussion linked in nom. I think the consensus is people don't care, which fits in pretty well with my hypothesis that the icon is not helpful. ProcrastinatingReader (talk) 03:58, 17 October 2020 (UTC)[reply]
I think the point is that there are very real behavior considerations, and a poorly-attended forum or abrupt deletion is not a great way to say "hey that thing everyone's been doing that lines up with other behaviors is different now." Or, to quote Barkeep49 (link): Too little participation to make a change to a project-wide practice of such longstanding. ~ Amory (u • t • c) 15:12, 18 October 2020 (UTC)[reply]
Amorymeltzer Maybe. But there's also the idea that we cannot wait forever for large quorums. On matters of little interest to editors they will never come, and in the meantime we wouldn't be able to do any work on improving anything. It's near 2 months since my highly advertised discussion, that was left open for quite some time. I think this template is just a piggyback onto the mainstream protection banners (those I imagine do have support - thought experiment: if I nominated {{pp-extended}}/sent to VPR, how long would it take till SNOW close?). Difference between these is: 99% of the actions on articles are edit rather than move. And move is also only limited to autoconfirmed users, which is a very small subset of total registered users, which is itself a very small subset of total (incl unregistered) users. However, both those groups are affected by edit protection, but none by move protection. So: we're showing a protection banner to everyone for something that only affects the minority of editors, for relatively rare actions anyway. So in my eyes it just feels like bloat. Obviously I recognise that it may be helpful to some, it's a big encyclopaedia with lots of editors doing different things, but I just cannot see how it provides anything over either 'Page information' or the absence of move button.
At minimum, CSS styling to hide the move icon only from non-logged-in/non-autoconfirmed is helpful, since this doesn't affect them at all, and maybe it'd also be sufficient (maybe also combined with the {{pp-move}} -> {{pp-move-indef}} I describe above). So that's an alternative proposal. ProcrastinatingReader (talk) 16:14, 18 October 2020 (UTC)[reply]
  • Largely paraphrasing myself, but literally no protection icon is useful to someone classified as "just a reader," so I don't think that argument should carry too much merit; a different discussion about whether all protection topicons should be account-/autoconfirmed-only could be worth having, but this isn't it. With that in mind, I don't see the harm. Protection-based icons only show if there's just protection, so when they're visible it's an indicator of status that would normally be unexpected. Indeed, it could be argued that the move topicon is more helpful since the "move" menu option is not immediately visible on Vector. Low transclusion count is a good thing, meaning any "harm" is rare, and means move protection is even more a surprise. ~ Amory (u • t • c) 15:23, 18 October 2020 (UTC)[reply]
  • Delete, it is no use to a reader and editors can find out when they attempt to move and find the button isn't there. I would also support deleting all other protection topicons for the same reasons — WT79 (speak to me | editing patterns | what I been doing) 18:29, 18 October 2020 (UTC)[reply]
  • Remove the icon from the template. The semi/30-500/full/upload/template-protected templates are helpful for everyone. The only real use might be when the page has a 30-500 move-protection (yes, the green icon does appear if that protection is set). (CC) Tbhotch™ 15:45, 20 October 2020 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: I am relisting mainly to get an opinion on whether this template should be deleted outright, and if so what to replace it with; if not, can/should it be redirected to {{pp-move-indef}}?
Please add new comments below this notice. Thanks, Primefac (talk) 01:45, 25 October 2020 (UTC)[reply]
  • For clarity (and regarding relisting comment): It cannot be redirected, as this template can sometimes be used for temporary protections, which that module cannot deal with. Perhaps if that module is edited to support non-indef better, then we could make both of these use the same underlying module. Similarly, it cannot be deleted outright because it adds protection categories for temporary move protections. Those categorisations are helpful, along with the general Module:Protection banner ones, for example because Petscan cannot filter by protection otherwise. I don't know if MusikBot adds move protection templates like it does edit protections, but regardless, the template itself isn't a problem. My nomination at VPR, and my support here, is solely to edit the template and remove/hide the indicator it is creating (technically speaking, this will require a slight change to Module:Protection banner), but not to delete the template outright. A structural change may be appropriate to condense these further, if only being used for categorisations, but Mr. Stradivarius would know more about that than I.
    In light of Amory's comments above, I also think adding a ".autoconfirmed-show" class to the indicator may do the trick. Thus leaving the icon in view to people who may care about it, but hiding it from all those who can't move anyway. Issue is, TfD is an awful venue to decide between proposals, and deciding which would be best suited for the wiki. I am happy with any of them, as long as unregistered editors / non-autoconfirmed don't have to see this icon anymore. ProcrastinatingReader (talk) 12:34, 25 October 2020 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2020_October_25&oldid=1251726461"