Internationalization: Strings as locales argument

Norbert Lindenberg ecmascript at norbertlindenberg.com
Sun Jul 15 21:53:44 PDT 2012


Empty strings are not valid BSP 47 language tags and would not qualify with or without my proposed change. Without the change, they'd be interpreted as an empty list, so the constructors would eventually fall back to the default locale, while supportedLocalesOf would return an empty array.

UTS 35, section 3.2.2, specifies that the Unicode locale identifier "root" is mapped to the BCP 47 language tag "und". I once proposed that our API should require support for a language-independent locale (to the extent that that's possible); that proposal didn't find approval.

In XML and HTML, an empty language tag means "no language information available" or  "primary language is unknown" [1, 2]. If within such content language sensitive operations are necessary, someone has to decide which language to assume. Should that be the Internationalization API? Maybe an application would find "und" more appropriate in this situation than the default locale?

Norbert

[1] http://www.w3.org/TR/2008/REC-xml-20081126/#sec-lang-tag
[2] http://dev.w3.org/html5/spec/global-attributes.html#the-lang-and-xml:lang-attributes


On Jul 14, 2012, at 13:49 , Phillips, Addison wrote:

>> 
>> The result would be that "" is rejected with a RangeError, but "en-US" is
>> processed as ["en-US"].
>> 
> 
> Would there be some means of referencing the "root" locale other than using the empty string?
> 
> Also, one means of assigning a locale would be to scrape one or another @lang attribute in some HTML or XML content. If that attribute were empty, would RangeError be an expected outcome? Wouldn't it be better to handle the empty string gracefully, since it isn't necessarily an error condition?
> 
> Addison



More information about the es-discuss mailing list