Wiktionary

Wiktionary:Votes/2017-07/Templatizing topical categories in the mainspace 2

< Wiktionary:Votes

Templatizing topical categories in the mainspace 2 edit

Voting on: Templatizing the markup for topical categories in the mainspace with one of two particular templates, {{cat}} or {{c}}. Thus, giving a full go ahead to all automatic and semiautomatic edits that replace the likes of "[[Category:nl:Mammals]]" with "{{cat|nl|Mammals}}" or "{{c|nl|Mammals}}". Note that the templates support multiple parameters, such as {{c|nl|Mammals|Zoology}}. Note that, currently, {{c}} is a redirect to {{topics}}. This proposal is about using templates for this purpose in general, and also about the particular template names to appear in wikitext in the mainspace.

Schedule:

Discussion:

Support for cat edit

  1.   Support --Daniel Carrero (talk) 22:17, 6 August 2017 (UTC)[reply]
    I like {{cat}}, like the alias "Cat" for categories. Typing {{cat|en|dogs}} seems similar to typing [[Cat:en:Dogs]]. --Daniel Carrero (talk) 22:17, 6 August 2017 (UTC)[reply]
  2.   Support -Xbony2 (talk) 01:37, 9 August 2017 (UTC)[reply]
  3.   Support, same reasons as in the previous vote. — Vorziblix (talk · contribs) 18:07, 10 August 2017 (UTC)[reply]
  4.   Support Ƿidsiþ 12:32, 12 August 2017 (UTC)[reply]
  5.   Support, the main reason being sortkeys. —Aryaman (मुझसे बात करो) 14:39, 28 October 2017 (UTC)[reply]
  6.   Support; this is consistent with the Chinese specific template {{zh-cat}}. — justin(r)leung { (t...) | c=› } 21:58, 28 October 2017 (UTC)[reply]
  7.   Support Lingo Bingo Dingo (talk) 12:15, 30 October 2017 (UTC)[reply]
  8.   Support – Because (as @Daniel Carrero says above) {{cat|en|Languages}} is similar to [[CAT:en:Languages]], I think it makes sense as a name for the template that generates language code–prefixed categories. — Eru·tuon 18:16, 3 November 2017 (UTC)[reply]
  9.   Support. Better than {{c}}, worse than {{topics}}, much better than [[Category:]]. — Ungoliant (falai) 15:48, 9 November 2017 (UTC)[reply]
    @Ungoliant MMDCCLXIV If you want {{topics}}, you should vote oppose like I did. —Rua (mew) 15:56, 9 November 2017 (UTC)[reply]
    I’d rather settle for a smaller improvement than insisting on one that is not likely to pass. — Ungoliant (falai) 16:08, 9 November 2017 (UTC)[reply]
    Indeed, {{topics}} had only one support in Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace, and 6 opposes. I find {{topics}} a fine name, but it is unlikely to gain 2/3-supermajority. {{cat}} seems to be an okay name, especially since its functions can be expanded to handle non-topical categories as well, as indicated on the talk page of the vote. --Dan Polansky (talk) 16:43, 10 November 2017 (UTC)[reply]
  10. Conditional   Support if an admin volunteers to fork a local version of HotCat to support the new template. It's not particularly hard to do, just requires careful testing; the code is doing simple regexp replacements - see the logic for HotCat.category_canonical and HotCat.category_regexp in https://commons.wikimedia.org/wiki/MediaWiki:Gadget-HotCat.js Tetromino (talk) 08:01, 27 November 2017 (UTC)[reply]
  11.   Support As long as {{c}}, {{cat}}, and {{topics}} all work, I really don't care which one is the primary name. I definitely support letting bots get rid of bare links though. —Mahāgaja (formerly Angr) · talk 10:54, 18 December 2017 (UTC)[reply]
  12.   Support I don’t care either about which is chosen, but I support getting rid of the vulgar syntax categories because they are ugly and take multiple lines with long names while the {{C}}, {{c}} and {{cat}} templates look fair. Palaestrator verborum (loquier) 17:37, 19 December 2017 (UTC)[reply]
  13.   Support, though I would prefer "category" as the default. Andrew Sheedy (talk) 23:38, 27 December 2017 (UTC)[reply]
  14.   Support —Μετάknowledgediscuss/deeds 00:45, 28 December 2017 (UTC)[reply]
    Late support. A near supermajority wishes to have this templatized; actually, some sort of templatization (albeit under a different name) is supoorted by a full supermajority as evidenced in this vote. Templatization is going to bring minor benefits. MediaWiki:Gadget-HotCat.js can be forked to support the template, as pointed out above. "topics" is a name unequivocally rejected in another vote; "cat" is a good name for the purpose, and the template can be extended to produce non-topical categories as well if there is such a requirement. --Dan Polansky (talk) 10:11, 3 February 2018 (UTC)[reply]

Oppose for cat edit

  1.   Oppose DonnanZ (talk) 20:03, 8 August 2017 (UTC)[reply]
    @DonnanZ: Could you please clarify why you oppose this? Is it because you consider it too long? (You seem not to oppose {{c}} and {{C}}.) --Dan Polansky (talk) 18:22, 31 October 2017 (UTC)[reply]
    I am all in favour of shorter template names, which is why I support {{c}} rather than {{cat}}. But if {{c}} causes problems for some users I have no objection to {{cat}} being used by them. I trust that {{c}} and {{cat}} are intended to be options chosen by the user, and it's not an either/or situation, where one of them wins. But I don't want to use {{cat}} myself. And I don't use HotCat. DonnanZ (talk) 17:18, 1 November 2017 (UTC)[reply]
    @DonnanZ: The proposal of the vote is to give a go ahead to certain replacements; it is not to force users to use a particular template name. If this particular proposal passes (very uncertain), you should still be able to use {{c}} but someone else may feel free to change that to {{cat}}. If {{c}} gets deprecated (not part of the proposal as written), that's going to be a different story. --Dan Polansky (talk) 17:46, 3 November 2017 (UTC)[reply]
  2.   Oppose. Not at all indicative of function. Yes, it categorises, but it's specifically for topical categories. Thus, {{topics}} makes more sense. Compare {{categorize}}, which is a general categorizing template. {{cat}} should redirect to {{categorize}}. —CodeCat 20:10, 8 August 2017 (UTC)[reply]
  3.   Oppose. It will mess up MediaWiki:Gadget-HotCat.js —Internoob 01:12, 27 August 2017 (UTC)[reply]
    Wouldn't that already be messed up with the use of {{topics}} or am I missing something? -Xbony2 (talk) 12:56, 27 August 2017 (UTC)[reply]
    Yes, any categories added through templates are not editable through HotCat. I mainly disagree with the go-ahead for all automatic and semi-automatic edits that replace [[Category:]] with {{cat}}, because that only takes away my ability to edit those with HotCat. —Internoob 00:21, 3 September 2017 (UTC)[reply]
  4.   Oppose per internoob.Dixtosa (talk) 07:53, 25 November 2017 (UTC)[reply]
  5.   Oppose This is not, by any means, what templates were meant for. I may be late to the party (and I may also be a lone dissenter in this respect) but this is really getting kind of ridiculous. At least things like {{label}} has the """justification""" of CSS customization, but there is no purpose for this but to save.... let me count... five characters. Five. Or seven if you prefer {{c}}, which is even worse since it's not obvious at all what "c" stands for. Because apparently WP:PAPER doesn't apply to Wiktionary. Who knew? — ObſequiousNewt — Geſpꝛaͤch — Beÿtraͤge 17:30, 13 December 2017 (UTC)[reply]
    @ObsequiousNewt: In addition to saving five characters, the templates also add the correct sortkeys using the makeSortKey function in Module:languages. That is not very important for English, because sortkeys are regularly identical to page names, but it is for Ancient Greek and quite a few other languages. — Eru·tuon 20:38, 13 December 2017 (UTC)[reply]
    @Erutuon: This boils down to normalization, which strikes me as the kind of thing that should be done on the MediaWiki end rather than here. — ObſequiousNewt — Geſpꝛaͤch — Beÿtraͤge 02:35, 14 December 2017 (UTC)[reply]
    @ObsequiousNewt: Certainly, but until an appropriate MediaWiki extension comes out, we have to do sortkey generation ourselves. (What sortkey generation involves depends on the language: see Module:vi-sortkey, Module:zh-sortkey, and Module:cop-sortkey for some odder examples.) — Eru·tuon 02:47, 14 December 2017 (UTC)[reply]
    @Erutuon: I don't think sortkey generation is really worth the trouble. I especially don't think it's worth the trouble of replacing all category links. — ObſequiousNewt — Geſpꝛaͤch — Beÿtraͤge 02:49, 14 December 2017 (UTC)[reply]
    @ObsequiousNewt: Well, I disagree, and I (and maybe others) have already been templatizing Ancient Greek categories. Without sortkeys, the sort order would be strange, and categories would be difficult to use. There would be headings for accented letters from the Greek and Coptic or Greek Extended blocks along with the unaccented letters. ἀνήρ would be alphabetized after the heading for ω, because ω is in the Greek and Coptic block and ἀ in the Greek Extended block. ἄλλος would follow ἀνήρ, because ἄ (U+1F04) has a codepoint greater than ἀ (U+1F00). ἆθλον would come last. (That's the opposite of the expected order, ἆθλον < ἄλλος < ἀνήρ < ω.) That seems intolerable to me, so I am willing to always add categories using templates. — Eru·tuon 04:25, 14 December 2017 (UTC)[reply]
    I think that first sentence should be immortalized. I think it should be put in a box and displayed as the heading of the Votes page. — ObſequiousNewt — Geſpꝛaͤch — Beÿtraͤge 06:41, 14 December 2017 (UTC)[reply]
    @ObsequiousNewt: Yes, the vote description doesn't clearly describe the current state of affairs and what would change (if that's what you mean). Practically, what the vote would do is to make official one shortcut, {{c}} or {{cat}}, for {{catlangcode}}, and to allow bots to substitute bare category links with templates. Right now, people can use any shortcut for the template, and bots can only templatize categories by request of the editors of a particular language (as was done with many or all Vietnamese category links). — Eru·tuon 21:56, 18 December 2017 (UTC)[reply]
    I feel this is not what the Newt meant/is concerned with... --Rerum scriptor (talk) 02:23, 20 December 2017 (UTC)[reply]
    Ah, I should have asked. — Eru·tuon 04:13, 20 December 2017 (UTC)[reply]
  6.   Oppose Kaixinguo~enwiktionary (talk) 16:11, 19 December 2017 (UTC)[reply]
  7.   Oppose - TheDaveRoss 16:22, 26 December 2017 (UTC)[reply]
  8.   Oppose, not worth it. --Robbie SWE (talk) 15:23, 28 December 2017 (UTC)[reply]
  9.   Oppose Per Rua (name of the template), Internoob (HotCat) and ObsequiousNewt. I've done some replacements of plain cats to {{c}} myself, but I shouldn't have. --Barytonesis (talk) 14:01, 30 December 2017 (UTC)[reply]

Abstain for cat edit

  1.   Abstain Prefer to keep as is. --Victar (talk) 19:18, 1 November 2017 (UTC)[reply]
    @Victar: In Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace, you said "Would support {{cat}}". Have you changed your mind? --Dan Polansky (talk) 17:41, 3 November 2017 (UTC)[reply]

Support for c edit

  1.   Support -Xbony2 (talk) 01:37, 9 August 2017 (UTC)[reply]
  2.   Support, same reasons as in the previous vote. — Vorziblix (talk · contribs) 18:07, 10 August 2017 (UTC)[reply]
  3.   Support - better than {{cat}} and much better than {{topics}}. DonnanZ (talk) 09:21, 19 August 2017 (UTC)[reply]
  4.   Support Lingo Bingo Dingo (talk) 12:15, 30 October 2017 (UTC)[reply]
  5.   Support As long as {{c}}, {{cat}}, and {{topics}} all work, I really don't care which one is the primary name. I definitely support letting bots get rid of bare links though. —Mahāgaja (formerly Angr) · talk 10:54, 18 December 2017 (UTC)[reply]
  6.   Support I don’t care either about which is chosen, but I support getting rid of the vulgar syntax categories because they are ugly and take multiple lines with long names while the {{C}}, {{c}} and {{cat}} templates look fair. Palaestrator verborum (loquier) 17:37, 19 December 2017 (UTC)[reply]

Oppose for c edit

  1.   Oppose. Same as above, except worse. —CodeCat 20:11, 8 August 2017 (UTC)[reply]
  2.   Oppose. It will mess up MediaWiki:Gadget-HotCat.js —Internoob 01:12, 27 August 2017 (UTC)[reply]
  3.   Oppose. Same as above. Also opposed to case-sensitive templates. --Victar (talk) 19:18, 1 November 2017 (UTC)[reply]
  4.   Oppose Kaixinguo~enwiktionary (talk) 16:10, 19 December 2017 (UTC)[reply]
  5.   Oppose - TheDaveRoss 16:22, 26 December 2017 (UTC)[reply]
  6.   Oppose, still not worth it. --Robbie SWE (talk) 15:24, 28 December 2017 (UTC)[reply]
  7.   Oppose Per Rua (name of the template), Internoob (HotCat) and ObsequiousNewt. I've done some replacements of plain cats to {{c}} myself, but I shouldn't have. --Barytonesis (talk) 14:01, 30 December 2017 (UTC)[reply]

Abstain for c edit

  Abstain for the present. What's wrong with {{C}}? DonnanZ (talk) 20:05, 8 August 2017 (UTC)[reply]

@DonnanZ: {{C}}, in contrast to {{c}}, is capitalized for no obvious reason. We have {{m}}, {{lb}}, {{l}}, {{ux}}, etc., not {{M}}, etc.
Furthermore, {{C}} in capital did not make it in Wiktionary:Votes/2017-05/Templatizing topical categories in the mainspace; I opposed there on account of the wrong capitalization. {{c}} in lowercase still has a chance. --Dan Polansky (talk) 07:45, 19 August 2017 (UTC)[reply]
What you really mean is "no consensus", it didn't fail. I am now supporting {{c}}. DonnanZ (talk) 09:35, 19 August 2017 (UTC)[reply]
  1.   Abstain —Aryaman (मुझसे बात करो) 14:39, 28 October 2017 (UTC)[reply]
  2.   Abstain — justin(r)leung { (t...) | c=› } 21:58, 28 October 2017 (UTC)[reply]
  3.   Abstain – I've used {{c}} and {{C}}, but I don't know if they really are intuitive names, or if the names are best used in this way. — Eru·tuon 18:18, 3 November 2017 (UTC)[reply]

Decision edit

  • Previous votes on this subject had more participants, so I would like to extend the vote. I know there is some opposition to extensions. --Dan Polansky (talk) 14:57, 8 October 2017 (UTC)[reply]
    I extended it to November 28, 2017, per your request, if no one minds. To be extra clear: I, personally, support extending the vote. --Daniel Carrero (talk) 04:40, 28 October 2017 (UTC)[reply]
    I extended it further to 28 December 2017. The result is tight (9:4), the last oppose was on 25 November 2017, and having the vote end on 28 Nov would expose the original extension to the accusation of being done to fish for the desired outcome. I propose to use the following extension mechanism on this vote: "If at least one new vote was cast to the vote in the last extension period, extend further by one more month, unless 6 months have already passed". --Dan Polansky (talk) 09:43, 26 November 2017 (UTC)[reply]
    I support extending the vote further this time, but unfortunately I'm not a fan of that specific extension mechanism for this or any other votes. Although it wasn't tested in practice yet, this is my first impression: If that's the only allowed extension mechanism, it's too bad that it does not tell us when to start extending a vote. For votes that were never extended, there's no "last extension period", so that rule would result in 0 votes being extended. But if there's any other secondary rule allowing the first vote extension, it seems trivial to wait for more people to cast at least 1 vote each month (especially if we ask at the BP like I did here), so it's likely that many or most extended votes would end up lasting exactly 6 months.
    I would prefer having a extension mechanism close to this: "If the current support results are between 40% to 70% (or between 60% and 70% if that's too much), invariably extend by 1 month, unless 6 months have already passed." Reason: It's to avoid "no consensus" rulings, when a few more votes could more easily tip the balance into clear support or clear oppose. As you said, right now the result for the result is tight (9:4 = 69.23%; 4:3 = 57.14%). That's why I support extending this vote. --Daniel Carrero (talk) 10:38, 26 November 2017 (UTC)[reply]
    The advantage of the mechanism I proposed is that it has no bias toward pass or fail, and therefore, it cannot be accused of having built-in fishing for a pass. As for "it's likely that many or most extended votes would end up lasting exactly 6 months", that would have to be borne out by experience. The algorithm is there only for votes that were extended at least once, and it leaves it unspecified under which conditions the first extension can take place. --Dan Polansky (talk) 10:46, 26 November 2017 (UTC)[reply]
    I acknowledge that advantage you mentioned as correct: "it has no bias toward pass or fail, and therefore, it cannot be accused of having built-in fishing for a pass".
    I understand that it leaves it unspecified under which conditions the first extension can take place. It does not have to be a bad thing at all. I also understand you proposed this extension mechanism for this specific vote, where the first extension already happened and thus the question "When the first extension can take place?" does not apply. It's just something that in my opinion is a good idea to say explicitly: for future votes, it would be nice to answer that question in some way if possible.
    If there's no first-extension rule, then votes are extended and non-extended with some degree of randomness. The accusation of "fishing for votes" can be rewritten as this obviously bad extension mechanism: "Whenever the vote does not have the result I like, extend." I hope someday we can agree on an actual extension mechanism consistently applied to all votes to counter this. In all or many extended votes where I supported extension, what sold it to me was that the result was unclear prior to the extension. Which lead me to my idea above. (to repeat: when a few more votes could more easily tip the balance into clear support or clear oppose)
    As for "it's likely that many or most extended votes would end up lasting exactly 6 months", there is some experience: whenever I ask at the BP for people to vote to break a tie or to increase the turnout, people vote. Current results are 100% (that is, at least 1 people voted after I asked that). But that's from memory and I didn't get actual links and vote examples. Some exception could have happened which I forgot. My point is, I or other people can probably cause a vote to be extended whenever we want by asking people to vote (up to some reasonable limit).
    Consider game theory: That mechanism ("if 1 vote was cast last month, then extend") has a bias towards "no consensus". It works like this: if I did not vote yet, and I want to support the vote, but nobody voted this month and the vote already has a majority of support, I can't vote "support", lest I risk extending the vote and allowing other people to vote oppose next month. In other words: Waiting, not voting, is optimal if I agree with the current result. Voting, not waiting, is optimal is I disagree with the current result. This is true until someone votes this month, but we will invariably have to wait for a whole month (until six months have passed) where nobody voted and for that period this will be true again. Hence there's some bias towards changing whatever is the current result and drifting toward "no consensus". --Daniel Carrero (talk) 12:43, 26 November 2017 (UTC)[reply]
    I don't see any bias towards no consensus in the proposed mechanism. I think the reasoning presented is incorrect. That speculative waiter you posit would have as the best strategy to wait until, say, one day before the current end of the vote to see whether other people have already ensured extension, and then vote accordingly. I find such speculative waiters unlikely, but even if they turned out to be real, their existence would not swing the vote toward no consensus. --Dan Polansky (talk) 15:56, 26 November 2017 (UTC)[reply]
  • "Cat" has no consensus 14–9–1 (61%). "C" fails 6–7–3 (46%). —Μετάknowledgediscuss/deeds 18:38, 30 December 2017 (UTC)[reply]
  • In my opinion {{c}} also has no consensus. DonnanZ (talk) 16:49, 6 January 2018 (UTC)[reply]
    Perhaps you don't understand. We use the terminology of "no consensus" only in cases where there is more support than opposition, but not enough for something to pass. —Μετάknowledgediscuss/deeds 02:35, 7 January 2018 (UTC)[reply]
    I think that has been interpreted differently in other votes. The vote for {{c}} was actually 6-7-3. DonnanZ (talk) 12:09, 7 January 2018 (UTC)[reply]
    I've corrected my tally to include your vote change. Just so you realise, abstentions don't count toward any of this, and no, it has not been interpreted differently in other votes for many, many years. —Μετάknowledgediscuss/deeds 14:58, 7 January 2018 (UTC)[reply]
    What Metaknowledge said: "no consensus" is applied for votes that would pass under a plain-majority rules; "fail" is applied to votes that fail even under a plain-majority rule. Abstentions don't count, now as before. --Dan Polansky (talk) 10:15, 3 February 2018 (UTC)[reply]
    Everybody, please read the intro of Wiktionary:Votes/Timeline for an explanation of "no consensus". --Daniel Carrero (talk) 12:40, 3 February 2018 (UTC)[reply]
    That says "When vote didn't pass, and the number of supports is approximately between 40% and 66.6% (or higher), the vote has "no consensus" as the result listed here ...": That's not how I remember our practice. The 40% got there via diff and there was 50% before; the diff does not trace the edit to any discussion or vote. --Dan Polansky (talk) 12:55, 3 February 2018 (UTC)[reply]
    Here's the discussion: Wiktionary:Beer parlour/2016/August#Wiktionary:Votes/Timeline. There, I said I organized the timeline in such a way with a detailed report and nobody objected to it. There's no rule stating that the "No consensus" in vote pages have to start from 40% or 50%. It's just that the timeline currently uses 40% for all votes because that's how I edited it. I would object to having a 50% threshold. If the result of some vote is 4-6, that seems a clear "no consensus" to me, not "failed". It's too close to a balanced 5-5 in my opinion. Was the 50% ever discussed or voted? --Daniel Carrero (talk) 13:21, 3 February 2018 (UTC)[reply]
    Thank you. I object to the 40% figure. In that BP discussion, only two other people participated, and it is not obvious that the 40% figure reached their attention since the figure was not at the center of the thread. 50% was not voted in, but it is, as far as I remember, our common practice. Whether it is or it is not our common practice can be determined from past votes, but I feel disinclined to do so. Incidentally, I think that kind of text does not belong to Timeline page at all. --Dan Polansky (talk) 13:25, 3 February 2018 (UTC)[reply]
    On a marginal note, I preferred the simple formatting at this revision; when I saw the tables, I disliked them, but decided that was a fight I would not choose to fight, among all the other changes that I find detrimental and that take place in Wiktionary. --Dan Polansky (talk) 13:29, 3 February 2018 (UTC)[reply]
Just as well this wasn't the UK EU referendum with a 52/48% split, where we are now faced with the prospect of leaving the EU. I would interpret the result as a situation where users are able to use whichever they prefer, {{cat}} or {{c}}. I will carry on using {{c}} DonnanZ (talk) 13:40, 3 February 2018 (UTC)[reply]
Alright, I understand you (Dan Polansky) object to the 40% figure. We may want to discuss/vote about the threshold as a community and create a proper rule to Wiktionary:Voting policy. I would support having some actual rule for this. Even though, as we know, both "failed" and "no consensus" mean the same thing in practice -- that whatever is proposed in a certain vote does not happen or get implemented at all.
You said common practice can be determined from past votes, so I'd like to comment about this. In the timeline, there are currently 742 votes, of which 114 are "no consensus". The "no consensus" currently starts at 40% because of my edits. It's roughly a 7:1 ratio. A minority of votes are "no consensus" votes. (This may not include votes with multiple options, with reported results in the timeline like "option 3 passed" where it's not clear whether options 1 and 2 are "failed" or "no consensus".)
I suppose a bot could give an accurate report of uses of "failed" and "no consensus" by reading all these 114 pages, looking for instances of these two character strings and counting the number of votes per page.
Aside from that, I already took the time to read all the 742 votes. Most of those I read in 2016, for the purpose of editing the timeline. To be precise, I quickly visually scanned them and skipped some repetitive things like tons of support in admin votes, but I paid a lot of attention to the vote numbers and results. From my inexact human memory, I can say this: The few votes that did have results around 50% to 66% seemed to randomly vary around "failed" and "no consensus" without consistency. So a vote with (for example) 58% support still seemed to have a good chance of being marked either "failed" or "no consensus" if we count all those years since the first vote in 2003. A bot can probably confirm this as said above. I'm pretty sure there was at least one vote with more than 66,6% which did NOT pass for some reason, but I didn't remember which vote.
P.S.: There's a bit of a conversation about the 40% at the end of Wiktionary:Votes/2017-07/Rename categories. --Daniel Carrero (talk) 14:06, 3 February 2018 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Votes/2017-07/Templatizing_topical_categories_in_the_mainspace_2&oldid=48779557"