Dealing with key-values & options, and duplicates about proposal-intl-locale

[littledan]

@zbraniecki Oh thanks for explaining, my mistake. Agree that baseName sounds better then.

[zbraniecki]

What do we do with -t- section? There is only value, no key (as in it-t-ja)
What happens with -x- key-values? Esp. if they match names in -u-?

The way we decided to approach it is that we will preserve the -t- and -x- but you can't retrieve or set them via the options.

So:

let loc = new Intl.Locale("sr-Cyrl-u-hc-h24-x-foo", {
  calendar: "gregory"
});
loc.calendar; // "gregory"
loc.locale; // "sr-Cyrl"
loc.hourCycle; // "h24"
loc.toString(); // "sr-Cyrl-u-ca-gregory-hc-h24-x-foo"

Wrt. the second:

let loc = new Intl.Locale("sr-u-ca-buddhist", {
  calendar: 'gregory'
});
console.log(loc.locale); // "sr"
console.log(loc.calendar); // "gregory" - options override lang tag
console.log(loc.toString()); // "sr-u-ca-gregory"

Does it seem reasonable to you?

[zbraniecki]

Hmm, also, IIRC we don't have a locale getter. We have language, script, region.

I'm not sure if Locale.prototype.locale makes sense as a name, especially if it strips extension keys, but I understand the value of a getter that returns just language/script/region/variants without extension keys. That would be a new addition to the spec tho.

[nciric]

@zbraniecki I am somewhat confused then.

Is loc.locale just a language tag then (sr, no script or region)? Or is loc.locale equivalent of getBaseName in ICU (language, script and region)?

I see it represents both in your example.

To clarify:

let loc = new Intl.Locale('sr-Cyrl-RS-u-hc-h24');
loc.locale; // sr-Cyrl-RS or sr?
loc.region; // RS or does this getter exist?

[zbraniecki]

@nciric - my examples above are just filled-in copies of your examples.

In the proposal, we have a field language which is sr, and we do not have a field locale.

[nciric]

@zbraniecki I actually copied them from main proposal page, where locale exists. Maybe we need to fix that:

let loc = new Intl.Locale("pl-u-hc-h12", {
  calendar: 'gregory'
});
console.log(loc.locale); // "pl"
console.log(loc.hourCycle); // "h12"
console.log(loc.calendar); // "gregory"
console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"

But, ok, locale is actually toString in our case. For v2 we may need baseName property, which is locale without extensions.

[zbraniecki]

I actually copied them from main proposal page, where locale exists. Maybe we need to fix that:

Definitely! It should be language :)

For v2 we may need baseName property, which is locale without extensions.

+1

[littledan]

The lack of a locale getter (which would omit extension keys) is an accidental omission. I was picturing that we would have it, and presented slide decks to the committee including it. The name locale rather than baseName might be better because it is parallel to resolvedOptions, which is a general design goal here. I'm thinking we should make a patch for this now.

For transforms, I share @zbraniecki's understanding in #22 (comment) . Do you have any concerns about whether the specification text does this?

[littledan]

Apologies, much of the logic here was in a PR that I forgot to merge until now. #21

[nciric]

@littledan locale sounds fine. It would be defined as base name of input locale, without extensions, after canonicalization.

[zbraniecki]

I think I prefer Locale.baseName over Locale.locale because that means that locale term has two meanings - as a class/API it contains extensions, and as a property/getter it specifically means the Locale without extensions.

[littledan]

@zbraniecki What do you think about the usage of locale in resolvedOptions which we will not be able to change?

[zbraniecki]

@littledan locale in ResolvedOptions is exactly the same as Locale.prototype.toString():

(new Intl.DateTimeFormat("en-US-u-ca-gregory")).resolvedOptions().locale; // "en-US-u-ca-gregory

What @nciric suggested is (new Locale("en-US-u-ca-gregory")).locale; // "en-US" I believe which would be inconsistent