Should _ be supported (equivalent to -) about proposal-intl-locale

[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.