Wiktionary talk:Votes/2015-11/term → m; context → label; usex → ux

Thoughts on wording and scope
These would be welcome from anybody in the community; I reckon might be especially interested. —Μετάknowledge discuss/deeds 06:02, 26 November 2015 (UTC)
 * I suggest separating the vote into two sections: 1) term->m and 2) context->lb (lb, not label, I'd prefer). I would support both. But I suspect the context template change has been less discussed than the term template, so I'd like to be sure that everyone is okay with each template separately. --Daniel Carrero (talk) 06:20, 26 November 2015 (UTC)

Vote rationale
I am moving the rationale from the vote here. --Daniel Carrero (talk) 14:29, 26 November 2015 (UTC)

"This vote is to formalise consensus regarding mass changes by bot from two commonly used templates that do not require language codes to be given, and, to their equivalents which do,  and  respectively. If this vote passes, it will be seen as authorising any bot operator to change these templates as described in cases where the language code is already given and thus is unambiguous, and will not require human editors to change their habits (although it is strongly recommended that they do so regardless). This is an important step in ensuring that all our links and categories moving forward are actually going to the language we want them to. —Μετάknowledge discuss/deeds 06:00, 26 November 2015 (UTC)"

label > lb
While I support changing to, I don't think it's any good to change  to. is simply a shortcut to, just as is a shortcut to. If we are going to force the use of the shortcuts, we might as well make the shortcut the main template, but I think it's better to just allow both. —CodeCat 15:56, 26 November 2015 (UTC)
 * I agree, and I think that oughtn't to be in the scope of this vote (this is about changing from templates that do not require language code to those that do, and nothing more). —Μετάknowledge discuss/deeds 16:05, 26 November 2015 (UTC)
 * That's fine by me. --Daniel Carrero (talk) 16:19, 26 November 2015 (UTC)
 * Thanks for the rest of the work you did on the vote, though. —Μετάknowledge discuss/deeds 17:36, 26 November 2015 (UTC)
 * You're welcome, thanks for creating the vote in the first place. --Daniel Carrero (talk) 14:52, 29 November 2015 (UTC)
 * I will oppose if the target is "label", but I will support if the target is "lb". Votes/2014-08/Templates context and label suggests that my preference for short template name is shared by more people than the opposite preference. --Dan Polansky (talk) 14:08, 29 November 2015 (UTC)
 * I also prefer as the target of the vote. If all uses of  and  are converted to  but all instances of  are left alone, then it's going to be weird when some entries have  and others have.
 * Similarly, is the shortcut to  and the vote currently uses the short name as the target. From my experience, nobody uses the longer name ; if they used, I'd suggest merging all uses of  into  alone. --Daniel Carrero (talk) 14:51, 29 November 2015 (UTC)
 * I added a sentence to address this; what do you think? I think a conditional vote would be appropriate in this case. —Μετάknowledge discuss/deeds 17:42, 29 November 2015 (UTC)
 * I think if lb is the most preferred template based on the available evidence, even if only by a relatively narrow margin, then lb should be positioned as the leading target, not as a secondary target. --Dan Polansky (talk) 17:54, 29 November 2015 (UTC)
 * and are the same template. —CodeCat 18:00, 29 November 2015 (UTC)
 * They are not the same markup. The markup matters. That is what some people apparently still don't get. --Dan Polansky (talk) 18:09, 29 November 2015 (UTC)
 * The proposal involves allowing a bot to edit basically all the 4,27 million entries to follow a certain standard; or, only those entries that have context labels.
 * Suppose we allow a bot to choose freely between label/lb.
 * Good news (in my opinion): it is a step in the direction of standardization, since context/cx would be deprecated.
 * But, bad news: basically, the bot owner would have the ability to unilaterally choose freely the markup that we are going to use, between label and lb.
 * Besides, lb is shorter than label. To put it a little more dramatically: label is 150% longer. --Daniel Carrero (talk) 22:44, 30 November 2015 (UTC)
 * You realise that a bot could simply convert to  and  to ? The bot doesn't have to make any choices. —CodeCat 22:46, 30 November 2015 (UTC)
 * Yes, it could, but it could also do something else. So it's still a choice. --WikiTiki89 23:05, 30 November 2015 (UTC)

label and lb as choices in the vote
I propose editing the vote to let people choose:


 * 1) support label
 * 2) support lb

If the vote is designed like that, I'd support lb. --Daniel Carrero (talk) 14:47, 30 November 2015 (UTC)
 * 2 days ago, added to the vote:
 * "Procedural note: Any uses of as described in this part of the vote may instead be changed to the shorter redirect  if there is consensus for that demonstrated on this vote or elsewhere."
 * I'd argue that if we make available in the vote the options "support label" and "support lb", this is a way to seek consensus about the syntax on the vote itself, which is a possibility stated in the procedural note. If we do it, I suppose we could delete the procedural note as redundant to the 2 options. --Daniel Carrero (talk) 03:19, 1 December 2015 (UTC)
 * How would you avoid the possibility of there being overall support for changing the template, but not enough for each of the two possibilities, such that they both fail? —Μετάknowledge discuss/deeds 05:45, 1 December 2015 (UTC)


 * I'd vote oppose to both, since it's a false dichotomy. —CodeCat 14:50, 1 December 2015 (UTC)


 * I agree with CodeCat. and  should be treated as equivalent by the policy. --WikiTiki89 14:52, 1 December 2015 (UTC)

The problem mentioned by Metaknowledge above is avoidable by using the format of Votes/2015-09/Adding a collocations or phrases namespace or section:

Proposal 1: Replace context (cx) by label (lb).


 * Support
 * Oppose
 * Abstain

Proposal 2: Choose a specific markup.

If proposal 1 passes, should we choose a specific markup?


 * Support using label, not lb
 * Support using lb, not label
 * Oppose
 * Abstain

This is just a suggestion in a way the vote could be edited. But given the current opinions of people about using markup, I'm not going to implement it in the vote.

I and Dan Polansky would like to specify the markup in the vote, while Metaknowledge, CodeCat and WikiTiki89 don't -- I count 2 support, 3 oppose. If more people support specifying the markup in the future, we can implement the system above or some other way to choose markup, but if other people don't want it, it would be pointless, I think. --Daniel Carrero (talk) 17:26, 1 December 2015 (UTC)


 * The plan above was designed as a possible compromise, since there are some people that would seem to support the proposal but would consider and  the same for the purposes of the vote. If it were up to me, I'd just make a vote about  alone, and people who wanted  or consider label/lb the same would have the option of voting oppose if they wanted. --Daniel Carrero (talk) 17:36, 1 December 2015 (UTC)

usex → ux
I suggest adding to the vote: --Daniel Carrero (talk) 21:01, 30 November 2015 (UTC)
 * This is thoroughly unrelated. As much as is reasonably possible, I would prefer to keep this vote about switching between different templates rather than conflate it between switching between different markup. —Μετάknowledge discuss/deeds 21:17, 30 November 2015 (UTC)


 * Actually this is a similar issue because takes a   parameter just like, while  takes the language code as the first positional parameter like . --WikiTiki89 22:01, 30 November 2015 (UTC)


 * Thanks. I see that the typo above has been fixed, and considering that doesn't even exist, I should've put more thought into it. Then yes, I support adding this to the vote. —Μετάknowledge discuss/deeds 02:33, 1 December 2015 (UTC)


 * ✅ --Daniel Carrero (talk) 03:06, 1 December 2015 (UTC)

ux and usex
and have differences in parameters for translations and transliterations. I hope this will be taken into account when running a bot to replace one with the other. Actually, it applies to and. --Anatoli T. (обсудить/вклад) 01:20, 10 January 2016 (UTC)

term ≠ m (just a note)
Just a note: I think it's good that this vote passed and we get to convert all uses of into.

Sometimes I find that people erroneously used with the 1st parameter being the language code. I'm fixing these as I find them.

Example: (diff)

dum:

--Daniel Carrero (talk) 19:38, 29 February 2016 (UTC)