API for BCP 47 language tags

[marcoscaceres]

(cloned from bugzilla)

The ECMAScript Internationalization API Specification describes a number of abstract operations to process BCP 47 language tags. Some of them might be useful to expose as public API:

• IsStructurallyValidLanguageTag
• CanonicalizeLanguageTag
• CanonicalizeLocaleList
• LookupMatcher

[marcoscaceres]

Given that the algorithms are all in place in the spec, we just need to come up with some kind of shape for this API.

Given Intl object just serves as a namespace with a bunch of constructors on it, so it seems like an ok place to hang some of the above functionality off. As language tags are just data, it might not make sense to make a class for them (i.e., no new Intl.LanguagTag(foo)).

So, question is, do we just want a bunch of methods off Intl? Like:

• Intl.isStructurallyValid( locales )
• Intl.canonicalize( locales ) // both CanonicalizeLocaleList CanonicalizeLanguageTag

I'm not sure how to best expose LookupMatcher (.findBest(locale)?), so would like to hear ideas.

[rwaldron]

So, question is, do we just want a bunch of methods off Intl? Like:

No, but only because it would be better to be more specific, eg:

• Intl.LanguageTag.isStructurallyValid(locales)
• Intl.LanguageTag.canonicalize(locales)

But that's just for illustration at the moment.

[marcoscaceres]

Yeah, I was thinking the above too. Just thought people might get confused with LanguageTag not being a constructor, like the others.

[caridy]

Intl.LanguageTag sounds good, but what about the other 2? and potentially other abstract operations in the future? (I'm thinking about pluralization resolution, and other stuff that we plan to add at some point). Are we willing to have multiple namespaces under Intl just to organize those methods? Normally, I'll push back on namespaces, but that's just me :).

[zbraniecki]

I would actually like to consider separating Locale object out of Intl object. The Locale object would handle LanguageTag operations like canonicalize and validation plus it would handle Language Negotiation.

Mostly, it would take out all of the locale related code that is right now hidden inside Intl API, and expose it. Then Intl API would use Locale API, and localization API would also be able to use it.

Here's an example of how it might look like: https://raw.githubusercontent.com/zbraniecki/l20n.js/v3-webl10n/examples/api/js/locale.js

[zbraniecki]

@caridy - what's your take on Intl.Locale? I'd be happy to champion that, but I don't have much experience so I'd need some guidance.

[srl295]

Lookup matchers etc would be helpful in implementing Accept-Language style matching in user code

[caridy]

@zbraniecki we had a quick side conversation about this today at TC39, I plan to get more bikeshedding on the next two days, and we can make a decision about where to put them.

As for help and guidance, you will get all the help you need if you're willing to champion this for the November meeting when we plan to push for many Intl stuff for the 3rd edition, I promise.

[zbraniecki]

cool. I'll be at the Nov meeting btw! Can you point me to any docs on how to design a spec?

[zbraniecki]

Proposed Intl.Locale as #46. Can we close this issue?