Intl: platform.normalizeLanguageTag does not correctly handle valueless unicode extensions

[jackhorton]

The result of calling CanonicalizeLanguageTag on "en-us-u-kn" should be "en-US-u-kn", not "en-US-u-kn-true" as is currently returned from platform.normalizeLanguageTag. This causes test262 9.2.5_11_g_ii_2 to fail.

[dilijev]

As of master:

## Source
print(Intl.getCanonicalLocales('en-us-u-kn'))

┌────┬─────────────────┐
│ d8 │ en-US-u-kn-true │
├────┼─────────────────┤
│ ch │ en-US-u-kn      │
│ sm │                 │
└────┴─────────────────┘

(jsc apparently doesn't have an Intl object)

[dilijev]

@jackhorton I didn't see the test you referenced in test262 at either of the following commits:

# my old master
[ 9376782c6 ] 2017-09-07 15:09 leonardo.. Regenerate tests
# latest
[ 515539737 ] 2017-12-21 16:46 waldron... Add missing features

I'm assuming that the test was referring to the section now known as #sec-resolvelocale https://tc39.github.io/ecma402/#sec-resolvelocale (which is not (?) referenced in https://tc39.github.io/ecma402/#sec-canonicalizelanguagetag) -- but there don't seem to be any tests which reference sec-canonicalizelanguagetag or sec-resolvelocale

[jackhorton]

Interesting, yeah I need to update my test262 clone -- I honestly completely forgot about that.

[dilijev]

Test is now located at test\intl402\Collator\missing-unicode-ext-value-defaults-to-true.js

[jackhorton]

Our behavior as of #4645 is similar to V8, but still incorrect compared to WinGlob and SpiderMonkey. Thoughts on if this requires more work?

[dilijev]

IMO if ( v8 behavior != one of [ spec | consensus ] ) we should either target spec behavior or push to update spec.

[jackhorton]

There was discussion today with respect to Intl.Locale to normalize extensions according to RFC 6067. I need to look over the spec again but otherwise I am not sure exactly what is defined and what is implementation-specific here.

@zbraniecki Do you know anything about this test/what is expected here?