Jump to content

Wiktionary:Votes/2019-06/Language code into reference template names

Add links
From Wiktionary, the free dictionary

Language code into reference template names

[edit]

Voting on: Renaming reference templates including those used for further reading to contain language code in their name, as long as the language code can be meaningfully determined. Thus, for instance, renaming {{R:Webster 1913}} to {{R:en:Webster 1913}}, {{R:OneLook}} to {{R:en:OneLook}}, {{R:DRAE}} to {{R:es:DRAE}}, {{R:TLFi}} to {{R:fr:TLFi}}, and {{R:Duden}} to {{R:de:Duden}}, with the caveat that the part of the new name after the second colon does not need to be the same as the original name if desired.

Schedule:

Discussion:

@Dan Polansky has taken it upon himself to enforce this vote as if it was to put into effect a policy to ban the moving of any and all reference templates to names with language codes. It is not. This vote has been worded as a vote to systematically move all reference template those with language codes. If a ban was his intention of this vote, then a follow-up vote should be started explicitly stating that intent. @A12n, Cnilep, Daniel Carrero, Donnanz, Fay Freak, Jberkel, JohnC5, Lingo Bingo Dingo, Mahagaja, PseudoSkull, Sgconlaw, Suzukaze-c, Vahagn Petrosyan, Xbypass, פֿינצטערניש --{{victar|talk}} 08:44, 10 July 2019 (UTC)[reply]

That is a misrepresentation; there is no ban but there is also the principle that status quo ante prevails unless overriden by consensus. A discussion is at User talk:Victar#Adding language code to reference template names. This discussion does not belong to the top of this vote, and I do not know why Victar is posting here; I am not sure I should be responding here either. --Dan Polansky (talk) 08:58, 10 July 2019 (UTC)[reply]
Again, this vote does not state that no templates currently formatted without a language code will be forbidden from being moved due to "status quo", or any reason whatsoever. As such, I will continue to move whatever templates I feel best suit the templates I work with, regardless of this vote, and will recommend others do the same. --{{victar|talk}} 18:11, 11 July 2019 (UTC)[reply]
The above editor should stop skipping WT:RFM, a process that covers template moves; this is a concern that existed before this vote was created. When the above editor moves a template without RFM and consensus, other editors may naturally move the template back; the status quo ante prevails barring consensus. --Dan Polansky (talk) 20:11, 11 July 2019 (UTC)[reply]
I agree that RFM applies to each and every renaming. DCDuring (talk) 14:52, 18 July 2019 (UTC)[reply]
@DCDuring: That's absolute nonsense. Show me the rule that says all moves require a WT:RFM. --{{victar|talk}} 20:06, 18 July 2019 (UTC)[reply]
We live by our prevailing practices. If you like rules, try Wikipedia. DCDuring (talk) 20:08, 18 July 2019 (UTC)[reply]
"Prevailing practices" are unenforceable. If you wish to enforce something, I recommend you start a vote --{{victar|talk}} 20:15, 18 July 2019 (UTC)[reply]
This is an obstructionist position. Harankas (talk) 16:59, 23 July 2019 (UTC)[reply]
Which one? Yours? Victars? Mine? Something earlier? DCDuring (talk) 17:03, 23 July 2019 (UTC)[reply]
Obviously the one that says you are entitled to have it your way unless there is a vote stating you're not. Harankas (talk) 18:22, 23 July 2019 (UTC)[reply]
Nothing is obvious online. Obviously I don't see my position as "my way". I see it as the Wiktionary way. DCDuring (talk) 19:01, 23 July 2019 (UTC)[reply]
Fine, let me spell it out (I see that reading between the lines is not your strong suit): the position of the user Victar is obstructionist. Harankas (talk) 19:41, 23 July 2019 (UTC)[reply]

Support

[edit]
  1. Support Fay Freak (talk) 19:52, 14 June 2019 (UTC)[reply]
  2. Support —Suzukaze-c◇◇ 21:41, 14 June 2019 (UTC)[reply]
  3. Support —Mahāgaja · talk 06:52, 15 June 2019 (UTC)[reply]
  4. Support --{{victar|talk}} 00:44, 18 June 2019 (UTC)[reply]
    Nearly a third of all reference templates are not sorted into any language categories. This is obviously due to people being too lazy to add [[C:LANG reference templates]]. If we mandate a [[T:R:LANG:*]] format, when applicable, with the use of {{documentation}} and/or a bot, we could automatically add a reference templates category to those are are missing them. That's a really practical, and not pointless, reason to start mandating them. @Cnilep, PseudoSkull --{{victar|talk}} 21:19, 27 June 2019 (UTC)[reply]
    That's far from good enough a reason to start introducing this visual overhead into template names. The time spent putting the language code into the template names would be better spent putting the same templates into the proper language categories. We do the same with mainspace entries: they are put to categories rather than being put into a nested naming structure, like moving train into en/noun/train or even en/transportation/noun/train. --Dan Polansky (talk) 11:26, 28 June 2019 (UTC)[reply]
    You're welcome to that opinion, but it does not make it fact. Do I need to quote you again from below on how editors choose to spend their time is irrelevant to a vote? I'm looking at this from a future perspective, not a present one. People will continue in their human nature of being lazy -- this, I believe, can help offset that. --{{victar|talk}} 14:33, 28 June 2019 (UTC)[reply]
    Sure, and people's being lazy in categorizing mainspace entries could be offset by introducing en/transportation/noun/train. And people's being lazy in adding further reading to entries could be offset by deleting all entries that have neither attesting quotations nor further reading. I don't think this kind of bondage-and-discipline approach befits the spirit of the wiki. My general position is that people have every right to be lazy and work on the aspects of this wiki that they find interesting as long as it does not harm the project; providing further reading to monolingual sources everywhere would be much more useful than putting some templates into categories, and yet, I do not wish to impose that kind of duty on editors. --Dan Polansky (talk) 14:56, 28 June 2019 (UTC)[reply]
    Any mechanism that offsets laziness and brings greater utility to the project, I will vote for hands down, every time. If that doesn't suit you, who am I to argue. --{{victar|talk}} 15:07, 28 June 2019 (UTC)[reply]
    Erutuon, has already gone ahead and created a great little module for categorizing reference templates based on the lang code in their URL, {{T:refcat}}. Now we just need to get it added to the header to automate it completely. --{{victar|talk}} 16:45, 30 June 2019 (UTC)[reply]
  5. Support –– Jberkel 11:44, 22 June 2019 (UTC)[reply]
    @Jberkel: I did not ask the other supporters but could I perhaps ask you which rationale for the proposal do you find convincing? --Dan Polansky (talk) 12:43, 22 June 2019 (UTC)[reply]
    I like self-explanatory names. For example, if {{R:xyz:Foo}} is mentioned somewhere, and I don't work on language xyz, I can safely ignore it, and don't have to go to the the template page to figure out what language it is for. It's also consistent with the practice of prefixing templates/modules with language codes ({{it-IPA}}, {{fr-IPA}} etc.). And lastly, with 4000+ languages ambiguities will become more and more frequent as the project grows (this also affects {{RQ:}} where translated works need to be taken into account, {{RQ:Cervantes Shelton Don Quixote}}, {{RQ:Cervantes Viardot Don Quichotte}} etc). – Jberkel 13:55, 22 June 2019 (UTC)[reply]
    Thank you. Let me note that {{it-IPA}} and {{fr-IPA}} is not really analogous since there the language code is indispensable unless we want to provide the language via a parameter, like {{IPA|it|...}} or rather {{IPA-auto|it|...}} since {{IPA}} does take language code already but does not automatically produce pronunciation. --Dan Polansky (talk) 14:55, 22 June 2019 (UTC)[reply]
  6. Support --Vahag (talk) 18:13, 27 June 2019 (UTC)[reply]
  7. Support --Daniel Carrero (talk) 01:03, 5 July 2019 (UTC)[reply]
  8. Support —*i̯óh₁n̥C[5] 08:37, 6 July 2019 (UTC)[reply]

Oppose

[edit]
  1. Oppose. This seems a bit excessive. The only case I can think of where it may be handy is {{R:Dokpro}}, where lang=nb and lang=nn can be added. DonnanZ (talk) 12:03, 15 June 2019 (UTC)[reply]
  2. Oppose The current simplicity of most template names has worked well. I have seen two arguments in favor of the change: 1) Use the language code prefix for disambiguation, that is, make sure that templates for different languages can have the same name. As for that, name overlap is going to be rather rare, and can be addressed by various means, including using an alternative acronym or by adding a year to the template name. 2) The prefix makes it easier to find the template by typing R: plus the language code into the search bar. As for that, if you remember the beginning of the template name ("R:Web", "R:Dud"), you do not need a language prefix and you can type the beginning of the template name into the search bar and the search bar will show you possible templates ("R:Webster 1913", "R:Duden"). As for the case where you only remember the language, redirects can be created to help memory, like a redirect from {{R:de:Duden}} to {{R:Duden}}; furthermore, there are template categories by language, e.g. Category:German reference templates. As a final note, the template names without language codes look a little less like letter salad and more human, are shorter to type, and present no serious practical obstacles. They are more simple; let's make everything as simple as possible but not more simple. --Dan Polansky (talk) 07:31, 16 June 2019 (UTC)[reply]
    @Dan Polansky: Especially for templates I don't use so often, sometimes I can't remember even the beginning of the template name. Then it's just easier to type Template:R:ga: (or whatever) into the search box and see what pops up. That to me is simpler than going to CAT:Irish reference templates, since doing so requires me to open a new a tab in my browser. —Mahāgaja · talk 13:16, 16 June 2019 (UTC)[reply]
    @Mahagaja, nice pro tip! --{{victar|talk}} 02:49, 21 June 2019 (UTC)[reply]
    Sure, and this search box function would be provided by creating a redirect, e.g. from Template:R:ga:Dinneen 1904 to Template:R:Dinneen 1904, right? You can verify that this works with template:R:BTS, which was moved out of process to template:R:ru:BTS and the redirect is still there. --Dan Polansky (talk) 07:10, 22 June 2019 (UTC)[reply]
    Fair enough, but this vote isn't about moving templates that already have language codes in them to versions without the code. —Mahāgaja · talk 09:02, 22 June 2019 (UTC)[reply]
    Well, it isn't, but what's the point? Let me try again: Let us suppose you cannot remember the German reference template names. One way to help you (in reference to search box) is to move {{R:Duden}} to {{R:de:Duden}}, and that is the proposal of the vote. Another way to help you is to create a redirect from {{R:de:Duden}} to {{R:Duden}} without moving the template. This alternative shows that we do not need to move the template to help you, and therefore, I oppose the proposal since I do not like its bad consequences and its good consequences can be achieved by creating redirects. --Dan Polansky (talk) 09:24, 22 June 2019 (UTC)[reply]
    By the way, the template redirect from T: enables you to enter "T:R:Du" into the search box and find Duden; you do not need to type Template:. --Dan Polansky (talk) 09:52, 22 June 2019 (UTC)[reply]
    Let me make a note about economy. One argument made is that the prefix in the template name helps automatic categorization of the template. However, the categorization of a template is something you make once per template, while entering the template name into the mainspace is something you make thousand times, and you read the template name even more times; surely it is the entering into the mainspace that should be optimized. --Dan Polansky (talk) 20:05, 11 July 2019 (UTC)[reply]
  3. Oppose I tend to feel that language codes should be omitted where they don't add information to an entry or facilitate things like category sorting. Simplicity is usually best, in my opinion. Cnilep (talk) 06:27, 21 June 2019 (UTC)[reply]
  4. Oppose If I already know to use the reference template, I think I'd probably know the language it's for by that point. Including the code seems pointless to me and seems like clutter. PseudoSkull (talk) 00:09, 23 June 2019 (UTC)[reply]
  5. Oppose I don't think it makes sense to go and rename a bunch of templates to include language codes in their name when there are very few reference templates where this would make any sense. Such efforts would be better spent making Wiktionary easier to use for non-technically-minded people. פֿינצטערניש (Fintsternish), she/her (talk) 19:43, 26 June 2019 (UTC)[reply]
    @פֿינצטערניש: The time it would take to get a project done is never a valid reason not to vote for something and the productivity of one project does not take away from the productivity of another. To quote Dan, "[editors] should feel to dispose of [their time] as they see fit; we should not act as managers of other people's resources." --{{victar|talk}} 21:34, 27 June 2019 (UTC)[reply]
    At the same time this still means introducing an extra level of difficulty in using templates, and I oppose doing this; I think it is moving in the exact opposite direction as making the site easier to use for non-technical people. פֿינצטערניש (Fintsternish), she/her (talk) 21:43, 27 June 2019 (UTC)[reply]
    @פֿינצטערניש: Well, a) if you're too technically inept to add a language code to the URL, then I have bad news for them in creating the actual reference template, because that's the easiest part of it, and b) see my rational in my vote in this being a mechanism to actually help people that are doing a poor job of creating templates, i.e. the inept/lazy. --{{victar|talk}} 21:48, 27 June 2019 (UTC)[reply]
    Actually I voted pro because it will be easier when one does not have to remember whether a template one wants to use uses the language prefix or not. Hard to remember that it is {{R:L&S}} and not {{R:la:L&S}}. Fay Freak (talk) 00:10, 28 June 2019 (UTC)[reply]
    That is an argument in both directions: if some people did not start using the language code prefixes, everything would have been consistent and no one would need to remember which of the two inconsistent practices to use. Historically, it was the people who started to use the language code who introduced inconsistence into the reference template naming. --Dan Polansky (talk) 11:21, 28 June 2019 (UTC)[reply]
    That is not an argument in both directions. It insinuates to complete what some people have begun so it becomes consistent instead of keeping it inconsistent. You are voting for inconsistency and incomprehensibility. Fay Freak (talk) 19:09, 28 June 2019 (UTC)[reply]
    I mostly started using the format because we began simplifying some templates to their acronyms. Three letters and a language code is easier to remember than the spelling of an author's name and the year of publication, i.e. {{R:De Vaan 2008}} > {{R:itc:EDL}}. --{{victar|talk}} 05:30, 28 June 2019 (UTC)[reply]
    The space of three-letter acronyms is large enough (17 576 items); we don't need language code to disambiguate them. For the few cases where disambiguation will be required, switching to a four-letter acronym or another ad hoc disambiguation means can be used.
    And the above claim about what is easier to remember is empirically unsubstantiated and does not appear particularly obvious to me. For instance, {{R:Duden}} is super easy to remember. --Dan Polansky (talk) 11:28, 28 June 2019 (UTC)[reply]
    Did I say anything about overlap? I was merely stating what the catalyst for this change was in my case. My rationale for supporting the migration of references templates to this format is listed in my support vote. --{{victar|talk}} 14:28, 28 June 2019 (UTC)[reply]
    Without an implied overlap argument, the statement "I mostly started using the format because we began simplifying some templates to their acronyms" makes no sense. --Dan Polansky (talk) 14:57, 28 June 2019 (UTC)[reply]
    There are many reasons I could have given, like it being the defacto standard for creating new templates, but I gave none, and I'm not obliged to. You make assumptions of me. --{{victar|talk}} 15:04, 28 June 2019 (UTC)[reply]
    As said, the statement makes no sense without the overlap concern, and the above response makes me no wiser as to what else could make sense of the statement. --Dan Polansky (talk) 15:09, 28 June 2019 (UTC)[reply]
    Dan, I'm not here to make sense or justify my personal catalyst in this issue. All I wanted to say in that regard is in my upvote comment. --{{victar|talk}} 15:12, 28 June 2019 (UTC)[reply]
  6. Oppose ←₰-→ Lingo Bingo Dingo (talk) 14:22, 28 June 2019 (UTC)[reply]
    Clarification: I understand this oppose vote to mean opposition to mandatory inclusion of language codes, not support for banning any renaming to a name with a language code. ←₰-→ Lingo Bingo Dingo (talk) 08:54, 10 July 2019 (UTC)[reply]
    Indeed, this vote cannot ban renames. That said, renames are governed by the consensus principle via WT:RFM process, especially renames that are likely to be controversial. --Dan Polansky (talk) 09:37, 10 July 2019 (UTC)[reply]
  7. Oppose - I don't see any advantage SemperBlotto (talk) 08:49, 10 July 2019 (UTC)[reply]
    @SemperBlotto: for one. --{{victar|talk}} 08:54, 10 July 2019 (UTC)[reply]
  8. Oppose. I don't feel for having to type in an extra "az:", or, G-d forbid, "trk-oat:" Ketiga123 (talk) 14:05, 11 July 2019 (UTC)[reply]
  9. Oppose. Reasons: (1) It is shown that redirect is good solution. (2) More convenient for old editors. (3) I like short templates names. --Andrew Krizhanovsky (talk) 12:34, 18 July 2019 (UTC)[reply]
  10. Oppose Each and every template renaming should go through RFM. Redirects from the old names should remain if new names with language codes are created. DCDuring (talk) 14:52, 18 July 2019 (UTC)[reply]

Abstain

[edit]
  1. Abstain: no strong feelings either way. — SGconlaw (talk) 13:05, 15 June 2019 (UTC)[reply]
  2. Abstain: Sitting on the fence, at least for now. Nice idea in terms of orderliness of the reference library, as it were, but the case doesn't seem so strong. Main advantage I see is being able to tell the language which an R template serves. Otoh, not clear any advantage for references w/ multiple language targets. The potential advantage for automatic categorization seems offset by the amount of work needed to add the language codes - would it be any more work to just manually categorize R templates per relevant language(s) that are not so already? --A12n (talk) 12:58, 29 June 2019 (UTC)[reply]
    @A12n: I'm mostly looking towards the future for the automatic categorization feature, and adding R:LANG:NAME is easier than adding categorization manually. --{{victar|talk}} 16:42, 30 June 2019 (UTC)[reply]
    The initial amount of work needed to perform the template renaming is pretty manageable, I think, and if the proposal were in the other direction, i.e. removing the lang codes, I would volunteer. I think it is about what you want to see and type into the wikitext, whether e.g. {{R:de:Duden}} or {{R:Duden}}. I prefer the latter, and if I find a reference template used in a section ==German==, I don't think I need any hints as to the language; and if I find the template alone, the manual categorization will do the trick. The alleged advantage of automatic categorization seems bogus to me: it is only automatic after you have manually placed the language code into the template name. --Dan Polansky (talk) 21:03, 4 July 2019 (UTC)[reply]
  3. Abstain:Xbypass (talk) 15:52, 1 July 2019 (UTC)[reply]

Decision

[edit]
Fails 8-10-3. - TheDaveRoss 17:39, 13 August 2019 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Votes/2019-06/Language_code_into_reference_template_names&oldid=53870646"