Internationalization: Strings as locales argument

Phillips, Addison addison at
Mon Jul 16 08:41:40 PDT 2012

The empty string isn't a valid BCP 47 language tag, but it is a valid value for xml:lang and HTML @lang. So my main concern would be to make the "pass through" somewhat seamless. That is, I'm more concerned with that becoming an error condition than I am concerned with what happens with that value. 

I agree that the empty value isn't very useful in determining what to do. For what it's worth, I supported a language-independent "root" locale, although there is scant difference between the empty string and using the "und" tag. I tend, personally, to favor the empty string over "und", because the "und" tag makes it look like there is data there (harder to special case). But the problem remains of what behavior to assign to the "no locale available" case and whether that should be normative or implementation defined.


> -----Original Message-----
> From: Norbert Lindenberg [mailto:ecmascript at]
> Sent: Sunday, July 15, 2012 9:54 PM
> To: Phillips, Addison
> Cc: Norbert Lindenberg; es-discuss
> Subject: Re: Internationalization: Strings as locales argument
> 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]
> [2]
> 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