Decide on behavior for Intl.Locale if the locale is unsupported about proposal-intl-locale

[zbraniecki]

My perspective is that Intl.Locale is a view of the language tag and is meant to facilitate operations on the tags.
It has, in result, no reason to depend on available data.

My perspective is that all it wraps is a set of algorithms to parse any BCP47 language tag, modify it and serialize it into its canonical form.
The datasets available for each Intl formatter are identified using the supportedLocalesOf method on them, and have no correlation with this API.

[littledan]

Related question #8--should we validate sub-components of locales? We probably shouldn't throw an exception on missing data for a region that exists when we can fall back to the parent locale, but there are other cases that are less clear-cut.

[zbraniecki]

What do you mean by validate? Validate if it's a BCP47 compliant? We do this. Validate that Intl has data for it? That's what Intl.*.supportedLocalesOf is for, no?
What do you mean fallback on the parent locale?

[littledan]

Well, I'm using your word from #8. There are a few different levels we could do this at--whether we have the data on the system, whether it's in a list of known existing regions/scripts, or syntactically valid, as you say.

It'd be good to hear more on this bug from people who are more in favor of throwing exceptions on unknown locales/locale components. For my part, I have to investigate what other libraries do; I think I'll have time for this in a month or so.

[zbraniecki]

Well, I'm using your word from #8.

In #8 I only meant BCP47 canonicalization.

whether we have the data on the system, whether it's in a list of known existing regions/scripts, or syntactically valid, as you say.

I really struggle to understand why do you want to connect to it CLDR data carried by the browser. This is a glorified canonicalizeLanguageTag that allows to operate on language tags.

It's not connected to any particular formatter or its data.

known regions/scripts would basically make it useless for operations on correct language tags for which the browser doesn't carry data. Why would you want it?
Once again, if the goal is to verify if the data is there, supportedLocalesOf is the API for it.

[littledan]

In #8 I only meant BCP47 canonicalization.

I see, I didn't realize.

I really struggle to understand why do you want to connect to it CLDR data carried by the browser.

I don't really want to; I'm trying to represent the points of view expressed in the committee. We'd better find others who want to represent that point of view. cc @bterlson .

[littledan]

I checked several other programming languages' standard libraries for their behavior on unsupported locales. Generally, unsupported locales can be constructed; using them sometimes falls back to a default and sometimes causes an error. I think we should support constructing locale objects which lack data, but if we add more operations, e.g., to get display names, then consider throwing errors on missing data rather than return data for the wrong locale.

[zbraniecki]

There are multiple levels of conformance [0].

"well-formed" is any tag that follows the ABNF. "valid" is any tag that follows ABNF and contains tag registered in the IANA (or grandfathered).

My recommendation is for Intl.Locale to support "well-formed" tags and not support grandfathered at all.
We can consider later adding isValid test.

[0] https://tools.ietf.org/html/bcp47#section-2.2.9

[littledan]

The current proposal doesn't support grandfathered locales, but it does support locales with no data.

[littledan]

OK, it seems like the current specification is acceptable, so closing this issue. Please reopen if you have any more concerns.

[littledan]

We reviewed this discussion at the January ECMA 402 VC meeting. The consensus was to continue accepting unsupported locales, given the independent utility in just parsing and processing a locale.