1476781 - Use the locale specific language name in languages

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P2)

Description

[Mark Striemer [:mstriemer]]

The languages section is currently using the language name in the current locale, but it would be better to use the name in the target language.

STR
  1. Go to change your language to French from English
  2. Search for "Français"

Expected
  "Français" is an option
Actual
  "French" is the option for this langugae

Comment 1

[Francesco Lodolo [:flod]]

Per discussion with Emanuela, we also need the country code when it's meaningful
https://docs.google.com/document/d/1zqBRFVHKVeRI40JJtTNB1X34oE1WlhZyFKMFvQ-n-Ak/edit

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

This basically means that instead of using mozIntl.getDisplayLocale/Language/Region we want to construct a single (JSON?) file with a map of languages and regions to their local names.

The benefit of it is that it'll be significantly cheaper, will not scale payload with langpacks, and can be easily maintained and extended.

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #2)
> will not scale payload with langpacks

Can you explain this one a bit more?

A single JSON would work for me, and it can be easily extended when we add a new locale to nightly builds. 

What's the strategy if a locale is missing from the JSON (e.g. non official language pack installed locally)? Would it be cheap to use mozIntl as a fallback? 

We'll need that for the dictionaries anyway, at some point, since we don't really control the list of supported languages.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

> Can you explain this one a bit more?

Currently we carry a list of language and region names *per locale*. Which means that if we ship Firefox en-US, the user has a list of all language names and region names in English American.
Then, if the user installs Spanish langpack, they get a list of language names and region names in Spanish. And for each new locale they install, they add another list of language names and region names. That's ~485 entries per locale.

If we want to present the user language name *in its native form*, then we only need a single list of language names where each language code has a value of the language name in its native language. That means at most a list of 485 entries *irrelevant* of number of installed locales.

That's cheaper. :)

If we can then extend this model to all places where we currently use languageNames.properties/regionNames.properties, we'll be able to remove them and make per-locale data smaller.

> What's the strategy if a locale is missing from the JSON (e.g. non official language pack installed locally)? Would it be cheap to use mozIntl as a fallback? 

We currently don't carry CLDR data for the language names / region names. My suggestion would be that we'd present the locale code in that case ("es (CL)" instead of "Spanish (CL)").

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

> We currently don't carry CLDR data for the language names / region names. My suggestion would be that we'd present the locale code in that case ("es (CL)" instead of "Spanish (CL)").

Alternatively, we could add a field to langpack manifest with the locale name it is for and present it.

Comment 6

[Francesco Lodolo [:flod]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #5)
> > We currently don't carry CLDR data for the language names / region names. My suggestion would be that we'd present the locale code in that case ("es (CL)" instead of "Spanish (CL)").
> 
> Alternatively, we could add a field to langpack manifest with the locale
> name it is for and present it.

We would require that also for dictionaries. 

And I realize this would solve another issue: there are 3 German dictionaries, they could have different "locale name" if we assume that's a free-text string. Also found a bug about that scenario :-\

Comment 7

[Francesco Lodolo [:flod]]

Attachment: languages.json

I've played a bit with CLDR and came up with this JSON [1]

CLDR has, in most cases, the language name in the native language, e.g.
https://github.com/unicode-cldr/cldr-localenames-full/blob/master/main/it/languages.json#L253

And rules to capitalize the language or UI list or menu
https://github.com/unicode-cldr/cldr-misc-full/blob/master/main/it/contextTransforms.json#L22

Also http://cldr.unicode.org/translation/capitalization about capitalizing names.

[1] https://gist.github.com/flodolo/23844c17dc349542627e1367d061b7ee plus some manual modifications

Comment 8

[Francesco Lodolo [:flod]]

Attachment: languages.json

Comment 9

[Francesco Lodolo [:flod]]

Comment on attachment 8996288 [details]
languages.json

Moved the discussion about the JSON to bug 1481729

Comment 10

[yxu]

Hi, is there any progress on this bug?

Comment 11

[Hector Zhao [:hectorz]]

Attachment: Bug 1476781 - Use the locale specific language name in languages. r=#platform-i18n-reviewers!,#preferences-reviewers!

Comment 12

[Hector Zhao [:hectorz]]

Hi, I understand with Intl.DisplayNames now available, a more thorough update to mozIntl.get{Language,Locale,Region}DisplayNames might be warranted. But before that happens properly, I'm hoping this patch might be seen as a minimal enough incremental improvement, that is acceptable? Thanks!

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32b17a075e9a
Use the locale specific language name in languages. r=platform-i18n-reviewers,preferences-reviewers,dminor

Comment 14

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/32b17a075e9a

Comment 15

[eloli]

(In reply to Hector Zhao [:hectorz] from comment #12)

Hi, I understand with Intl.DisplayNames now available, a more thorough update to mozIntl.get{Language,Locale,Region}DisplayNames might be warranted. But before that happens properly, I'm hoping this patch might be seen as a minimal enough incremental improvement, that is acceptable? Thanks!

I have some suggestions. Please check my email 👉 IMG: https://s2.loli.net/2022/01/10/fY1uW7UJdQMOZoa.png)

Comment 16

[Hector Zhao [:hectorz]]

(In reply to eloli from comment #15)

I have some suggestions. Please check my email 👉 IMG: https://s2.loli.net/2022/01/10/fY1uW7UJdQMOZoa.png)

The email is in Chinese, as I understand it, eloli from comment #15 is expressing their preference of certain native language names from 1, which is already being used in places like {addons,www}.mozilla.org.

:flod, maybe you can comment on the difference between the lists?

Comment 17

[Francesco Lodolo [:flod]]

The list has been generated in bug 1481729, starting with CLDR data and doing manual corrections where needed. Other Mozilla websites are likely using a very old hard-coded list (product-details), and maybe that's the list that should be updated, not this one.

It would help to have more context on why the change would be needed, and what the difference is (and which locale is affected). That conversation should happen in public bugs, not email threads, so I strongly suggest to file a separate bug for it.

Comment 18

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using an affected Nightly build from 2022-01-01, under macOS 11.

The bug is verified as fixed on the latest Beta 97.0b5, across platforms: Win 10 x64, macOS 11 and Win 10 x64.