Wiktionary:Votes/2013-09/Translation-links to other Wiktionaries

Definition from Wiktionary, the free dictionary
Jump to: navigation, search

Translation-links to other Wiktionaries[edit]

  • Voting on:

Making this change to the formatting of translations, vis-à-vis the link to the entry on the target-language Wiktionary:

case currently proposedly (notes)
FL-entry known to exist le (fr) le (fr) (unchanged)
FL-entry known not to exist le (fr) le (link gone)
no FL wikt le le (unchanged)
not-yet-bot-touched le (fr) le (link gone)

The above should not be taken very strictly; further changes may be made, after discussion, without another vote. (My reason for creating this vote is not that I think this really needs to be a vote, but only that the current formatting evolved from a previous vote.)


  1. Symbol support vote.svg Support --Vahag (talk) 08:35, 18 September 2013 (UTC)
  2. Symbol support vote.svg Support --SemperBlotto (talk) 21:18, 18 September 2013 (UTC)
  3. Symbol support vote.svg SupportUngoliant (Falai) 22:02, 18 September 2013 (UTC)
  4. Symbol support vote.svg Support Reasonable, although I sometimes wonder how useful this feature even is. —Μετάknowledgediscuss/deeds 03:21, 19 September 2013 (UTC)
  5. Symbol support vote.svg Support With some reservations.
    My initial reservation was because of case #4. Sorry to see new translations without a link to a FL wiki, they often are important for checking before saving translations. It's especially the case with well developed Wiktionary projects. E.g. when adding a Russian translation, I'd like to see the Russian entry (may remind of a synonym or a qualifier to add, make me even reconsider and choose a different term).
    Also, case #2, we still have many {{t-}} (i.e. no entry to FL wiki) for Mandarin when an entry in zh:wiki existed for ages. Hopefully "no link" will be timely converted to a "link" when an entry exists. It may have to do with the way Mandarin Wiktionary works. Both traditional and simplified Chinese words link to the same entry. Even Japanese words are "simplified" the Chinese way. --Anatoli (обсудить/вклад) 04:17, 19 September 2013 (UTC)
    Re: having the link before saving translations: you use the translation-adder script, right? It should be possible to change that script to check if the remote page exists, just like the bot does, and if so, to use {{t+}} instead from the get-go. (Disclaimer: I really have no idea how easy that is to do, and I'm not promising anything.)
    Re: zh.wikt: Yeah, Rukhabot doesn't (yet) support it, for exactly the reason you name. I think I need to re-evaluate how to handle it. (Similarly for kk.wikt and iu.wikt, though it does support sr.wikt and ku.wikt.)
    RuakhTALK 05:08, 19 September 2013 (UTC)
    Yes ({{t+}} on preview) and yes (address zh.wikt problem), please. If you could do that, it would be great. --Anatoli (обсудить/вклад) 05:36, 19 September 2013 (UTC)
    More on the link in preview: a link to FL would allow to look up transliterations, among other things, especially true for Chinese, Korean, Lao, Burmese. Links to other wikis also helps to find more translation into other languages, e.g. Russian wiki may have translations into languages of Russia. Turkish into Azeri, etc. Persian Hebrew wikis show vocalisation. --Anatoli (обсудить/вклад) 06:44, 19 September 2013 (UTC)
    An example of zh:wikt, @goodbye#Translations, which I corrected today (removed-, added+) : 再見, 再见 (zàijiàn). Both translations (trad. and simpl.) are linked to zh:再见, created in 2011 but our translations had {{t-}} for a long time. Hopefully the new method will not ignore entries at zh:wikt. I understand your disclaimer, happy to assist if I can. --Anatoli (обсудить/вклад) 05:47, 19 September 2013 (UTC)
    O.K., I've made the change to User:Conrad.Irwin/editor.js. It does support script-redirects on e.g. zh.wikt, but it does not (yet) support the diacritic-removal stuff; so, for example, if you try to add Latin amō, you'll get {{t-|la|amō}}, with a red-colored link to la:amo, even though the latter exists. To get the blue-colored link, you need to specify the page name as well, so you get {{t+|la|amo|alt=amō}} instead. Please let me know, and/or revert, if you encounter any problems. —RuakhTALK 21:24, 19 September 2013 (UTC)
    If it creates {{t+|la|amo|alt=amō}}, then it's really just substituting one bot task for another, right? In the last while I've been removing such "redundant" alt forms from links, following Mglovesfun's request. —CodeCat 21:34, 19 September 2013 (UTC)
    The reason for this change was not to eliminate a bot-task, but to provide instant feedback to the person adding the translation, and to use the appropriate template immediately rather than waiting a few weeks for database-dumps and whatnot. (You must admit that {{t+|la|amo|alt=amō}} is better than {{t-|la|amō}}.) —RuakhTALK 22:34, 19 September 2013 (UTC)
    {{t-|la|amō}} links to amo#Latin, thanks to Module:links, no need for alt=, see amō. --Anatoli (обсудить/вклад) 23:11, 19 September 2013 (UTC)
    Sorry, I think you must have misunderstood my comment? All I was saying is that {{t-|la|amō}} produces a red-colored link to la:amo, even though the latter exists. —RuakhTALK 01:01, 20 September 2013 (UTC)
    Yes, thanks for clarifying. What are script-redirects you mentioned?--Anatoli (обсудить/вклад) 01:04, 20 September 2013 (UTC)
    That's like, when you visit https://zh.wiktionary.org/wiki/再見 and the server responds with HTTP 301 "Moved Permanently" pointing at https://zh.wiktionary.org/wiki/再见. ("Script-redirect" is not a technical term, I just mean that MediaWiki performs script-conversion on the page-name and returns an HTTP redirect to the result.) —RuakhTALK 01:27, 20 September 2013 (UTC)
    In other words, you're going to show links for traditional forms (e.g. 再見) as existing, even if the zh:wikt redirects to the simplified form (e.g. 再见)? It's probably OK. I wonder if there are some specific user setting on the Chinese Wiktionary, which allow the select simpl. or tradit. form. (I searched but I didn't find any but Chinese Wikipedia allows to switch between mainland China, Taiwan and Hong Kong pages). These settings are a good way to handle dual writing system for Chinese topolects (individual characters can be shown separately - simpl. or tradit. on well structured entries) but they do a bad job for Japanese (+ Korean and Vietnamese old characters). --Anatoli (обсудить/вклад) 01:40, 20 September 2013 (UTC)
    Yes. I thought that was what you wanted? It's actually much easier not to do it, so if you don't want it, please speak up! (The whole reason that Rukhabot doesn't support zh.wikt is that it doesn't know how to tell when a redirect will exist. If you're saying that you want it to treat the redirects as nonexistent, then it can be fixed an instant.) As for a user setting, yes: go to https://zh.wiktionary.org/wiki/Special:%E5%8F%82%E6%95%B0%E8%AE%BE%E7%BD%AE?uselang=en, and look in the 'User profile' tab under 'Internationalisation'. You'll see 'Content language variant', which you can set to Chinese, Simplified Chinese, or Traditional Chinese. —RuakhTALK 02:03, 20 September 2013 (UTC)
    Thank you. I personally like your change but others may not, let's see. Just to clarify case #4. You said it was possible to check for existence of a FL entry when adding a new translation. Are you planning to try to add (have you added) this feature? Sorry if I missed something. --Anatoli (обсудить/вклад) 02:19, 20 September 2013 (UTC)
    That's what I was referring to above, when I wrote, "O.K., I've made the change to User:Conrad.Irwin/editor.js". (I have not yet modified Rukhabot to support script-redirects on zh.wikt, if that's what you were thinking.) —RuakhTALK 04:15, 20 September 2013 (UTC)
    Thank you. Hopefully, the issue with {{t-|la|amō}} can be resolved, as it is the same with Russian (or other) translations with stress marks or diacritics, e.g. {{t-|ru|старе́йшина|m|sc=Cyrl}} - старе́йшина m (staréjšina). (I'm not going to change my vote, of course.) --Anatoli (обсудить/вклад) 04:44, 20 September 2013 (UTC)
  6. Symbol support vote.svg SupportSaltmarshαπάντηση 10:39, 21 September 2013 (UTC)
  7. Symbol support vote.svg Support --Dan Polansky (talk) 08:31, 22 September 2013 (UTC)
  8. Symbol support vote.svg Support -- Haplology (talk) 12:21, 29 September 2013 (UTC)




  • Vote passes, 8–0–0. —RuakhTALK 06:58, 3 October 2013 (UTC)
    • I've now implemented the vote by modifying {{t}} not to include the link, redirecting {{t-}} to it, and updating the documentation accordingly. I've also redirected {{t0}} and {{}} to {{t}}, and marked both them and {{t-}} as deprecated; I hope that's uncontroversial? —RuakhTALK 07:27, 3 October 2013 (UTC)
      • There are no controversies but the performance of the bot adding {{t+}} should be a priority. E.g Chinese translations 臭蟲, 臭虫 (chòuchóng), 壁虱 (bìshī) have been for years at bedbug#Translations. Also, will the bot work correctly with translations having diacritics, like Russian stress marks, Latin macrons, etc.? I miss the default link to FL Wiktionaries when adding new translations. I wish the translations untouched by bot had {{t+}}. --Anatoli (обсудить/вклад) 00:03, 4 October 2013 (UTC)
        • Re: "E.g Chinese translations 臭蟲, 臭虫 (chòuchóng), 壁虱 (bìshī) have been for years at bedbug#Translations": I have a battle plan, but it will probably be another month or two before it's in place.
          Re: "Also, will the bot work correctly with translations having diacritics, like Russian stress marks, Latin macrons, etc.?": Yes, I added support for that about a month now.
          Re: "I miss the default link to FL Wiktionaries when adding new translations": It's there, I don't know how you can miss it.
          RuakhTALK 01:09, 4 October 2013 (UTC)
          • I think it needs/may need some testing and verifying. Not sure if we're talking about the same thing. It's not working (default link) in my observation. I often have to add "+" manually to Russian and Chinese translations, as the program doesn't seem to find the FL entry. Take the last three Russian translations at colonist#Translations for example (the first one was added long ago). All entries exit in ru wikt but {{t-}} is added, not {{t+}}: колони́стка f (kolonístka), поселе́нец m (poselénec), колониза́тор m (kolonizátor). --Anatoli (обсудить/вклад) 01:23, 4 October 2013 (UTC)
            • As I told you above, you can get the right result to begin with by specifying the pagename, rather than relying on the template to strip out the accent mark for you; you'd then have {{t+|ru|поселенец|m|alt=поселе́нец|sc=Cyrl}}. If you prefer to start with {{t-|ru|поселе́нец|m|sc=Cyrl}} and then manually change it to t+, you are of course free to do that, but you have to recognize that that's a choice that you're making. (Ideally, of course, you wouldn't have to make this tradeoff. I do plan to improve the translation-adder so it knows the right pagename even without your having to tell it; this will also fix the edit-summary that you complained about. But it doesn't seem like a huge deal to me; you're no worse off now than you were a few months ago, when you had to specify the pagename.) —RuakhTALK 06:51, 4 October 2013 (UTC)
Thanks. As I understand, {{t+|ru|поселенец|m|alt=поселе́нец|sc=Cyrl}} is not encouraged, anymore. All such cases have been changed to use just one link by a bot, since it's no longer needed. If I leave it as {{t-|ru|поселе́нец|m|sc=Cyrl}}, will the bot be able to fix it later or should I add the a plus manually for now? The bad news is that, even if I don't add a stress mark, the tool doesn't always find the link. You can test it yourself by adding "поселенец" (without a stress) anywhere.--Anatoli (обсудить/вклад) 07:04, 4 October 2013 (UTC)
Re: "{{t+|ru|поселенец|m|alt=поселе́нец|sc=Cyrl}} is not encouraged, anymore": It's no longer necessary, but it's completely harmless.
Re: "If I leave it as {{t-|ru|поселе́нец|m|sc=Cyrl}}, will the bot be able to fix it later or should I add the a plus manually for now?": Yes, the bot handles these fine. It's only the translation-adder that doesn't know how.
Re: "The bad news is that, even if I don't add a stress mark, the tool doesn't always find the link. You can test it yourself by adding "поселенец" (without a stress) anywhere": Oops, thanks, now Yes check.svg fixed.
RuakhTALK 07:31, 4 October 2013 (UTC)
Thanks again! Hopefully, the translation-adder is fixed as well. "alt=" was previously added automatically when there was an accent mark - there was no need to copy and remove accents. To replicate what happened a few months ago would require copy/paste, remove accent. Sorry to be a pain. :) --Anatoli (обсудить/вклад) 07:43, 4 October 2013 (UTC)
Re: "'alt=' was previously added automatically when there was an accent mark - there was no need to copy and remove accents": Ah, I see; that feature was removed last month. I've re-added it now, as a temporary measure. (To get the updated script, visit https://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/editor.js&action=raw&ctype=text/javascript and hit Ctrl+F5.) —RuakhTALK 02:13, 7 October 2013 (UTC)
Thank you but it seems that we are going backward. Not sure I want to go back to use 'alt=' for removing accent marks. Most templates don't require 'alt=' any more, diacritics and accent marks are removed automatically, not just for Slavic accents but Arabic and Hebrew vocalisation, e.g. Hebrew translation דָּג (he) m (dag) is linking to דג. Perhaps it's worth considering changing the translation adder to use the same methods? Pity you don't combine efforts with CodeCat and Kephir on this. Doesn't have to be immediate. (Thank you for the clarification on the talk page). --Anatoli (обсудить/вклад) 02:39, 7 October 2013 (UTC)
Yes, as I've said more than once, I definitely plan to change the translation-adder to do that. (As for "combin[ing] efforts", I don't think this change is really something that multiple people can work on together: either I do it, or someone else does it, or no one does it. It's not like this is a lot of work that can be split up for multiple people, it's just that it's one small-but-somewhat-tricky bit of work.) —RuakhTALK 04:26, 7 October 2013 (UTC)
I'd like to understand what exactly you have changed in terms how translations should work differently now. I see that links still work with diacritics/accents without 'alt='. I was able to use 'alt=' when linking non-lemma to lemma forms then and I can now. For "combining efforts", I meant that work that eliminated the need to use 'alt=' for diacritics and accents may be related to what you're trying to do (Have you undone some work by reverting to older code?). I've been away from the technical work @Wiktionary when I don't have to, focusing on words and grammar, I can't really give meaningful advice on this. Thank you for reassurance. As I said, I'm happy to wait, having to add "+" manually on accented translations is some inconvenience but I don't know if your latest change to the older version did something undesirable, like adding to redundant links categories CodeCat has been making. All cases with 'alt=' were changed by a bot to use links with diacritics (they still work). Anyway, thanks again. Will wait for further development. --Anatoli (обсудить/вклад) 04:51, 7 October 2013 (UTC)
Exactly what I changed is: I edited User:Conrad.Irwin/editor.js to restore the translation-adder's old behavior for various languages, whereby it would automatically populate the "page name" field by stripping diacritics from the translation. This is partially redundant, in that {{t}} and {{t+}} already know how to strip the diacritics, but: (1) User:Conrad.Irwin/editor.js needs to know the right page name for some purposes (such as producing the right edit-summary, and such as accurately choosing between {{t}} and {{t+}}), and (2) User:Conrad.Irwin/editor.js already adds some redundancy, such as sc=Cyrl for Russian, and this one is harmless. This will indeed add to CodeCat's "redundant" categories, but so what? I believe she's still running her bot to de-populate those categories, and if she were to stop, we'd simply turn off the categories. There are indeed reasons that it would be good for User:Conrad.Irwin/editor.js to use AJAX to retrieve the page-name from Module:Links, but they are not the reasons that you seem to think. —RuakhTALK 06:21, 7 October 2013 (UTC)