Template talk:Multilingual description

Purpose ?

What's the purpose of this template? --Slomox (talk) 13:14, 30 April 2009 (UTC)

See meta:Meta:Language select. Multichill (talk) 13:43, 30 April 2009 (UTC)

Is it planned to create something similar on Commons? And wouldn't it be possible to implement that with the existing language templates too? --Slomox (talk) 13:51, 30 April 2009 (UTC)

I do not see the advantage over using {{En}},{{De}}, etc. Those templates set the lang property for the contained text. Language switching should then be done either by the browser, by a global java script, or a preference setting. This template clutters the description pages, makes our syntax more heterogeneous (thus confusing editors), and offers no apparent benefit. --Dschwen (talk) 14:16, 14 May 2010 (UTC)

How about trying this version MediaWiki:Multilingual_description.js over the old version MediaWiki:Common.js/LangSelect.js coming from meta almost unchanged? Esby (talk) 14:45, 14 May 2010 (UTC)

As far as I can see from reading the source, that script is designed to work with {{En}},{{De}}, etc. as well. So again, what is the added value of the mld template? --Dschwen (talk) 15:17, 14 May 2010 (UTC). P.S.: or were you proposing to deprecate mld, through the use of the new javascript? Sorry, I'm not sure I quite understood you there :-). --Dschwen (talk) 15:19, 14 May 2010 (UTC)

Basically for now, {{En}} templates will need to be put into a multilingual div for having the new version of the script working. There might also be some changes needed on some templates too, to add alternate classnames.

The initial script (that every users is using) used to not work with the {{En}} and {{Fr}} templates. There were also various bugs making that we could not simply adds the mld headers to each section of a file description. The script would work on the first instance of {{En}} but would not work if another one was encountered, hence one of the reason for having an mld template. Others reasons follows:

This also allows to show all language when there is no translation available for a given field, thus not forcing the display of all other localized parts.

Imo, it's better to handle translation that should correspond to a same concept than rather using {{En}} & {{Fr}} likes, it is also better than autotranslate, since it's destined to be used on any file description and as you don't have to monitor subpages for possible vandalism.

Finally, once the user just understands he can fill the description with his language code, editing it might be no problem for him. Besides, it's the basic syntax that templates use. I'd assume that coding a ajax tool to fill the language code and appropriate description would be easier to code and maintain while relying on a single mld template than with the whole list of templates like {{En}} {{Fr}} {{Ar}} {{Az}} etc.

Esby (talk) 15:54, 14 May 2010 (UTC)

Ok, I think Iḿ starting to understand what this is about. The isolated {{En}},{{Fr}} etc. templates have no explicit structure that ties all translations of the same text into one group. This is needed to figure out if a fallback is needed. MLD provides that by wrapping all translations in one big div. I think this is not a major problem. We can take a heuristic approach here: all translation strings that have the same HTML parent node can pretty safely be assumed as belonging to a group. Let me work on a new JavaScript for language selection. The current solutions are not satisfactory. The language selection UI currently sucks, and it should only appear once per page (if it should appear at all! Intelligent language detection is necessary.) --Dschwen (talk) 01:06, 17 May 2010 (UTC)

try

 importScript("MediaWiki:Multilingual description.js") 

in your mono/vector/*.jss ? Esby (talk) 04:28, 17 May 2010 (UTC)

(indent reset) I see one issue with the version in use: I thought that hiding the langlabel when one is set was a good idea, but this makes difficult to differenciate when no language descriptor is used. Any idea? Colorating to yellow the non localized text maybe? Esby (talk) 23:15, 24 May 2010 (UTC)

Buttons

Could the buttons be translated too ? Sémhur (talk) 11:32, 17 July 2009 (UTC)

The strings are defined in MediaWiki:Common.js/LangSelect.js. But there seems to be no localisation method, so the code needs to be changed. --Slomox (talk) 12:01, 17 July 2009 (UTC)

Adding support to the Information Template...

User talk:Jean-Frédéric suggested here to modify {{Information}} to add the following 'magic code':

<div class="multilingual">

There is one issue still, linguistic code using linguistic templates like {{En}} or {{Fr}} does not behave as wanted when the inline parameter is used as no language selection is performed when the inline parameter is used.
I had asked Edward Z. Yang about it (since he was the one to create the script on meta), his answer was this one, now I don't know enough jss & (dom) html to correct the javascript.
Any idea how to fix LangSelect.js to correct it?
Esby (talk) 11:47, 19 July 2009 (UTC)

Sorting order changed without consensus

In these edits the sort order was changed. The default sorting order here at Commons is by language code so I don't like this change because this sort order is not logical. Multichill (talk) 14:32, 7 October 2009 (UTC)

They are ordered for the display purpose as it is easier to read for most users (non-editors). This does not change the way the parameters are passed, and that should still be preferably sorted by code. Note that the code is not visible in the display, that uses the native language name, and so it is perfectly logical to order them by native language name, exactly as they are displayed. In addition, it makes sense to group the RTL languages together so that they align properly (the code order is really not good).

Note that the multilingual extensions are all using a native language name order on display (the code order is internal only for passing the coded parameters, to avoid duplicate entries and allowing to find them easily when editing pages, and for the interwiki links, for the same reason). Please separate the editing preferences from the page display preferences (for non-editors, considering accessibility rules as more important for them) as they are separate localization targets. verdy_p (talk) 11:11, 30 October 2009 (UTC)

Note also that I added a lot of missing languages (that were actually used in pages, but were be displayed as they should). verdy_p (talk) 11:13, 30 October 2009 (UTC)

Generating the form only once, at top of page

Currently, the javascript generates the language selection form multiple times, for each multilingual division. In addition, it attempts to place the form anywhere ni the page, even if this is not the best place for it.

Could I ask that the javascript generates the same (and functionally strictly equivalent) language selection form only once within the page:

• preferably at top of page (or near the page title, if it can also be localized).
• but it could also be at the first occurence of the multilingual division ?

It would allow placing mutilingual divisions within the description of each image in a <gallery> (currently this form displays correctly there, but this is really bad design to have this form under ALL images of the gallery).

See for example the galleries in United Kingdom.

It should also be possible to translate the page sections without having to annotate their title (because adding translations to them just breaks the page anchors in the MediaWiki Summary). The Mld template would then be used first under each section.

Another solution should be developed to generate multilingual summaries, and still have editable sections). verdy_p (talk) 11:22, 30 October 2009 (UTC)

I managed to get the will back to hack my test javascript. Now It loads the language selector above content, but below image on file description pages.

If some people want to test it: just add

 importScript('user:esby/testls2.js'); 

to your monobook.js

Esby (talk) 00:00, 10 February 2010 (UTC)

Quickly tested it : it is very nice, seems to work.

However, it does not work with Image Annotations, such as in File:Berliner kongress.jpg (though I kind of expected that).

Jean-Fred (talk) 00:20, 12 February 2010 (UTC)

Images annotations seem bugged. I don't know the cause for now. Sometimes it works, sometimes it does not, it seems linked with refreshing the page.

You can also see that the german note in the description is not hidden, this is for two reasons:

• there is no {{Mld/start}} nor {{Mld/end}} block to tell the plugin to do its job.
• there needs to be at least one section with your language for the hiding to work. this is the cases for the mld note that only contains french.

Esby (talk) 09:15, 12 February 2010 (UTC)

I found the cause of the bug, but I can't fix it for now. I just have no idea on how to fix it. MediaWiki_talk:Gadget-ImageAnnotator.js#image_annotation_related_issue Esby (talk) 23:27, 12 February 2010 (UTC)

I did some coding: The new version of the script will disable itself on image annotation. The language label (english:..., french:...) will hide themselves when you are displaying only one language. Maybe I could add some background color to show when the languages are localized or not. I'll update MediaWiki:Multilingual description.js once the new version of the script has been tested on several browser. Esby (talk) 13:24, 23 April 2010 (UTC)

tests performed with user:esby/testls2.js on User:Esby/test:

• Ubuntu 9.10 - 64 bits
  • Firefox 3.5.9. OK Esby (talk) 13:24, 23 April 2010 (UTC)
  • Chromium 5.0.382.0 (44898). OK Esby (talk) 13:24, 23 April 2010 (UTC)
  • Midori 0.1.9 OK Esby (talk) 13:24, 23 April 2010 (UTC)
• Windows XP
  • Internet Explorer 8.0.6001.18702 OK Esby (talk) 12:45, 12 May 2010 (UTC)

I've put the new version here, feel free to report any issue related to it. Esby (talk) 14:47, 14 May 2010 (UTC)

Integration

How to move the template and related to another project? In particular, where to get the js it is associated?

For the javascript part, you can copy MediaWiki:Multilingual_description.js to your wiki and load it via your monobook/vector.js. Depending the usage (wiki using commons as a media base or not) there might be a few issues with the description coming from commons. Esby (talk) 08:17, 2 June 2010 (UTC)

Merge/move the javascript back in one place

Currently for everybody the old version of the javascript is loaded in the central MediaWiki:Common.js, importing ('MediaWiki:Common.js/LangSelect.js'). Since a while now the new javascript is developed at MediaWiki:Multilingual_description.js.

We could update the old one with the new code, but then everbody who had importScript() the new one will have it double. So, in order to prevent any unnneeded loading, I propose to move MediaWiki:Multilingual_description.js to MediaWiki:Common.js/LangSelect.js (deleting the latter first in order to be able to do the rename), and then blanking the redirect at MediaWiki:Multilingual_description.js with /* Emptyness */. This way everybody (both users without the manual importScript, who currently get the old version. And those who manually imported the new version, who currently get both (since the old one in Common.js applies to them also). will from now on only load the new one. Those who still have the new one manually imported in their vector.js or monobook.js will simply load an empty file addionally (still better then loading two entire files).

This'll update everybody and speed up by not double loading. If I missed anything in the above that could cause a problem (I think not), please let know so down below. If nothing heard, I'll execute the move Monday. –Krinkle^talk 14:10, 26 June 2010 (UTC)

Well, technically, I'd rather keep the two versions, while updating the old one. Speed wise, it is not an issue. I havn't seen any issue related to it. That would allow to work and debug the script while not affecting all users. You could see the script everyone uses as the stable version while the one manually loaded as the unstable one. Esby (talk) 16:20, 26 June 2010 (UTC)

Alrighty, a seperate debug/development versions sounds good. –Krinkle^talk 12:32, 12 August 2010 (UTC)

 Done - the public script is stored at MediaWiki:Multilingual description.js/public. The one the beta-testers and script writers can include is MediaWiki:Multilingual description.js. An example to override it in the custom user script:

ls_enable=false; // blocks the one in Common.js from loading
addOnloadHook(function(){ ls_enable=true; importScript('MediaWiki:Multilingual description.js); });

–Krinkle^talk 10:21, 15 August 2010 (UTC)

uselang

When we select a language, all the texts in the page using the template are translated but templates stay in the original language. That doesn't seem very logical. Can I add something like ?uselang=selected language so that the templates are translated in the same time ?--Zolo (talk) 12:34, 14 August 2010 (UTC)

Got no opinion on the subject. If you feel it might improves the situation feel free to try on a test script. Esby (talk) 20:05, 22 August 2010 (UTC)

I hadn't realised that I don't know how to do it. I've tried but didn't manage. I'm convinced that something like a merger between {{LangSwitch}}, {{Autotranslate}} and {{Mld}} would make many things simpler.--Zolo (talk) 10:15, 2 September 2010 (UTC)

The templates that use {{Autotranslate}} are not dynamic. They are based on the {{LangSwitch}} principle, in that they only show 1 language on the output page (the one that matches the users preference and/or &uselang=-parameter). Then a script shows language-links along the bottom of the template and when clicked upon it replaces the template with a translation.
{{Mld}} on the contrary shows all languages on the page, and then the script checks the current uselang and hides the others when possible. So they dont have to be merged, they both work at the same time. The central thing here is the uselang (wether it being the url-parameter or the usersetting). So if you set your language to uk-Ukrainian in Special:Preferences then you see the Ukrainian descriptions and the Ukrainian templates. –Krinkle^talk 07:52, 26 September 2010 (UTC)

Yes I see. Maybe a full merger would not be a good idea, but it would be nice if it was made easier to choose another language, especially for non logged-in users that get English by default.

There are many templates related to artworks that use langSwitch without any mld. For instance "oil on canvas" will display in the user's default language. In this kind of cases, users without an account don't have any language choice (maybe in some cases langSwitch should just be replaced by mld)--Zolo (talk) 09:33, 26 September 2010 (UTC)

Further development

I am going to work on a derivated version of the current script, to solve or enhance the following point:

• allow to detect a classname to always shows some associated captions, what ever are the settings. This would allow to load the script on the wikipedias, in order to hide the unwanted localized content of commons while showing the possibly localized content of the wikis.
• allow to suggest the user to enter a translation when none exists in his/her default language.
• allow to suggest the user to enter a translation when none exists in a list of given language code he/she previously set in his/her (mono/vector)*.js

The 'enter a translation feature' would mean to provide a link to edit the corresponding page / section. Esby (talk) 20:12, 22 August 2010 (UTC)

See Category_talk:Plaques#Multilingual_category_description and {{Mldcat}} for further suggestions. --Foroa (talk) 09:03, 26 September 2010 (UTC)

AnonymousI18n, fallback, user preferences

Hi all, I'll get right into it: I propose to slowly replace this template with {{LangSwitch}}. Not redirecting, since there are valid cases in which {{Mld}} is still wanted.

"(..) still wanted. ?", you ask ? What changed ?

Well, there's a few points in no particular order:

• {{Mld}} outputs all languages to the browser. More load, and in most cases, unneeded translations. And in case of javascript failure the list can be quite consuming and overwhelming on the better translated pages.
• {{LangSwitch}} only returns the wanted language. No more, no less, no "flash of unprocessed mld-lists" before the javascript for it is done processing the user's cookie and hiding the other languages.
• The MLD-javascript is not capable of fallbacks. Which means that the user will see English unless there is a translation into their exact language (or it will show all translations)

Since a few weeks MediaWiki:AnonymousI18N.js has been developed which is an attempt to centralize language settings for anonymous users by using cookies and ?useleang. This means that anonymous users can get translated content from

• a {{LangSwitch}}
• or {{int: }} construction such as {{int:filedesc}}, {{Self}} and {{Cc-by-sa-3.0}}
• {{Own}} templates and {{Autotranslate}} templates such as {{Welcome}}, {{Information}}, {{Test3}} and {{Blocked}}

.. which they currently either can't get into their own language or it requires extra steps which they probably won't and shouldn't have to take.

For that reason I think it's a good step to only use {{Mld}} where the intend is to "show all languages" and not where the intend is to "manage translations and display the one langauge the user wants" (which is essentially a description of {{LangSwitch}}). Especially now that LangSwitch no longer is just for logged-in users.

When people agree we shouldn't forget to unload MediaWiki:Multilingual description.js from the global site script in MediaWiki:Common.js. –Krinkle^talk 13:56, 4 January 2011 (UTC)

I honestly don't like langswitch as you are forced to look on the code to check for vandalisms in other language than you are currently browsing. Esby (talk) 14:28, 4 January 2011 (UTC)

I would clearly support harmonization of language templates.

LangSwitch is simpler and visually more pleasing that mld (no flash, no bold language names). Beside necessary linebreak between language in mld make it virtually impossible to use in some templates. If the MediaWiki:AnonymousI18N.js allows anonymous users to easily and intuitively choose the language they want to display, I think it would be much better.

I guess that with the new i18N script, the only advantage of mld will be the "all languages" option. To me this option is useful because:

• as mentioned by Esby, it makes it simpler to check for single language vandalism (is it that common ?)
• sometimes, users provide a rather detailed description in their own language plus a shorter description in other languages they do not master that well. In this case, it may be interesting to have all languages displayed.

I still think that the proposed solution's benefits would outweigh these downsides. Maybe we could add an "all languages" button for {{LangSwitch}} ? but it may get us back to the same javascript problems. --Zolo (talk) 22:46, 4 January 2011 (UTC)

I'd like to comment back on the argument that were exposed:

• The problem about 'cookie processing', an anonymous version could be set to use directly either the navigator preferred language, either the useLang parameter. This would not stop the flash effect, but I don't believe it is really problematic.
• The lack of 'fallback', the more I think about it, the more I feel this is a non argument. Langswitch is supposed to be better because it has a fallback parameter? What is the point exactly of fallbacking to chinese, when you have only russian, japanese and chinese versions present and you can't read any of those? The fallback setting should be a user setting / preference and definitely not a template parameter. Now if we decide that we must have all translation available in english, then we can allow ourselves to fallback to it. Also, the script behind {{tl[mld}} has a fallback code that displays all the available language, if the matched one is not found. The only problem I see is when you need to indicate on which language source something was translated.

Esby (talk) 10:28, 13 January 2011 (UTC)

The very next version of AnonymousI18N will have an option to show all languages. This is not a bug or an inability, simply something I forgot to implement when writing it. You can either show all languages once or keep it as your setting instead of one particular language

@Esby: I wasn't referring to that kind of fallback. I was referring to {{LangSwitch}}'s fallback mechanism. If you look at it's code you see that it uses several layers of fallback languages. For example if someone has the "Informal dutch" (nl-informal) preference they will see "Dutch" if nl-informal is not provided. Or if a Dutch Low Saxon speaker is browsing a page with only English and Low Saxon, the absence of Dutch Low Saxon will cause the second fallback layer to serve "Low Saxon". Which is still better than "English". Likewise if someone has their langauge setting to a particilar variant of Chinese (zh) but none are available it will server standard Chinese as fallback. Check the template code for more examples like these.

So, if I understand correctly from the discussion so far all that is left is the implemtation of the 'all language' option, and we're ready ? –Krinkle^talk 14:10, 13 January 2011 (UTC)

Well, on this subject, are there licence like template that uses lang-select based template, imo, if such option of showing those languages were to be implemented, it should not affect the highly used templates. (meaning, there could be a check for displaying all language based on the namespace the template being called.)

On another subject, the script behind mld now triggers even on {{En}} (supposed there are more than 5 languages in a page which means files descriptions don't have to be edited to reduce the tower of Babel effect.

Esby (talk) 12:21, 14 January 2011 (UTC)

Some corrections and changes

{{Editprotected}} Kurdish (ku) is written with Latin script, Sorani dialect (ckb) uses Arabic script though. Please also add arz, glk, ps and ug to "(RTL) Arabic", and ba and ky to "Cyrillic" section, and move war from "Indic" to "Latin" and ks from "Indic" to "(RTL) Arabic". --Z 12:39, 28 April 2012 (UTC)

 Done all except I've left ku under Arabic, because ku-latn is listed under Latin. Rd232 (talk) 15:26, 24 June 2012 (UTC)

Missing language code

Latvian (lv) is missing from here. I don't know if any other too. 90.190.114.172 12:46, 15 November 2013 (UTC)

language added. Esby (talk) 15:53, 15 November 2013 (UTC)

It hasn't been added correctly. See, for example, Baseball. Instead of showing Latviešu (Latvian, lv), followed by Lietuvių (Lithuanian, lt), it shows the Lithuanian twice — both the word "Lietuvių" and the translation "Beisbolas". I'd fix it, but all the relevant templates are frozen or protected. — Quicksilver^@ 05:19, 25 April 2014 (UTC)

Hey Quicksilver, please {{Edit request}} edits to protected templates. Thanks in advance and thanks for making us aware of the mistake. -- Rillke^(q?) 07:25, 26 April 2014 (UTC)

Fixed: Special:Diff/122296519. That was a trivial fix to Module:Multilingual description/sort. -- Rillke^(q?) 07:25, 26 April 2014 (UTC)

Machine-readable standard markup for i18n templates

I started a discussion about standardizing the markup generated by i18n templates so that it can be made machine-readable: Commons talk:Machine-readable data#Machine-readable markup for languages/language names; please share your opinion! --Tgr (WMF) (talk) 11:16, 11 November 2014 (UTC)

Issues

I have some issues with this template at File:Ansamblul „Cetate” -vedere aeriana.JPG. I can't see anything in the description, even the {{Monument istoric}} which is outside the template. Going back to {{Ro}} etc. Makes the description visible. My preferences are set to Romanian language.--Strainu (talk) 12:08, 26 September 2016 (UTC)

Please state:

• the nagivator you used,
• the os you are using.
• how to reproduce it. (because I don't see anything abnormal in the corresponding files).

Esby (talk) 07:35, 29 September 2016 (UTC)

Any OS, any navigator, but I think it's related to one of my gadgets (probably User:MarkTraceur/editDescriptions.js), since on another account it does not reproduce. I'll investigate further and report the bug at the respective script's talk page. Thanks.--Strainu (talk) 15:27, 30 September 2016 (UTC)

I can reproduce it. I get following errors (on Ubuntu):

on Chrome[ium] (53): HierarchyRequestError: Failed to execute 'appendChild' on 'Node': The new child element contains the parent.

on Firefox (49): HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy

On load it can be shown all languages are visible which than disappear. Lang select is also not visible.

↔ User: Perhelion 21:37, 6 November 2016 (UTC)

Incompatibility with User:MarkTraceurs/editDescriptions.js, which is anyway beta only (and he has declared to have no time to further develop). ↔ User: Perhelion 21:53, 6 November 2016 (UTC)

Bullet points don't get formatted correctly

{{Edit request}} See e.g. File:BlankMap-World.svg. The bullet points in different languages don't line up: the first language looks correct, the following ones don't. Cherkash (talk) 21:56, 27 February 2019 (UTC)

 Done You need an extra line before the bullets. It seems not fixable in the template itself. Although a nowiki (or space entity) on the beginning works too. -- User: Perhelion 20:36, 17 March 2019 (UTC)

Extra space

@Verdy p: Some language has an extra space before colon ( : ). Please take a look. Test:

{{Multilingual description
 | be-tarask =test
 | bn =test
 | ca =test
 | de =test
 | diq =test
 | en =test
 | fr =test
 | it =test
 | ja =test
 | mk =test
 | pt =test
 | pt-br =test
 | ru =test
 | uk =test
}}

Català: test

Deutsch: test

English: test

Français : test

Italiano: test

Português: test

Português do Brasil: test

Zazaki: test

Беларуская (тарашкевіца): test

Македонски: test

Русский: test

Українська: test

বাংলা : test

日本語： test

notice Català :, Français :, Italiano :, Português :, বাংলা : --আফতাবুজ্জামান (talk) 16:09, 15 May 2020 (UTC)

Not an error at all! And these are not regular spaces. The "colons" also vary depending on languages (some langues use other punctuation as the colon is confusive for some scripts). For various languages the space is required (at it is a narrow non-breaking space). These are defined in Template:Colon with specific rules for specific languages. Do not attempt to remove them, the single ASCII colon is not appropriate at all for various languages (in fact it does not works for most languages except English and a few Latin-written languages; it is wrong for lot of Asian languages, for Armenian, for Arabic; Armenian, Chinese, Japanese even have their own punctuation; several Indian languages require a distinction to avoid confusion with some letters). And for most Latin written languages, the narrow non-breaking spece is even recommanded for typographic reasons (including English even if this narrow non-breaking space may be removed as the traditional English narrow space is a bit thinner than in Romance languages, allowing its suppression when using legacy ASCII-only encodings and the approximations created in the time of typewriters with fixed-width fonts: this time is over, thin spaces are back even in English with proportional fonts, but for now they've not been readded, taking into account the diference of width of these thin space in English typography but also the fact that most fonts have disgned their colons to preinclude a larger gap inside their glyph without needing an extra space. You should also know that double spacing between sentences is also an old practice coming from the time of typewriters, and it also makes no sense with proportional fonts). verdy_p (talk) 06:15, 16 May 2020 (UTC)

The rules per script are these (note the important comments):

|Ethi = &#x1365;&#32;<!-- Ethiopic punctuation sign colon -->
|Mong = &#x1804;<!-- Mongolian/Mandchu punctuation sign colon -->

|Bpmf|Phpa|Tale|Talu|Yiii<!-- Indo-Sinitic scripts used along with Chinese -->
|Hang|Hani|Hans|Hant|Jpan = &#xFF1A;<!-- CJK punctuation fullwidth colon (rotated if vertical layout) -->

|Arab<!-- avoids confusion with several Arabic diacritics -->
|Armn<!-- avoids confusion with U+0589 Armenian punctuation Full stop -->
|Hebr<!-- avoids confusion with U+05C3 Hebrew punctuation sign Sof Pasuk -->
|Deva<!-- avoids confusion with U+0903 Devanagari combining sign Visarga -->
|Beng<!-- avoids confusion with U+0983 Bengali combining sign Visarga -->
|Guru<!-- avoids confusion with U+0A03 Gurmukhi combining sign Visarga -->
|Gujr<!-- avoids confusion with U+0A83 Gujarati combining sign Visarga -->
|Orya<!-- avoids confusion with U+0B03 Oryia combining sign Visarga -->
|Telu<!-- avoids confusion with U+0C03 Telugu combining sign Visarga -->
|Knda<!-- avoids confusion with U+0C83 Kannada combining sign Visarga -->
|Mlym<!-- avoids confusion with U+0D03 Malayalam combining sign Visarga -->
|Sinh<!-- avoids confusion with U+0D83 Sinhalese combining sign Visarga -->
|Tibt<!-- avoids confusion with U+0F7F Tibetan combining sign Rnam Bcad (Nam Che) -->
|Khmr<!-- avoids confusion with U+17C7 / U+17C8 Khmer combining signs Reahmuk / Yukaleakpintu -->
|Tfng<!-- avoids confusion with U+2D53 Tifinagh letter Yu (Touareg Yaw) -->
|Zinh-nbsp-Po-space = &nbsp;&#x3A;&#32;

|Zinh-nnbsp-Po-space = &#x202F;&#x3A;&#32;
|Zinh-Po-space|#default= &#x3A;&#32;

For Latin, there are two rules, one with NNBSP, another without it (e.g. English). Most Romance languages use the traditional NNBSP (which also avoids some confusions where the colon may have also other usages, e.g. in Swedish). Note the pounctuation sign itself changes, and for Indic scripts, the NNBSP is not even sufficient because of the Visarga sign and replaced by a larger NBSP. Removing thes NBSP would create a confusion with Visarga (the same applies with Arabic diacritics, the Armenian full stop, and one Tifinagh letter). verdy_p (talk) 06:22, 16 May 2020 (UTC)

The languages are not switched on the whole page, only in the first instance encountered

{{Edit request}} See e.g. File:BlankMap-World.svg. The first place (framed "Editor's note") switches correctly, but the second place ("Description" box in the "Summary" section) contains all languages together without them being switched. Cherkash (talk) 21:56, 2 June 2020 (UTC)

@Cherkash: First, this is not an edit request; questions and support requests should go to COM:VPT or other similar pages. Second, {{Mld}} is not used in the information template, so it naturally works differently, which means for example that it’s not collapsed if there are less than four languages. —Tacsipacsi (talk) 23:18, 4 June 2020 (UTC)

@Tacsipacsi: What would you suggest using in information templates? Ideally, it would switch languages on request, just like {{Mld}} does, but if not then it could just list them all without switching (but by using appropriate language codes). Cherkash (talk) 23:27, 4 June 2020 (UTC)

@Cherkash: What do you mean by “using appropriate language codes”? The current version doesn’t switch languages; the source code contains language codes that are easier to maintain, but it displays language codes that are easier to understand by readers of that language (everyone will know the autonym of their language, but may not know its code, and uniform codes are less easy to distinguish at first sight). I like the current situation, but using {{Mld}} is also a possibility. —Tacsipacsi (talk) 14:34, 5 June 2020 (UTC)

Adding a tooltip to display the name of particular languages in the user's local language

I suggest we add a tooltip that would allow users to read the name of foreign languages in their local language, just like it currently works on Wikipedia. –Iketsi (talk) 14:42, 3 February 2021 (UTC)

Line-spacing

This template seems to give an unusually small line-spacing. The result is harder to read and looks out-of-place compared to other content. Compare:

Regular text	{{Mld}}
English: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. French: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.	English: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Français : Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
English: Testing French: Testing	English: Testing Français : Testing

Is that a default in this template or as a result of some lower-level template that is called here? DMacks (talk) 05:29, 24 March 2021 (UTC)

It's an effect of line-height: normal; in {{Ls}}. @Verdy p: who did some experimenting with that value. Why are we defaulting to compressed spacing, instead of using whatever the surrounding context is? If I scrap that (or have Module:Multilingual description pass |CSS-box=line-height:unset; to cause it to be ignored), spacing is matched. DMacks (talk) 17:32, 24 March 2021 (UTC)

This is because of internationalization (the forced "large" line-height is not good with many Asian fonts, we can just use the default; this still does not change the paragraph margins that separate items in tall lists of languages); And when there are many translations displayed, this is much more readable as each language is clearly separated in it own paragraph, the whole list not expanding vertically as much. Note that tjhis applies only to (multilingual) descriptions, they appear in long lists if there's no language selection, or the user's selected language is not in the multilingual list.

This Mld template (which actually generates a list item prefixed by the native language name) however is legacy: it does not support any language fallback, and requires Javascript to filter it... sometimes. It is very boring and adds another language selector in the page (which contradicts the ULS which is the language really prefered by the user for the UI. Most of the time it does not work as expected except for English-speakibng users where the filter works almost always. For all others, we get long lists of languages and users have to seek the description.

The Mld description items (Ls) are normally very short paragraphs (not a lot of sentences). This old template also does not well when you need to place multiple "MLd" sections, each one translated separately: each one will generate a new vertical list... The alternative is usually to use autotranslation in the user's language directly). It is only made to fit correctly in the infobox of image description pages, everywhere else the forced linehight in a multilingual context (mixing languages in multiple scripts) is very poor. And I don't see why the font-size;normal would not be correct for foratting a paragraph that should always be short (noting that it already also has its own vertical margins of .6em which adds to the line-height). verdy_p (talk) 17:49, 24 March 2021 (UTC)

I agree that a separation between language entries can help with visual clarity. But the forced narrowing of the lines within a language makes it harder to read the individual English (and German and French...) blocks themselves, and there is actually also less space between languages than between normal paragraphs. The site-wide style defaults are what they are presumably based on broad consensus for a variety of reasons including legibility within a block of text and to distinguish between separate ones. DMacks (talk) 19:04, 24 March 2021 (UTC)