I18n API should expose language negotiation API

NEW
Unassigned

Status

()

Core
JavaScript Engine
4 years ago
3 years ago

People

(Reporter: gandalf, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
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)

Updated

3 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.