Use the locale specific language name in languages

NEW
Assigned to

Status

()

defect
P2
normal
9 months ago
5 months ago

People

(Reporter: mstriemer, Assigned: mstriemer)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 obsolete attachments)

(Assignee)

Description

9 months ago
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 :-\
Posted 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
Posted 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
You need to log in before you can comment on or make changes to this bug.