Bug 282504 – `new Intl.Locale('und').language` returns `undefined`, not string `'und'`

• Status: NEW
• Component: JavaScriptCore

`new Intl.Locale('und').language` (and other locales with a `language` of `und`) return `undefined`, rather than the expected string `'und'`. This behavior diverges from the ECMA-402 spec.

Repro:

```js
new Intl.Locale('xxx').language // 'xxx' (correct result)
new Intl.Locale('und').language // undefined (expected 'und')
```

Per ECMA-402 spec:

https://tc39.es/ecma402/#sec-Intl.Locale.prototype.language

> 3. Return GetLocaleLanguage(loc.[[Locale]]).

https://tc39.es/ecma402/#sec-getlocalelanguage

> 1. Let baseName be GetLocaleBaseName(locale).
> 2. Assert: The first subtag of baseName can be matched by the unicode_language_subtag Unicode locale nonterminal.
> 3. Return the first subtag of baseName.

Other browsers/engines:

* Chromium/V8 suffers from the same issue, presumably with a similar cause: https://issues.chromium.org/issues/334251989
* Firefox has the correct behavior

I guess the offending code path is this one? https://github.com/WebKit/WebKit/blob/635a079e5128f24a69f90de3141943153e46e5bb/Source/JavaScriptCore/runtime/IntlLocale.cpp#L489-L494

[Yusuke Suzuki]

This is ICU issue around "und" support.

(In reply to Yusuke Suzuki from comment #1)
> This is ICU issue around "und" support.

Apologies for ignorance, this is my first bug report here. Do you mean it's an issue in ICU itself? Or it's relating to a preexisting issue against WebKit's ICU implementation? Or something else?

I don't think it can be an issue in ICU itself, as ICU doesn't specify how implementations should _represent_ the various semantics (i.e. there's nothing in ICU that says an "und" locale shouldn't be represented as having a nullish "language" field). The problem is rather that ECMA-402 specifies that `GetLocaleLanguage` should return the language subtag unchanged.

From a userland perspective, I first encountered this bug by creating `new Intl.Locale('und')` and noticing that its `language` was `undefined`, then noting that the TypeScript types appeared to be wrong. But upon checking the spec, I realized it was the implementation that was wrong, not the TS types.

![TypeScript logo superimposed over Seymour Skinner's face: "Am I out of ~~touch~~ spec?" "No, it's the ~~children~~ implementations who are wrong!"](skinner.jpg)

[Radar WebKit Bug Importer]

<rdar://problem/139586863>