Should _ be supported (equivalent to -)

[littledan]

The current spec parses on -, supporting en-US but not en_US. This matches RFC 5646, but not the extensions included by UTS 35. I'm pretty sure we should always normalize to -, but should we parse _ or throw some sort of error?

[zbraniecki]

I'd vote yes. Let's stay lenient in what we accept and strict in what we return.

[littledan]

@caridy raised the question in the Novemer 2017 TC39 meeting: If we permit _ in locales for Intl.Locale, should we permit it in other places where a locale string is needed as well? Currently, I believe _ is prohibited everywhere (including in this proposal).

[caridy]

My argument is mostly about consistency, and specially with https://tc39.github.io/ecma402/#sec-intl.getcanonicallocales, which does not accept _ as part of the canonicalization process of the provided locales.

[zbraniecki]

I don't have a strong opinion, but my gut feeling is that we should be lenient in what we accept, so would be happy to take _, at least for Intl.Locale and Intl.getCanonicalLocales, but possibly for all.

[littledan]

We discussed this at the January ECMA 402 VC meeting. The strong consensus was to disallow this format, since it is not permitted in the actual BCP 47 format.