Closed Bug 1476781 Opened 6 years ago Closed 2 years ago

Use the locale specific language name in languages

Categories

(Firefox :: Settings UI, defect, P2)

defect

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox97 --- verified

People

(Reporter: mstriemer, Assigned: mstriemer)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

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
Per discussion with Emanuela, we also need the country code when it's meaningful
https://docs.google.com/document/d/1zqBRFVHKVeRI40JJtTNB1X34oE1WlhZyFKMFvQ-n-Ak/edit
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.
(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.
> 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)").
> 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.
(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 :-\
Attached file languages.json (obsolete) —
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
Attached file languages.json (obsolete) —
Attachment #8996281 - Attachment is obsolete: true
Depends on: 1481729
Comment on attachment 8996288 [details]
languages.json

Moved the discussion about the JSON to bug 1481729
Attachment #8996288 - Attachment is obsolete: true
Blocks: 1425941
See Also: → 1648800

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!

Pushed by bzhao@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/32b17a075e9a
Use the locale specific language name in languages. r=platform-i18n-reviewers,preferences-reviewers,dminor
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

(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)

(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?

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.

Depends on: 1749248
Depends on: 1749369
Flags: qe-verify+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: