Validation of 'calendar', 'collation', and 'numberingSystem' options about proposal-intl-locale

[zbraniecki]

BCP47 separated "valid" and "well-formed". I'd like us to support "well-formed" here.

That means that your example of "en-u-nu-!@-#asdf" will not work because it doesn't match:

extension = singleton 1*("-" (2*8alphanum))

but, en-u-nu-foo should parse and I believe in result new Intl.Locale('en', {'numberingSystem': 'foo'}) should as well.

[anba]

new Intl.Locale("en", {hourCycle: "h99"}) currently throws a RangeError, should this also be changed?

[zbraniecki]

I believe so. @littledan @srl295 ?

[zbraniecki]

My intention here is that we should not cap the values that are well-formed and potentially supported by some language tag parsing code just because our APIs don't support a certain value.

For example, maybe at some point UTS will add hc-h28 and maybe ECMA242 will not support it for a while. That doesn't mean that Intl.Locale must reject such code.
A user may use Intl.Locale to compare/retrieve language or script portion of the tag, but keep carrying such a language tag around because some part of their code actually recognizes h28 as a valid hourCycle.
So, yeah, I'd suggest we stick to well-formed for this API.

[anba]

(Note: Updated the issue description to note a possible problem with the third choice.)

[littledan]

I'm not sure if ICU contains an API for this validation, cc @jungshik . The question here is closely related to that in tc39/ecma402#175 (comment) though we may decide to answer it differently if Intl formatters are validating and Intl.Locale is not.

With the patch in Intl.Locale currently as well as tc39/ecma402#175 , the logic for validating options is something like, "if it's from a small, fixed set, check that it is in that set; otherwise, treat it as uninterpreted data and permit any value". I can see how this is inconsistent, especially if hourCycle may get more values in the future.

For that reason, option 2 seems good to me. But, if we go with that, maybe we want to perform similar validation in existing Intl constructors. Or should we continue to omit the validation for compatibility?

Seems like we should discuss this issue in the Intl VC call.

[anba]

I'm not sure if ICU contains an API for this validation

The following functions should probably fit our needs:

• unumsys_openAvailableNames to retrieve all known numbering systems.
• ucol_getKeywordValues to retrieve all known collation types.
• And for the calendar types we probably need to use ucal_getKeywordValuesForLocale with commonlyUsed = false.

Plus uloc_toUnicodeLocaleType to convert the values to BCP 47 Unicode extension types.

[littledan]

We discussed this issue in the Intl meeting, and the group consensus was to validate just the grammar, as @anba's patch ended up doing.

[littledan]

Fixed by #23.