Bug 282504
| Summary: | `new Intl.Locale('und').language` returns `undefined`, not string `'und'` | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | lionel.rowe |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | iKonnyaku40, karlcow, vitor.roriz, webkit-bug-importer, ysuzuki |
| Priority: | P2 | Keywords: | BrowserCompat, InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
lionel.rowe
`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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Yusuke Suzuki
This is ICU issue around "und" support.
lionel.rowe
(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.

Radar WebKit Bug Importer
<rdar://problem/139586863>
Keita Nonaka
In the latest JSC, `new Intl.Locale('und').language` correctly returns "und".
Karl Dubost
Safari TP 125
new Intl.Locale('und').language
undefined
new Intl.Locale('xxx').language
"xxx"
Firefox Nightly 143.0 and Chrome Canary 141.0
new Intl.Locale('und').language
"und"
new Intl.Locale('xxx').language
"xxx"
Karl Dubost
This has been fixed in Bug 295853
*** This bug has been marked as a duplicate of bug 295853 ***