no validation of value of extensions in tag? about proposal-intl-locale

[anba]

The correct results are:

js> addIntlExtras(Intl) // Add Intl.Locale to Intl in SpiderMonkey shell
js> (new Intl.Locale("en-u-kf-true")).caseFirst
""
js> (new Intl.Locale("en-u-kf-mom")).caseFirst  
"mom"

The caseFirst result for "en-u-kf-true" is the empty string, because the tag is first canonicalised to "en-u-kf" per BCP 47 Language Tag to Unicode BCP 47 Locale Identifier and 3.2.1 Canonical Unicode Locale Identifiers which states:

Any type or tfield value "true" is removed.

[zbraniecki]

I think this is a reasonable behavior tbh.

We verify that the input language identifier string is well formed while we verify that the options are valid.

We're consistent in that behavior.

Long time ago we talked about an option to validate the input string as well, but that never came to fruition.

[FrankYFTang]

then
What should the expected result of
(new Intl.Locale("en-u-kf-true")).caseFirst and
(new Intl.Locale("en-u-kf-mom")).caseFirst ?

[zbraniecki]

(new Intl.Locale("en-u-kf-true")).caseFirst

undefined

(new Intl.Locale("en-u-kf-mom")).caseFirst

undefined

I'm not opposed to liberating options to be well-formed only, in which case we'd also accept caseFirst = "mom" and just not apply it since it's not valid.
That would be forward compatible, but I'm not sure if consistency is more important than feedback to users.

The reason why I think the current subset makes sense (until we complete it) is that options come from developers, so throwing on well-formed, but invalid value makes sense.
langid strings come from some external sources, browser, system etc. If they contain errors, rejecting them should be last resort, because user can rarely do anything about it, and the dev usually cannot do anything.

[FrankYFTang]

(new Intl.Locale("en-u-kf-true")).caseFirst

undefined

(new Intl.Locale("en-u-kf-mom")).caseFirst

undefined

Why, according to the current spec, the result is not "true" and "mom" ? That is the part I try to understand.

I'm not opposed to liberating options to be well-formed only, in which case we'd also accept caseFirst = "mom" and just not apply it since it's not valid.

I am not lobbying for that. Just try to figure out what the current spec said.

That would be forward compatible, but I'm not sure if consistency is more important than feedback to users.

The reason why I think the current subset makes sense (until we complete it) is that options come from developers, so throwing on well-formed, but invalid value makes sense.
langid strings come from some external sources, browser, system etc. If they contain errors, rejecting them should be last resort, because user can rarely do anything about it, and the dev usually cannot do anything.

[littledan]

We last discussed this topic in #19 . There, we decided to validate simply the grammar, and not the contents, in these contexts. Applying that decision here, I think we should return "mom" and "true", as the current specification does, while continuing to be more strict in the options bag. (EDIT: @anba has the correct answers below)

[zbraniecki]

Based on my read of the current spec and @anba's description, it seems like the current spec is correct and the behavior is as expected.

Is it ok for me to close this issue?

[zbraniecki]

reopen if needed!