Template talk:LangSwitch

Archives 1

New version

I have created a new Lua version at Template:LangSwitch/sandbox. It is necessary if we want to make langSwitch like function in module and it has several other benefits (more at Template talk:Fallback. From what I can see it works the same as the current version, save for a slightly different error handling, but error reports are welcome. If no one objects, I will replace the main template in a few days. --Zolo (talk) 16:36, 21 November 2013 (UTC)

Edit request: Heavily used template

{{Edit request}} Please add <noinclude>{{heavily used template}}</noinclude> to the top of this high use template (example). Riley Huntley (talk) 08:49, 30 April 2016 (UTC)

 Done--Jarekt (talk) 13:18, 2 May 2016 (UTC)

Langswitch considered harmful (when used beyond its intended purpose)

The "langswitch" template element was really originally intended for software interface messages (the underlying Wikimedia software telling you that some kind of error has occurred in a language that you'll understand, etc). Unfortunately, some people seem to want to extend langswitch to uses for which it was not designed, and to which it is not suited -- i.e. managing various types of general-purpose multilingual descriptions (of images, etc). In such cases, if you want to check if the translations between the different languages are correct, or see file descriptions in a language different from your browser interface language, then langswitch does nothing for you. The rigid inflexible simplistic "langswitch" approach is simply not capable of handling the various diverse situations and needs which arise in the context of multilingual image etc. descriptions, and should not generally be used for such purposes (as has been discussed previously at various times on the "Village pump". etc). AnonMoos (talk) 16:11, 30 October 2016 (UTC)

Using default with en

Is the following example from the documentation correct?

{{LangSwitch
|de=[[:de:Warschau|Warschau]]
|en=[[:en:Warsaw|Warsaw]]
|fr=[[:fr:Varsovie|Varsovie]]
|ja=[[:ja:ワルシャワ|ワルシャワ]]
|pl=[[:pl:Warszawa|Warszawa]]
|default=[[d:Q270]]
}}

The above displays as Warsaw

Examples which show this section:

• uselang=de
• uselang=bn
• uselang=fa

It seems that all languages fall back to en, so en will always be used if it is present. That means default has no effect when en is specified. Johnuniq (talk) 06:10, 15 September 2017 (UTC)

Yes "default" is only going to be used if there is no "en" option, so int the above example "default" will never be used. --Jarekt (talk) 18:24, 15 September 2017 (UTC)

Maybe I will change the documentation to present "default" as alternative argument name to "en". It is only useful if your default text is not English and you do not want to call it English. --Jarekt (talk) 18:42, 15 September 2017 (UTC)

Clearly I also was mistaken by default documentation.

If this is the behavior, then I will have to implement another LangSwitch.

Because with Wikidata what we want now to do is {{LangSwitch|en=...|default={{label|Q16965488}} }} which does not work.

Regards Liné1 (talk) 18:02, 22 September 2017 (UTC)

@Liné1: what will you say about this? A bug or not, but the {{Label}} fallback (not to be confused with LangSwitch) in {{Maps}} is now completely knocked out “thanks” to Verdy p. I have no opinion how specifically {{LangSwitch}} should work, but, please, converge to some definite solution about it. Either keep status quo and propose another implementation, or make default= usable here. Incnis Mrsi (talk) 17:23, 17 February 2018 (UTC)

@Incnis Mrsi: Again this is a bug in Module:Fallback which still does not correctly handle the "default" we need on Commons. See the talk page of this module and the Module talk:Fallback/testcases showing the strategy we want on Commons (this is a limitation of the internal MediaWiki fallback chains that do not include any "default" option in the fallback lists it currently returns; but we can work around this, as demonstrated in the testcases). I have documented the small change needed in the talk page of the module. This is how it worked on Commons before the module was rewritten to use the fallbacks exported by MW, instead of the local lists of fallbacks where Commons has always needed a "default" option to come first before the "en" option. verdy_p (talk) 17:28, 17 February 2018 (UTC)

That's wrong, the default is used first, before using fallback to English. This default will not be used is you look for the English version and there's an "en" value supplied, or if a language has an "explicit" fallback coming first to English, instead of using the other fallbacks including "default" at end.

That's how it should work, and so specifying *both* "default" and "en" has a meaning, they are at different places of the fallback chains.

This allows tracking missing translations where an additional formatting (or note) is necessary, which won't be used in the plain English version. English ("en") is effectively in the last position of all chains, the penultimate position being the "default".

As well the "default" is not necessarily in English or could be "international English" different from the standard English used in "en", to avoid some (implicit) semantic shortcuts used in US ("en" is often tuned for "en-US" for topics geolocated in US and all non-geolocated topics, or tuned for "en-GB" for topics geolocated in UK), but when the "default" is used to display English text, it is better for English-speaking users living elsewhere, in UK (if the "en" resource was tuned for US), or in US (if the "en" resource was tuned for UK), or in India, South Africa, etc.

The "default" is not necessarily in English and may be an official local toponym adopting its standardized orthography (not used in US where it was simplified), and even the "default" may be in another non-Latin script for this case. So "en" has very low priority for all other languages, "default" is more international and more standard. verdy_p (talk) 15:57, 17 February 2018 (UTC)

I did not follow the conversation, but clearly default should be prioritary to en. In fact I don't even know how to document a default= parameters used only when there is no en=. Regards Liné1 (talk) 22:02, 17 February 2018 (UTC)

You've effectively not followed the discussion: "default" is to be used independantly of the presence of "en". It is pêrfectly valid to have both set differently (see the example above as an application, where English (or variants of English) would go to a Wikipedia article in English, and any unspecified language would go to Wikidata via the "default"). There are may other uses of the "default", such as tracking untranslated messages in categories, or asking for translators to improve the translation by adding a real one instead of the default one (possibly in English but not necessarily, it is just a text meant to be usable by most people including non-English readers). That's exactly what I've done in the sandbox version, which multiple users have confirmed to be correct, and which unifies the management of fallbacks, by adding automatically the fallbacks that are built in MediaWiki (but only for its own UI translations), after the translations tuned specifically on Commons in the "Fallback" data module.

Also I made it more compliant to BCP47, by taking into account automatically for all languages coming from the two existing sources of fallbacks those that are variants of a base language, and automatically adding the base language to the list (local on this Commons Wiki, and global on MediaWiki), and here again these additions for variants are taken AFTER each source of fallbacks, so we have full control on the search order for fallback and never see any one missing. As well the code is more optimal, avoids all non trailing recursions, runs faster, and even uses less memory. verdy_p (talk) 01:48, 21 February 2018 (UTC)

Mapping the same value to several languages with LangSwitch

I'd like to make another improvement to "LangSwitch" : being able to specify parameters that are comma-separated (or space separated) lists of languages to which we want to map the same translation.

Unlike "#switch:" where it is simple (use a vertical bar to separate languages and map the same value after the next equal sign), it is not possible with the template syntax of "LangSwitch" (you need to map each language individually to the same value, which may be quite complex in some templates), but we could pass multiple languages in the same parameter name: it is perfectly possible because valid language codes do not contain any space, or comma, only character in [a-z0-9] or hyphens [-] (note that underscores are also recognized as equivalent as hyphens, and the letter case of given language codes is not significant).

So I just propose to parse in Module:Fallback these parameter names and split them where they contain commas (or spaces), as if we had passed separate parameters with the same value (at the same time I can detect if the same language is specified twice in separate parameters and render a usage error, this duplication is already possible by passing for example "|en=value1|EN=value2" and the effect is unspecified as we can't predict which value will be used). This would also simplify various cases, for example "|hr,sr-latn,bs=value1" instead of "|hr=value1|sr-latn=value1|bs=value1", or "|ko,ja,wuu,yue,zh-hant=value2" instead of "|ko=value2|ja=value2|wuu=value2|yue=value2|zh-hant=value2" to reduce the code size of various templates. verdy_p (talk) 01:48, 21 February 2018 (UTC)

Why not

I am missing too that option as it exists in writing SVG with switchable embedded text, e.g.

 <text systemLanguage="de">Grün</text>
 <text systemLanguage="es, it, pt">Verde</text>
 <text systemLanguage="fr">Vert</text>
 <text>Green</text>

The LangSwitch does not understand a #switch:-like notation as e.g. |es|it|pt=Verde, it has to be written 3 times explicitely:

{{LangSwitch
|de=Grün
|es=Verde|it=Verde|pt=Verde
|fr=Vert
|en=Green}}

IMHO it would be nice to have this simplifying option. -- sarang♥사랑 14:08, 29 May 2018 (UTC)

@Sarang: it is almost identical to the proposal above, except that verdy_p prefers commas to pipes. Incnis Mrsi (talk) 16:41, 29 May 2018 (UTC)

In Lua |es|it|pt=Verde|xx|yy=abc will show up as args = {1=es, 2=it, 3=xx, pt=Verde, yy=abc} structure identical to structure created by |es|it|xx|pt=Verde|yy=abc. Input |es,it,pt=Verde|xx,yy=abc will show up as args = { ["es,it,pt"]=Verde, ["xx,yy"]=abc} which is a bit more manageable. --Jarekt (talk) 17:34, 29 May 2018 (UTC)

I altered Module:Fallback/sandbox (which is called by {{LangSwitch/sandbox}}) so

• {{LangSwitch/sandbox|de=Grün|es/it/pt=Verde|fr=Vert|en=Green |lang=en}} -> Green
• {{LangSwitch/sandbox|de=Grün|es/it/pt=Verde|fr=Vert|en=Green |lang=it}} -> Verde

Would that work? --Jarekt (talk) 18:54, 29 May 2018 (UTC)

That's a good step, but anyway the separator character used between language codes can be any punctuation (except the "|" pipe needed to separate parameters, "=" for assigning their value, braces, and hyphen or underscore used by BCP 47 identifiers). As there will not be any valid use with empty "" language codes, you can also eliminate runs of multiple separators, so "es/it/pt=Verde" or "es it pt=Verde" or "es,it,pt=Verde" or "es, it, pt, =Verde" can be parsed equivalently. We just need to allow multiple language codes (using only ASCII letters or digits, or hyphen or underscore) to be used as parameter names and make them non-case significant. The LUA module can than parse the parameter names and ensure they are not colling so that {{LangSwitch/sandbox|de=Grün|es/it/pt=Verde|fr,EN=Vert|en=Green |lang=en}} will be signed as an error because "en" is present twice with distinct values ("Vert" and "Green") mapped to it (in "fr,EN=*" and in "en=*"). I don't care about which separator is used, so you can use commas, semicolons, colons, spaces, slashes. This gives greater flexibility of use with other generative templates. This parsing will then transform the args into args = {de: "Grün", es: "Verde", it: "Verde", pt: "Verde", fr: "Vert", en: "Green", lang: "en"} where all parameter names are then in canonical lowercase form (only ASCII letter, digits and hyphens) and conforming to BCP47 (except "lang=*" and "default=*" parameters). verdy_p (talk) 20:07, 31 May 2018 (UTC)

 Done I deployed a new version, which was moved to a new Module:LangSwitch for easier tracking. --Jarekt (talk) 12:16, 4 June 2018 (UTC)

Bug

LangSwitch Error: no default appeared on 28 614 pages, for e.g. Grave of Bernhardt. Pyb (talk) 11:31, 9 June 2018 (UTC)

@Pyb: may something be wrong with the {{Inscription}} template? Incnis Mrsi (talk) 16:51, 9 June 2018 (UTC)

@Incnis Mrsi: yes, it's probabably the side and position parameters. But I don't know what to do. May be something like that. Pyb (talk) 17:52, 9 June 2018 (UTC)

This error appears on several templates since {{LangSwitch}} was recoded a few days ago. For me it doesn't appear to be a bug. Basically it just returns an error message when it's used improperly (without a default value or an English language code) where the old version of LangSwitch didn't "complain" about.

• see also Category:Buses where {{Other language}} is used (along with several thousand uses of this template)
  

Please fix this. (I don't know how.) --Zaccarias (talk) 18:13, 9 June 2018 (UTC)

There were no major changes to {{LangSwitch}} lattely. Maybe error checking was not working correctly for a while. But all the errors I looked at were correct: both "en" and "default" options were missing or were empty. I think the issue with Category:Buses is with the {{Other language}} template. I do not know what it is suppose to do. The description makes it sound like {{LangSwitch}} but it is somehow different. --Jarekt (talk) 01:12, 10 June 2018 (UTC)

I still don't understand what is missing :

{{inscription|FAMILLE BOURLIER|side=recto|language=fr}}

recto:

FAMILLE BOURLIER

Adding "en" or "default" parameters doesn't hide the error message. Pyb (talk) 10:26, 10 June 2018 (UTC)

Fixed here (only the last line mattered}}. It was a case where "en" was present but returned empty string sometimes. --Jarekt (talk) 02:49, 11 June 2018 (UTC)

Thank you Pyb (talk) 05:40, 11 June 2018 (UTC)

Language

{{Edit protected}} Please add {{Lang}}. 217.117.125.72 16:54, 6 June 2020 (UTC)

Please explain what are you trying to achieve. --Jarekt (talk) 02:53, 7 June 2020 (UTC)

Edit request

Please add a "no" parameter, Norwegian language. 12u (talk) 01:38, 6 July 2022 (UTC)

It was removed intentionally on request by Jon Harald Søby. Use nb (bokmål) or nn (nynorsk)—or both—depending on which standard you use. (If you set only either of them, the users with the UI language set to either of them will get that one, but if you set both, everyone will get their own preferred writing standard.) —Tacsipacsi (talk) 13:04, 7 July 2022 (UTC)

Thanks for making me aware, "nb" is compatible for my use. 12u (talk) 21:05, 9 July 2022 (UTC)

RTL support

It is requested that an edit or modification be made to this protected page.
Administrators: Please apply <nowiki> or {{Tl}} to the tag after the request is fulfilled.

---

Fulfill this request after checking that the code is safe

Achim55

Can it automatically assign correct text direction when an RTL language is used? I've added Hebrew translation to {{Help banner}}, but it shows the question at the wrong end because it's shown as part of the page content, and on Commons, the page content is LTR by default. Amir E. Aharoni (talk) 16:20, 7 March 2023 (UTC)

It shouldn’t. Currently it emits no markup, which means it’s usable in any context, including within HTML attributes, with not human-readable language-dependent output (like using LangSwitch to select a date format, name format etc.), and so on. However, I support introducing a new parameter for opting in adding markup. If it’s added, usage that opted in should probably get not only rtl/ltr markup (ltr is also important, in case English text appears in the middle of a Hebrew text block), but also marking up the language, helping browsers to use the correct fonts and screen readers to use the correct pronunciation. This opt-in parameter should also contain information on whether inline markup (<bdi>) or block markup (<div>) should be used, so that it’s usable both for one or two words and for multi-paragraph text blocks. —Tacsipacsi (talk) 08:37, 8 March 2023 (UTC)