On Tuesday, February 7, 2017 at 2:33:05 PM UTC-8, Gijs Kruitbosch wrote: > Please can you add an alias into Services.jsm so that > Services.locale.<whatever> works ?
Yeah, filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1337551 > > Also, that particular API looks like it might as well be a readonly > attribute, which allows more concise use from JS while looking the same > from C++: > > const {appLocales} = Services.locale; Good idea, I'll discuss it with :jfkthame. > I'm confused. The reason I normally ask for the locale that's currently > in use from the chrome registry is because I want to know whether > strings are going to be available for the feature I'm working on (esp. > when relating to uplifts), based on a list I have with locales that have > strings. And that's a valid use-case for which you will want to use the `GetAppLocale`. There are other use cases which do benefit from the access to fallback chain, like Intl formatters, collators etc. > Conversely, if we're going to start providing the OS locale (which might > not be reflected at all in the Firefox UI) as the first/top locale We will not. > Worse, what happens in a situation where: > 1) I'm using my OS in French > 2) I'm running en-US Firefox > 3) I'm installing an add-on that ships with localization into French. If your negotiated locale fallback chain for Firefox has 'en-US' as the first locale, and the addon has en-US translation we will use it. So generally yes, we'll try to keep the UI translation consistent as much as we can across the whole product. But we may benefit from the ability to fallback on something better than last resort for some operations in edge cases where we do not have data for your first locale. > Do I just misunderstand what the goal of this > API is or how it's supposed to work? Can you clarify? Hope that helps! zb. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
