LocaleService serves two main functions. It is a central place for all code in the
engine to learn about locales, but it also does the language negotiation and selection.
The former is relevant in all processes, but the latter should only be performed
by the "main" process. In case of current Desktop Firefox, the parent process
is the one performing all the language negotiation, and content processes should
operate in the "client" mode.
In Fennec, there's a Java app on top of Gecko which should work as a "server"
and then all processes, including parent process of Gecko is merely a "client" for that.
This refactor finalizes this duality making it easily configurable to define in
which mode a given LocaleService operates.
The server-client model allows all clients to stay in sync with the server,
but operate transparently for all callers just returning the right values.
In order to initialize LocaleService in the client mode in child process with the
right locales I'm adding the list of app locales to the XPCOMInitData,
and then fire LocaleService::SetAppLocales in the child process initialization.
In order to keep the list up to date, I'm adding intl:app-locales-changed to
the list of observed topics, and when triggered, I send the updated list
to the child process, which updates LocaleService::SetAppLocales with the new
list.
MozReview-Commit-ID: K9X6berF3IO
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
intl/uconv/util/nsUCSupport.cpp:552:34 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: Emk05qDJHbm
StringBundle caches bundles, so when language chain changes we should
flush the cache to enable new strings to be loaded.
This also affects localized prefs like intl.accept_languages.
Then in HttpHandler we have to mark the value as dirty so that next
time it's called it actually recalculates using flushed string bundle
with the new locale.
MozReview-Commit-ID: DKWEDUli4yH
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
CLOSED TREE
Backed out changeset 1cce9249b4a2 (bug 1351200)
Backed out changeset 792fb55377f5 (bug 1351200)
Backed out changeset 767bee78574c (bug 1351200)
After landing bug bug 943283, no one uses nsIPlatformCharset::GetDefaultCharsetForLocale. Also, nsIPlatformCharset isn't scriptable interface, so it is unnecessary now.
MozReview-Commit-ID: Giy68AS9yK2
This patch fixes a regression that we hit on Fennec when we handed over control
over language negotiation to LocaleService in bug 1347306.
The problem is that we currently do not have good Android bindings for
OSPreferences::GetSystemLocale and in result we could not negotiate
languages between user-selected OS locales and available locales.
The temporary solution implemented here binds android OS preferences to
`intl.locale.os` pref which is set on Locale:OS event in browser.js.
In LocaleService we add a listener on the pref to renegotiate languages
when OS locale changes.
MozReview-Commit-ID: KTqjYSzLNNO
Beta and release channel of Android still turn off ICU. So we should add UTF-8 version of nsICollation for fallback.
Some people want to keep --enale-intl-api=no for faster build on developer environment, so even if non-Android, it will be required.
MozReview-Commit-ID: 3RcjqoVip1W
nsICollation for macOS version uses ICU, so we should use it on all platform since nightly and aurora can use ICU on all platform.
MozReview-Commit-ID: 4nTzDCjOQXJ
nsCollation.cpp implements nsCollationFactory and nsCollation utils classes.
To remove nsIPlatfromCharset dependency, I would like to remove nsCollaction utils class. So at first, I would like to rename it to nsCollactionFactory.cpp. (then, nsICollation implementation will be nsCollation.cpp)
MozReview-Commit-ID: FaG3vfzi9cl
After landing bug 1301640, 1st parameter of nsIScriptableDateFormat.FormatDateTime() is ignored now. So it is unnecessary to create nsILocaleService from locale parameter.
MozReview-Commit-ID: GlqC0D9shdy
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
In cases, where the caller is looking for the locale to be used for JS Intl API,
we can now replace it with `undefined` which causes JS Intl API to use the default
locale which since bug 1346674 is resolved to the app locale.
This allows us to remove a lot of calls for the app locale.
The remaining ones are split between `AsBCP47` and `AsLangTag`.
Here, the `AsLangTag` is used, as described in the API docs, for cases where
the language string is used for localization purposes, such as language negotaition
matching to our language resources etc.
`AsBCP47` is used when the returned value is handed over to ICU API.
MozReview-Commit-ID: DzmFEUvMq3N
