Add English names to Select Language dialog

[AntonKhorev]

Useful to have for names in scripts you can't read and maybe even don't have a required font.

[tomhughes]

Looks good to me, thanks.

[1ec5]

It’s unusual to have a choice between “Traditional” and “Hong Kong”. I guess Chinese speakers will infer that the “Traditional” option is Taiwanese, but it’s kind of awkward.

[tomhughes]

It should probably say Taiwan instead of Traditional there I guess as we have two versions of traditional?

[1ec5]

Hm, looks like this is based on Translatewiki.net’s language code mapping. They uses zh-Hans and zh-Hant for Simplified and Traditional, with zh-Hant-HK as an override for the Hong Kong standard of Traditional (similar to how our en-GB overrides whatever en is). They’ve disabled other national variants for translation. That means MediaWiki only has these three localizations too, but their language switching UI shows all the other national variants as aliases, like zh-SG as an alias to zh-Hans.

The choice between zh-CN, zh-TW, and zh-HK is aligned with Windows preferences, but these days most other platforms and libraries use both script and country codes for Chinese, so some users set those instead (see #2647, sort of). mapbox/mapbox-gl-language#67 would ensure a reasonable fallback regardless of the form of language code.

@mapmeld, am I barking up the wrong tree, or is there a more sensible set of options we could expose? We can take it to a separate issue if so.

[AntonKhorev]

English names are copypasted from whatever Translatewiki has in their files with some changes like Traditional Chinese => Chinese (Traditional) in case I want to sort by that name.

[mapmeld]

I think it makes sense to keep Simplified, Traditional, and Hong Kong options in the language menu.
In the diaspora / Chinatowns in the US, there are many people who continue to use Traditional Chinese (Reddit), and when I visited Kuching, Malaysia there were signs with both.
Setting the page language to Hong Kong can change the appearance of fonts. I don't have specific character examples, but Google does have a separate Noto Sans HK font: https://fonts.google.com/noto/specimen/Noto+Sans+HK
On vector map labels, both zh-TW and zh-HK will be resolved to name:zh-Hant as that's what's available in the language plugin and vector tile providers. When I was reviewing tagging in Hong Kong, about 5% of places have name:zh-Hant or name:zh-Hans, and virtually no places use name:zh-HK or name:zh-Hant-HK, so I don't think we need to change anything there.

[1ec5]

To be clear, I was asking about whether the Traditional and Simplified labels should be more specific. I definitely wasn’t asking to remove any options.

[AntonKhorev]

You could have asked this question about the existing labels. I don't know if Translatewiki contributors translate to Traditional or Taiwanese and if there's any difference between these.

[1ec5]

Yes, the question was about what to call zh-Hant in general, not just in English. It’s OK if we don’t have a clear answer on that. If we can ensure fallbacks between zh-TW and zh-Hant, then it won’t matter so much.

[1ec5]

Are we hard-coding English only because most fonts support it, or are there other reasons? Translated language names would be useful to users who want to see the map in a language other than their own, but in that case, we should try to localize the language name into the current language, falling back to English. I think we can assume that the user has an adequate font for the language they currently prefer.

/ref #5201 (comment)

[tomhughes]

It's complicated - doing "name in current language" is certainly potentially useful (but harder) but name in english is possibly more helpful when you're trying to select a language you don't speak, and more importantly where you don't read the script at all.

[1ec5]

We use Intl.DisplayNames elsewhere to show an arbitrary language’s name in the currently active language:

openstreetmap-website/app/assets/javascripts/index/element.js

Line 114 in c0debf6

const localeName = new Intl.DisplayNames(OSM.preferred_languages, { type: "language" });

If an English speaker flips to Marathi out of curiosity, this change helps them find it by the English name, and they’ll also be able to switch back to English easily, because the main link text will always say “English”. Then they can go to any other language using the English name again. However, a Greek speaker won’t have the same luxury of finding Marathi by the Greek name without recognizing Marathi’s writing system or language code.

[AntonKhorev]

I think we can assume that the user has an adequate font for the language they currently prefer.

Not true as soon as you click on any language that doesn't have a font.

[1ec5]

Here are the scenarios I’m imagining:

• The user prefers Portuguese. They can read Portuguese and have fonts for Portuguese. They want to view the map in Greek out of curiosity. They have fonts for Greek, but they don’t know that “Ελληνικά” means Greek. Seeing “grego” underneath would help them find it.
• The user prefers Portuguese. They can read Portuguese and have fonts for Portuguese. Then they click on “��������”¹ by accident. Unfortunately, they don’t have Greek fonts installed, so they see ���� ���� ���� all over the website. Fortunately, they can still return to Portuguese by clicking on “português”, which they can still read. They know how to say Portuguese in their own language. They don’t need it to say “Portuguese” underneath in English.

It seems like this change is optimizing for the following scenario instead:

• The user prefers Portuguese. They can read Portuguese and have fonts for Portuguese. Then they click on “��������”¹ either by accident or out of curiosity. Unfortunately, they don’t have Greek fonts installed, so they see ���� ���� ���� all over the website. Now they want to switch to Yiddish, but they don’t have the fonts for Yiddish either, so they don’t know to click on “�������”². They know some English, so if we add “Yiddish” underneath, they’ll be able to find it.

I don’t think we can necessarily assume that the user speaks English. A Portuguese speaker won’t recognize “Yiddish”, because it looks too different than “iídiche”. It seems to me that we should expect a user who is already lost to go back to their own language before trying out another language they don’t speak.

In any case, I brought this up because it’s only a matter of time before people come to us asking why the language settings modify the whole interface except for the language switcher, which remains in English. They’ll want to know how to translate it.

Footnotes

1. Ελληνικά, Greek in Greek. ↩ ↩²

2. ייִדיש, Yiddish in Yiddish. ↩

[HolgerJeromin]

In any case, I brought this up because it’s only a matter of time before people come to us asking why the language settings modify the whole interface except for the language switcher,

which remains in English.

But this is not correct!
As far as I understand this PR (it is not live yet) the language switcher now offers target language AND English.

[1ec5]

Right, each language will be labeled with both the native name and the English name – but not the name in the currently selected language. I think we’re going to get people wondering why there’s bits of English that never change no matter what you set as your language. It’s a very unusual approach.

[AntonKhorev]

@1ec5 If you propose using new Intl.DisplayNames([lang], { type: "language" }).of(lang), you can open a new issue, then I'll ask you what are your plans for lang = be-Tarask, lang = aln and other corner cases, and you'll be able to describe your plans in a place more convenient than comments for a merged pull request.

[1ec5]

Sure, I’m not trying to make a scene, just trying to better understand the rationale for this change. But I opened #6319 to try to articulate an alternative.