288670 - Use intl.accept_languages to choose the locale for a package if the current locale is unavailable

Status: NEW

(Toolkit :: Startup and Profile System, enhancement)

Description

[Greg Campbell]

This is looking for a better solution to bug 279952, prompted mainly by bug
279952 comment 3.

Steps to Reproduce:
1. On a clean fi-FI FF, install an extension that doesn't support fi-FI.

Actual Results:  
Extension installs in en-US. (because of bug 279952)

Expected Results:  
Firefox should select the locale from the user's intl.accept_languages. If still
no match, Firefox should present a list of the languages in which the extension
has been localized, allowing the user to choose whichever is preferred.

The dialog should probably have a checkbox saying "Always fall back on this
language" which would add the selected language to intl.accept_languages.

Comment 1

[Benjamin Smedberg]

I don't think we should present a list. We should follow the
intl.accept_languages pref.

Comment 2

[Greg Campbell]

Say a user is using the pl-PL build, also reads German, Russian, and Esperanto,
but not English. The user would have to have gone into the Language options and
added de, fr, and eo to the list to get the extension in a preferred language.

I don't know if adjusting this pref is commonplace among multilingual folks. If
it is, your point is valid. If it's not commonplace, allowing the user to select
a (possibly) more familiar language at extension-install-time seems better than
arbitrarily defaulting to en-US.

I assume most extensions are currently only available in English, but for the
optimistic future, this enhancement seems like a good idea to me.

Comment 3

[Tuukka Tolvanen (sp3000)]

The default intl.accept_languages pref for fi-FI is "fi, en", so the proposed UI
would never be shown when using intl.accept_languages as fallback before it
(assuming the extension supports English, which they may or may not have to; and
assuming the user hasn't removed 'en' from accept_languages). Haven't looked,
but I'd guesstimate that the same holds for other localizations as well.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I don't think it should follow intl.accept_languages pref. I think we should create another intl.ui_locale_fallback pref in about:config.

People might prefer to read different languages between web content and browser UI.

This bug is extremely important to Hong Kong users, if they wish to create their own version of Firefox and related software. Traditional Chinese and Simplified Chinese both use the language code 'zh', and a proposed zh-HK Firefox (Trad. Chinese) would inevitably fall back to zh-CN (Simp. Chinese) instead of zh-TW without this pref.

We can not create zh-HK Firefox without fix this bug first. So HK people please vote here :-P.

Comment 5

[Zeroth Yu (余弘志)]

I think if this bug can not be fix, we still have to fix the locale fall-back of zh-HK, we have to change the first fall-back locale to zh-TW and not zh-CN. If this bug can not be fixed, we can not create the Hong Kong version without fixing this bug.

P.S. I am the L10n Manager of the Hong Kong personal version in the MozTW discuss forum. (My nane is Zeroth Yu!)

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> I think if this bug can not be fix, we still have to fix the locale fall-back
> of zh-HK, we have to change the first fall-back locale to zh-TW and not zh-CN.
> If this bug can not be fixed, we can not create the Hong Kong version without
> fixing this bug.

Can you elaborate on what you are talking about here?

Comment 7

[Ho Fung Wong]

I agree with 余弘志.  Hong Kong seldom uses simplified Chinese, so it makes sense for zh-hk to fallback to zh-tw (traditional chinese locale) if zh-hk is unavailable.  Currently, when zh-hk falls back to zh-cn (simplified chinese locale) which makes no sense at all.  It would be the best if Mozilla can show a list for us to choose the extension's locale that users want.  This gives users the most flexibility.

Comment 8

[hkytrewq]

(In reply to comment #6)
> (In reply to comment #5)
> > I think if this bug can not be fix, we still have to fix the locale fall-back
> > of zh-HK, we have to change the first fall-back locale to zh-TW and not zh-CN.
> > If this bug can not be fixed, we can not create the Hong Kong version without
> > fixing this bug.
> 
> Can you elaborate on what you are talking about here?

I believe I understand what he is talking and I can help him to explain more about it. For a foreigner without the background knowledge of Chinese characters, it's a bit confusing at the very first time.

At this moment, FireFox has officially released two Chinese versions, the zh-CN and zh-TW. The zh-CN is in simplified Chinese and is for users from the mainland China, while the zh-TW is in traditional Chinese and is for users from Taiwan. As both the users from Hong Kong and Taiwan are using traditional Chinese, one may think that users from Hong Kong can use zh-TW. However, because of the cultural difference between Hong Kong and Taiwan, zh-TW version cannot fulfill all the needs of them and some users are making zh-HK version.

In the development of zh-HK version, they are facing such a problem: If the FireFox is zh-HK and one install an add-on which include zh-CN and zh-TW but not zh-HK, the result is that the zh-CN (simplified Chinese) is chosen. But users from Hong Kong would expect traditional Chinese whenever it is available and hence the language preference is zh-HK > zh-TW > zh-CN > en-US.

That's why he is calling for such improvement. And of course, I support this.

Comment 9

[Axel Hecht [:Pike]]

The standard algorithm for fall back from locale to locale by dropping the specificiers one by one isn't the best, yeah.

This shouldn't only benefit Chinese, but also minority languages like Occitan or Catalan even.

I'm not 100% convinced that we need to have a new pref in addition to accept_lang, though. That's already user-customizable with a localized default, and I have a hard time seeing a scenario where the user's choice of languages would be cool for web pages but bad for UI.

I don't see us trivially fixing this on a per-extension basis, as the chrome registry handles this per package, which has little to do with the installable bundle that that thing came with.

Comment 10

[Dave Townsend [:mossop]]

I think allowing the user to customise per extension is going over the top. We should just have the chrome registry follow intl.accept_languages so moving this over there. Possibly we might want a service to select the best locale given a list of available locales since we already have some code doing this in the EM, some in the registry and I think some elsewhere.

Comment 11

[[:Aleksej]]

Related: bug 562648.

Comment 12

[lungzenoopen]

Maybe other people don't know.

en-GB and en-US are different only in spellings of words (and more larger language structures). Besides spellings of words, Simplified Chinese and Traditional Chinese are two different character sets.

Simplified Chinese and Traditional Chinese are both proper names. Simplified Chinese doesn't refer arbitrary Chinese languages that are simplified. The word "Simplified" in Simplified Chinese doesn't mean like Simple English. It refers simplification in characters. For the purpose, a lot of compound strokes and character components were invented by mainland China government.

Also, the simplification of Simplified Chinese bases on Putonghua language, not Cantonese language nor any other language in Chinese language family.

Excepting Unicode that covers all modern earth languages, Simplified Chinese and Traditional Chinese are used by different character encodings.

Hong Kong users are unfamiliar with Simplified Chinese from character level. If zh-HK is unavailable, Hong Kong Chinese users expect zh-TW. English is second language of Hong Kong society. For example, if Traditional Chinese locales are all unavailable, I expect English locales rather than zh-CN. My language preference is zh-HK > zh-TW > en-US.

Franch is so easy relativity to be learned by native Enlingish speakers. Similarly, Simplified Chinese is so easy relativity to be learned by Hong Kong native Chinese speakers. However, Hong Kong users are usually familiar with English. In my opinion, the user interface only with Traditional Chinese character or English character, no Simplified Chinese characters, makes me much more comfortable.