Wiktionary:Votes/2016-07/Using template l to link to entries

From Wiktionary, the free dictionary
Jump to navigation Jump to search

Using template l to link to entries[edit]

  • Voting on: For languages other than English, allowing automatic and semi-automatic edits to ensure that all links in Synonyms, Antonyms, Hyponyms, Hypernyms, Related terms, and Derived terms are linked using {{l}} template rather than plain wikilinks.

    Thus, instead of

    [[escuela]]

    there will be

    {{l|es|escuela}}

  • Rationale: See Wiktionary talk:Votes/2016-07/Using template l to link to entries#Rationale. The voters only vote on the proposed action, not on the rationale.
  • Vote starts: 00:00, 31 July 2016 (UTC)
  • Vote ends: 23:59, 28 September 2016 (UTC)

Support[edit]

  1. Support --Daniel Carrero (talk) 16:27, 31 July 2016 (UTC)[reply]
  2. Support. — Andrew Sheedy (talk) 18:44, 31 July 2016 (UTC)[reply]
  3. Support, already been done IIRC. —Μετάknowledgediscuss/deeds 19:23, 31 July 2016 (UTC)[reply]
  4. Support --WikiTiki89 19:03, 1 August 2016 (UTC)[reply]
  5. Support Benwing2 (talk) 00:42, 2 August 2016 (UTC)[reply]
  6. Support - DonnanZ (talk) 13:16, 2 August 2016 (UTC)[reply]
  7. Support, though it's moot, it has already been done. —CodeCat 20:16, 2 August 2016 (UTC)[reply]
  8. Support -Xbony2 (talk) 15:49, 3 August 2016 (UTC)[reply]
  9. SupportEru·tuon 04:14, 10 August 2016 (UTC)[reply]
  10. Support Philmonte101 (talk) 18:33, 11 August 2016 (UTC)[reply]
  11. Support Mulder1982 (talk) 21:45, 20 August 2016 (UTC)[reply]
  12. Support --Octahedron80 (talk) 06:51, 27 August 2016 (UTC)[reply]
  13. Support --AtalinaDove (talk) 17:49, 27 August 2016 (UTC)[reply]
  14. Support --Vahag (talk) 08:51, 29 August 2016 (UTC)[reply]
  15. Support --Mistrz (talk) 15:10, 20 September 2016 (UTC)[reply]
  16. Support DTLHS (talk) 14:56, 28 September 2016 (UTC)[reply]
  17. SupportAɴɢʀ (talk) 15:30, 28 September 2016 (UTC)[reply]
  18. Support Though we should be careful about instances of [[foobar]] appearing inside of {{der3}} and the like. —JohnC5 18:21, 28 September 2016 (UTC)[reply]
  19. SupportJberkel (talk) 19:49, 28 September 2016 (UTC)[reply]

Oppose[edit]

  1. Oppose Dan Polansky (talk) 18:28, 1 August 2016 (UTC) The service delivered by the template is not worth the additional line noise. Furthermore, that service can be achieved using JavaScript as was done in tabbed browsing: there, retargetting already works even without {{l}}. Alternatively, this seems fit for a MediaWiki plugin, executed on the server site. Let's keep the markup that is the editing interface of Wiktionary simple. --Dan Polansky (talk) 18:28, 1 August 2016 (UTC)[reply]
    Some people say that votes are evil. I am not one of them; I vehemently oppose that meme. But it has not escaped my attention that the supporters did not raise any points or respond to any points raised by me. Like, MediaWiki plugin is a bad idea because X. Or JavaScript would slow down the browser. Or whatever. --Dan Polansky (talk) 19:03, 2 August 2016 (UTC)[reply]
    WikiMedia plugins are out of our control, and it would be silly to develop a plugin that is so specific this one purpose. JavaScript would both slow down the page loading time and cause the link and formatting to be temporarily incorrect while the page is loading. --WikiTiki89 19:09, 2 August 2016 (UTC)[reply]
    I don't understand the plugin argument. The plugin would produce the {{l}} markup, and that markup would render whatever we let it in the code of {{l}}. Don't see anything "silly" about it. But let me make a note about JavaScript: editors voted to enable tabbed browsing by default. This has not been done yet, but the approving vote is there. And that tabbed browsing already does use JavaScript to make that retargetting automatically, without {{l}}. So by voting to enable tabbed browsing by default, editors already voted in the JavaScript overhead. --Dan Polansky (talk) 19:12, 2 August 2016 (UTC)[reply]
    Plugins are not cheap. They require a good deal of development, testing, rollout, more testing, maintenance, etc. And all of that is done by the devs, not by us, which slows down the process even more. So unless they make our lives significantly easier, we should avoid them. In this case, replacing links with {{l}} is not such a big deal that we should create a plugin to avoid doing that. I'm not sure exactly what retargeting you are referring to in tabbed languages, because I've never used tabbed languages. But if replacing links with {{l}} would allow us to remove some JavaScript from the tabbed languages code, that would be a good thing. --WikiTiki89 19:22, 2 August 2016 (UTC)[reply]
    As for the expense of the plugin, they obviously have enough resources for sci-fi rocket-science projects like Visual Editor and Flow; a little plugin that makes some very simple replacements on the text level would be ridiculously cheap in comparison. As for tabbed browsing, you can try it: enable tabbed browsing in prefs and try browsing old versions without {{l}} and see whether you see the added # targets. But I accept your point that {{l}} could make the tabbed browsing cheaper on JavaScript. OTOH, my guess would be that the retargetting is one of the less expensive parts of the whole tabbed browsing functionality. --Dan Polansky (talk) 19:28, 2 August 2016 (UTC)[reply]
    Did I mention that plugin development is outside of our control? And every plugin is a headache no matter how small; the fewer the better. More importantly, it doesn't solve any essential problem. I don't see any downside to converting these lists of links to use {{l}}. --WikiTiki89 19:50, 2 August 2016 (UTC)[reply]
    If the problem solved by {{l}} is not essential, then I don't see why we are bothering with complicating our wiki markup with {{l}}. Plugin development is not outside of our control. Anyone can develop a plugin for MediaWiki. Another thing is having that plugin deployed; that could be out of our control, just like deployment of things we did not approve is out of our control. But with a good and simple plugin developed, I don't see why devs would oppose deployment. --Dan Polansky (talk) 20:09, 2 August 2016 (UTC)[reply]
    Sorry if I wasn't clear. I meant that the problem solved by the plugin is not essential, because it can be easily solved with {{l}}. --WikiTiki89 14:51, 3 August 2016 (UTC)[reply]
    Let me add: This is a bot-maintained redundancy in the markup in the best case, and human-maintained redundancy in the markup in the worst case. It is telling the computer something via the markup that the computer should already know. --Dan Polansky (talk) 09:22, 6 August 2016 (UTC)[reply]
  2. Oppose. This is exactly the kind of thing that drives off new users. Plugins may not be cheap, but it's definitely cheaper than this. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 14:55, 28 September 2016 (UTC)[reply]

Abstain[edit]

  1. Abstain The last time CodeCat+MewBot did it automatically tons of {{l}} links had the wrong language due to human editor peculiarity, etc. Unless bot logic is better this time... —suzukaze (tc) 14:54, 3 August 2016 (UTC)[reply]

Support for non-Latin-script languages[edit]

  1. Support --Daniel Carrero (talk) 16:27, 31 July 2016 (UTC)[reply]
  2. Support. — Andrew Sheedy (talk) 18:44, 31 July 2016 (UTC)[reply]
  3. Support --WikiTiki89 19:04, 1 August 2016 (UTC)[reply]
  4. Support —Enosh (talk) 21:00, 1 August 2016 (UTC)[reply]
  5. Support especially strongly here Benwing2 (talk) 00:42, 2 August 2016 (UTC)[reply]
  6. SupportCodeCat 20:16, 2 August 2016 (UTC)[reply]
  7. SupportEru·tuon 04:15, 10 August 2016 (UTC)[reply]
  8. Support Philmonte101 (talk) 18:33, 11 August 2016 (UTC)[reply]
  9. Support Mulder1982 (talk) 21:45, 20 August 2016 (UTC)[reply]
  10. Support --Vahag (talk) 08:51, 29 August 2016 (UTC)[reply]
  11. Support --Mistrz (talk) 15:10, 20 September 2016 (UTC)[reply]
  12. SupportAɴɢʀ (talk) 15:30, 28 September 2016 (UTC)[reply]
  13. SupportJohnC5 18:21, 28 September 2016 (UTC)[reply]
  14. Support AtalinaDove (talk) 20:05, 28 September 2016 (UTC)[reply]

Oppose for non-Latin-script languages[edit]

  1. Oppose Dan Polansky (talk) 18:28, 1 August 2016 (UTC)[reply]
  2. Oppose ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 14:56, 28 September 2016 (UTC)[reply]

Abstain for non-Latin-script languages[edit]

  1. Abstainsuzukaze (tc) 14:55, 3 August 2016 (UTC)[reply]
  2. Abstain May be yes, may be no. Some terms of non-Latin script cannot be decided which language they are. --Octahedron80 (talk) 06:53, 27 August 2016 (UTC)[reply]
    @Octahedron80: Can you give an example of what you are talking about? In all these cases, the language should be the same as the language of the entry. For example, a synonym of a Japanese word, must also be Japanese. --WikiTiki89 13:32, 29 August 2016 (UTC)[reply]
    I think about synonyms that are symbols, which are already under a language section. Or should they be put as 'mul' instead? Simple example of these is centimetre. (Sorry for Latin example) --Octahedron80 (talk) 13:42, 29 August 2016 (UTC)[reply]
    Yes, they should be 'mul' whenever that symbol would be included as translingual. --WikiTiki89 14:15, 29 August 2016 (UTC)[reply]

Decision[edit]

  • Proposal 1 passes: 19-2-1 (90.48%-9.52%)
  • Proposal 2 passes: 14-2-2 (87.50%-12.50%)

Edited WT:TASK accordingly. --Daniel Carrero (talk) 00:51, 29 September 2016 (UTC)[reply]