Open Bug 889616 Opened 7 years ago Updated 6 years ago

I18n API should expose language negotiation API


(Core :: JavaScript Engine, defect)

Not set




(Reporter: zbraniecki, Unassigned)


The Ecma 402 API introduces very nice API for language negotiation, but makes it non-public.

In particular, two functions: LookupSupportedLocales and CanonicalizeLanguageTag are very useful for localization libraries.

In L20n we exposed them together with one wrapper function that we named prioritizeLocales.

prioritizeLocales takes three arguments:
 - availableLocales
 - requestedLocales
 - defaultLocale

It canonicalizes all the input and builds a list of available locales that match user requestedLocales, adding defaultLocale at the end if needed.

One addition to that is that we had to fork LookupSupportedLocales into LookupAvailableLocales because the former one returns the list of *requested* locales, not *availalable* ones.
The difference translates into returning "es-MX" when "es" is available which is pointless for localization library which needs to pick the available locale for app localization.

It would be very helpful for localization frameworks to have access to CanonicalizeLanguageTag and LookupSupportedLocales at least.
It would be even better to have LookupAvailableLocales as well.
Summary: I18n API should expose language negotiation AP → I18n API should expose language negotiation API
You want to bring this up on the es-discuss list.  We don't extend the language in advance of rough consensus on standardizing APIs any more.

I'd expect not exposing this stuff was a deliberate design decision, but I could be wrong.
Any update on from ES-Discuss or Norbert?
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.