Talk:Wikimedia LGBT/Barnstar

Tests

By default, display the current user's language

The Wikimedia LGBT+ Barnstar For excellence in service to the Wikimedia community on matters related to the LGBT+ communities.

The Wikimedia LGBT+ Barnstar With joy !

The Wikimedia LGBT+ Barnstar With joy !

display the current page content language

The Wikimedia LGBT+ Barnstar For excellence in service to the Wikimedia community on matters related to the LGBT+ communities.

The Wikimedia LGBT+ Barnstar With joy !

The Wikimedia LGBT+ Barnstar With joy !

display a specific language (here de for German) if its translation exists, otherwise display a fallback

Der Wikimedia-LGBT+-Barnstar For excellence in service to the Wikimedia community on matters related to the LGBT+ communities.

Der Wikimedia-LGBT+-Barnstar Mit Freude !

Der Wikimedia-LGBT+-Barnstar Mit Freude !

display a specific language (here fr for French) if its translation exists, otherwise display a fallback

L’Étoile de grange Wikimédia LGBT+ Pour l’excellence du service rendu à la communauté Wikimédia sur les matières relatives aux communautés LGBT+.

L’Étoile de grange Wikimédia LGBT+ Avec joie !

L’Étoile de grange Wikimédia LGBT+ Avec joie !

Switch

Ad [1]

@Verdy p: You’re right, I don’t understand why my version would be broken. I checked this talk page after the first change and everything looked OK. (Unfortunately, due to this template being in main space, the “preview with this template” feature doesn’t work.) There are two differences in how the #switch works in your and my version:

• Mine is at the outermost level. I think it looks nicer with cleaner code (not using a switch within the template name) and by not passing unnecessary parameters to the translation subpages in the #default case, but I don’t think it would cause any practical difference.
• In my version, the translate section that the template switches on is entirely empty, so it doesn’t create an actual translation unit, just outputs the garbage that makes the switch work. In your version, it’s actually translatable, which creates extra work for the translators, and is quite dangerous: take a look at Template:Affiliations Committee/MainNav/ko’s previous version—a translator translated this message to non-empty content, which caused an infinite template loop.

The documentation doesn’t help either, it just contains a small example and a link to this talk page. —Tacsipacsi (talk) 22:39, 19 August 2020 (UTC)

This is a limitation of the translation tool. Yes there's an empty unit (note really it is actually a variable with an empty value, but this is necessary). Otherwise the page does not generate correctly. You just attempted to change things that I had tested years ago, and this is the only solution I found which is still sage, and actually does not create any hard work for translators. You "nicer" code was actually wrong. In fact it was worse and syntactically incorrect. If you look at the history years ago, what you attempted to fix was already tested, it never worked. The limitation of the Tranlate tool that was applicable years ago is still there. There's still no completely clean way to translcluse a template which is translatable, except the solution using the switch (which will detect the presence of translate tags, invisible in each translated versions, but necessary to correctly include them and pass them the expected language code).

In fact before I reveretd you I first tried to drop the bad code you introduced, but then I realized why It was written like this: the switch was there before for a good reason. You should have not modified it, as there as no reason to change it when you just broke it for no benefit at all. The way it was written before was perfectly correct (with the only cost of a dummy translation unit "$x" that can be left as is, and was already set as is in existing translations). You did not fix anything, you did not "clean" anything you just broke them and made the code worse. So I've reverted to the working version that was there since years and has never caused any problem since then.. verdy_p (talk) 15:39, 20 August 2020 (UTC)

Note: the namespace used does not change anything. It's just that the barnstar was created as a subpage of the portal, especially for not polluting the template namespace. It is not a generic template even if it can used like a template, it is fully part of the portal since the beginning years ago. verdy_p (talk) 15:42, 20 August 2020 (UTC)

@Verdy p: Please look at the diff more carefully. I did not remove the switch. I just moved it to a different position. I know pretty well that the switch is necessary, why it’s necessary and how it works. Yes, the translation unit can be left as is when translating, and it will be left as is in 99.99% of cases—but not always, see the above Korean example. That’s why an empty pair of translate tags is better: it cannot be translated, but it still makes the switch hack work. This empty translate hack is used on hundreds of pages on MediaWiki.org with no apparent issues. (Yes, the namespace doesn’t change anything except for making it more difficult to test transclusions. But that’s okay. I just mentioned it because I can do little testing without making actual edits because of this.) —Tacsipacsi (talk) 16:03, 20 August 2020 (UTC)

No, the empty translate tag does not work (the empty tvar in the translate tags however does work). This makes the translate tool incorrectly parse the page. As well this leaves these translate tags as plain text in the generated pages (including all translations).

What you tried is what I had attempted already years ago (look at the history), it did not work in the past and still does not work today. it was reported as a bug years ago, never corrected, the multiple reports were discarded as NOTBUG or WONTFIX,... So I found this workaround using the switch to detect the tags that are left as plain text by the translate tool). A **non-empty** translation unit is really necessary (even if this is just a "tvar" with an empty value). This has still not changes since years after the bug reports constantly discarded.

Finally there's NOTHING special for Korean (which was already working correctly as is and since years: there was nothing to "fix" for it). verdy_p (talk) 16:21, 20 August 2020 (UTC)

@Verdy p: Sorry, you’re denying facts. It works. It’s used by hundreds of templates on MediaWiki.org, and no problems arose so far. Take a look at mw:Template:Done’s source code and notice the empty translation unit in the first line, then go to mw:Template:SkinInstall/fr and notice that the third bullet point starts with “Fait”—not with “Done”, and not with garbage. It simply works.

I clicked through the whole page history (which is not super helpful with its empty edit summaries and everything marked as minor), but I haven’t found the revision you’re referring to, so could you please post a diff link where you introduced a completely empty translation unit, which didn’t work?

There’s nothing special about Korean in general, but if you take the time to click on my link (which you don’t seem to have done so far), you’ll see a red message saying Template loop detected: Template:Affiliations Committee/MainNav/ko. This is because Translations:Template:Affiliations Committee/MainNav/4/ko’s content is &$x instead of $x. Pretty small mistake, but it made this particular template unusable in Korean for more than five years. —Tacsipacsi (talk) 19:00, 20 August 2020 (UTC)

I'm not denying facts: your change did not work; the old code written 3 years ago had no problem and you just broke it without reason. So you are denying the facts. You're not comparing the same thing in other templates that were built on a different base and with a different use case (not the same language defaults).

There's nothing special for Korea, but I don't know why you want to place an ampersand in its translation (there's none in the original and this variable is empty in all languages). verdy_p (talk) 19:24, 20 August 2020 (UTC)

@Verdy p: You said the empty translate tag does not work, which is clearly not true. It works, at least most of the time. If the empty translate tag doesn’t work on this page, that’s another case, but you haven’t explained yet in what way the page was broken (I could see it myself by reverting your edit, but that’s not wise if it so seriously breaks the page), and I also don’t understand what’s so special about this page that a solution tested on hundreds of pages suddenly breaks here. Other templates were built on a different base—what base? Everything is built on wikitext and the Translate extension’s features, isn’t it? Not the same language defaults—what language defaults? The default is always English, this page being no exception.

I don't know why you want to place an ampersand in its translation—it’s not me who placed the ampersand in the translation, it’s just a random Korean translator who decided for whatever reason to add an ampersand. This can happen any time—although it’s quite unlikely, not impossible. And since the empty translate tag does work, why risk this? —Tacsipacsi (talk) 22:04, 20 August 2020 (UTC)

Which risk ? Any translation can be garbled by translators typing what they want. This does not mean the source was incorrect. Those bugs can be fixed in the translation interface directly. There's no such "risk".

What I saw is that empty translate units are not working as you think, causing the wrong subpage to be included (not the translated one, but the source with its translate tags kept as plain text. The initial code already managed to detect this and always display the correct version. So your argument about Korean was wrong, and in fact your "fix" did not fix the incorrect Korean translation unit and the page was still incorrect. You did not fix it as you think, but broke something in a way that was incompatible and broke everything else. Note that this template is intended to be posted in user talk pages, that do NOT have their own language defined (most of the time) and expect the language to be the user's current language of the UI (selected by "?uselang=*" or the ULS feature in the top toolbar. So why did you want to change something that actually worked without any problem since years? It's not clear what you wanted to do. But you just made false assumptions by changing it without any need for that. verdy_p (talk) 01:22, 21 August 2020 (UTC)

Any translation unit can be garbled. But a such easy-to-break, hard-to-understand one can be broken more easily. The risk is low, but completely eliminating it is quite easy, and it even makes translators’ life easier (no need to take care of this message either by pasting the source text or by skipping it), so it’s worth it.

The empty translate tags do not cause the source subpage (which is not a subpage, by the way) to be transcluded, or the hundreds of templates would all be broken. The Korean translation unit was still incorrect, but it’s no longer used at all, so its content doesn’t matter. Note that the code present in the documentation of this template (explicitly calling {{TNT}} without a |uselang= parameter) will never display the template in user language, regardless of which version of the template is used; user language is used only if it’s called as {{:Wikimedia LGBT/Barnstar}}, in which case both versions pass |uselang={{uselang}} to their language switch template ({{TNTN}} or Module:Template translation). My goal was to remove the tiny risk while making translators’ life easier. I accomplished it while not breaking the template, at lest certainly not breaking language selection. (Actually language selection seems to be testable without saving any edits, so I checked it, and it works.) —Tacsipacsi (talk) 22:03, 21 August 2020 (UTC)

@Tacsipacsi: You can use w:User:Jackmcbarn/advancedtemplatesandbox.js to show the "preview page with this template" link on pages not in the template namespace. * Pppery * _{it has begun} 19:17, 22 August 2020 (UTC)

As to the actual merits of this dispute, it accomplishes very little to say something is broken without explaining what the problem is in a way that can be reproduced by someone else, which verdy_p appears to have failed to do. * Pppery * _{it has begun} 19:17, 22 August 2020 (UTC)

It was demonstrated by the samples already present in this page at the top (And I added the link to the doc page, immediately at start of this talk, so your comment is sterile; even Tacsipacsi saw there was a problem with his edit; Nothing was broken since years, before his edit that suddenly changed something even if it was clearly not needed at all to change anything). verdy_p (talk) 21:04, 22 August 2020 (UTC)

Please point out in which of Tacsipacsi's comments he saw there is a problem with his edit. I see no such acknowledgement. * Pppery * _{it has begun} 21:48, 22 August 2020 (UTC)