Don't conflict with locale keywords

[sffc]

UTS 35 defines a number of locale keyword extensions that aren't yet in 402. We should design an API that cannot conflict with them. For example:

+ get Intl.Locale.prototype.measurementSystem

That would conflict with the -u-ms- extension.

In general, of the properties you are adding, some of them are supported by locale keywords, and some are not. These settings are supported by locale keywords:

• get Intl.Locale.prototype.firstDayOfWeek (-u-fw-)
• get Intl.Locale.prototype.defaultHourCycle (-u-hc-)
• get Intl.Locale.prototype.measurementSystem (-u-ms-)
• get Intl.Locale.prototype.defaultCalendar (-u-ca-)

The following are not currently supported by locale keywords. However, all of them except maybe "direction" could potentially be supported in a future version of UTS 35:

• get Intl.Locale.prototype.minimalDaysInFirstWeek
• get Intl.Locale.prototype.weekendStart
• get Intl.Locale.prototype.weekendEnd
• get Intl.Locale.prototype.direction
• get Intl.Locale.prototype.commonCalendars

[sffc]

I've previously suggested using the "likely" prefix. For example:

get Intl.Locale.prototype.likelyHourCycle

The implementation would first return the explicit -u-hc- if present, and if it's not present, then it would load the default from data.

The term "likely" is consistent with "likely subtags" and emphasizes that the returned hour cycle is not necessarily the correct choice for the user; it is merely a best attempt based on the locale and CLDR data.

[FrankYFTang]

I've previously suggested using the "likely" prefix. For example:

get Intl.Locale.prototype.likelyHourCycle

The implementation would first return the explicit -u-hc- if present, and if it's not present, then it would load the default from data.

The term "likely" is consistent with "likely subtags" and emphasizes that the returned hour cycle is not necessarily the correct choice for the user; it is merely a best attempt based on the locale and CLDR data.

I change the model so for this case it will be

let locale = new Intl.Locale("ja")
locale.defaults.hourCycle

[sffc]

What happens if you write

let locale = new Intl.Locale("ja-u-hc-h11")
locale.defaults.hourCycle

Do you get "h11" or do you get whatever the CLDR data says for ja?

[FrankYFTang]

I believe in that case it should be "h11" because that is the default hc for that locale ("ja-u-hc-h11")

On Wed, 2 Dec 2020 at 15:10, Shane F. Carr notifications@github.com wrote:

What happens if you write

let locale = new Intl.Locale("ja-u-hc-h11") locale.defaults.hourCycle

Do you get "h11" or do you get whatever the CLDR data says for ja?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-intl-locale-info/issues/2#issuecomment-737551093, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2N2KKZPVI3T2T5GLET2SDSS3CNXANCNFSM4RWS3AZQ .

-- Frank Yung-Fong Tang 譚永鋒 / 🌭🍊 Sr. Software Engineer

[FrankYFTang]

I have hard time to justify the need for adding defaults to this proposal

1. the hourCycle information can be found by (new Intl.DateTimeFormat("fa", {hour: "numeric"}).resolvedOptions().hourCycle
2. I cannot find any user request for returning the list of commonly used calendar, collations and calendars Therefore I think we should drop the support of defaults from this proposal

[sffc]

I think adding defaults is the most important part of this proposal.

You can get the default hour cycle or calendar from resolvedOptions of Intl.DateTimeFormat, but it's non-obvious and slow.

[FrankYFTang]

I think adding defaults is the most important part of this proposal.

What OTHER defaults do you have in mind? Do you have a good use case for those?

You can get the default hour cycle or calendar from resolvedOptions of Intl.DateTimeFormat, but it's non-obvious and slow.

I do not believe there are FASTER way to do that actually. I actually prototyped in v8 and remove them.

[sffc]

• Default calendar is useful for plugging into Temporal
• Default hour cycle is useful for apps that could allow users to switch their hour cycle preference

As far as the other extension keywords like numbering system and collation style, those are probably less useful, but I can help make the argument that they don't increase the complexity or data size burden of ECMA-402, in which case we don't need to present as compelling of a case against the three points.

[FrankYFTang]

But all these are already exposed and in the name of not increase API surface and Difficult to implement in User Land, they are all not needed...

let locale = new Intl.Locale('fa')

Default calendar is useful for plugging into Temporal

(new Intl.DateTimeFormat(locale)).resolvedOptions().calendar
"persian"

Default hour cycle is useful for apps that could allow users to switch their hour cycle preference

(new Intl.DateTimeFormat(locale, {hour:"numeric"})).resolvedOptions().hourCycle)
"h23

As far as the other extension keywords like numbering system

(new Intl.NumberFormat(locale)).resolvedOptions().numberingSystem
"arabext"
(new Intl.NumberFormat("ar-SA")).resolvedOptions().numberingSystem
"arab"

and collation style,

(new Intl.Collator("zh")).resolvedOptions().collation
"pinyin"
(new Intl.Collator("ar-SA-u-co-compat")).resolvedOptions().collation
"compat"

[FrankYFTang]

You basically can polypill it easily

Intl.Locale.prototype.prefs = function() {
  return {
       calendar: (new Intl.DateTimeFormat(this)).resolvedOptions().calendar,
       hourCycle: (new Intl.DateTimeFormat(this, {hour:"numeric"})).resolvedOptions().hourCycle,
       numberingSystem: (new Intl.NumberFormat(this)).resolvedOptions().numberingSystem,   
       collation: (new Intl.Collator(this)).resolvedOptions().collation,   
  }
}

fa = new Intl.Locale("fa")
fa.prefs()
// {calendar: "persian", hourCycle: "h23", numberingSystem: "arabext", collation: "default"}
arSA = new Intl.Locale("ar-SA")
arSA.prefs()
// {calendar: "islamic-umalqura", hourCycle: "h12", numberingSystem: "arab", collation: "default"}

[FrankYFTang]

so I do not think this would pass the "Expensive to Implement in User Land"

[sffc]

See my response on "Expensive to Implement in User Land" in https://github.com/tc39/proposal-intl-locale-info/issues/8#issuecomment-797710528

[FrankYFTang]

How about this, add back the spec of prefs which have calendar, hourCycle, numberingSystem, and collation and propose to advance to Stage 3, we discuss this in april 8 ECMA402 meeting. If we reach agreement, we move forward with that, if not, we take it out and move forward without it.

[FrankYFTang]

no conflict now, closeit.