I would like to expose other user settings. Can this proposal accomodate me? about proposal-intl-locale

[zbraniecki]

There are two extension keys that can contain this data.

• rg is for regional override. It allows you to say en-US-u-rg-gbzzzz which means en-US with regional settings for GB
• ms is for measuring system. You can switch between metric, ussystem and uksystem

I would like to see us adding both of them in ECMA402 APIs.

[zbraniecki]

I'm not sure how overlapping it will end up being, but I do have a proposal for DateTimeFormat and NumberFormat to allow for looking into OS regional settings to retrieve custom formatting information.

That would address your use case where you specify a custom date or time format (or number format).
I already implemented it locally in Gecko as a thin wrapper on top of Intl API [0]

This information cannot be easily conveyed by extension keys and options, but I believe we can work toward extending ECMA402 APIs to allow systems to do that.

But for Intl.Locale API I believe that respecting rg and ms extension keys would give us a good start.

[0] http://searchfox.org/mozilla-central/rev/2c9a5993ac40ec1db8450e3e0a85702fa291b9e2/toolkit/components/mozintl/mozIntl.js#91

[domenic]

Could you give me at least a vague sketch of how you eventually see people accessing e.g. the user's DateTimeFormat? Would it be navigator.locales[0].dateTimeFormat, or would it be some new top-level entrypoint?

[littledan]

When @jungshik and I discussed Into user settings, it seemed like it would be better to separate out an API for reading default settings from the core Intl APIs. This would be a disadvantage the second proposal that you list. I wonder how much more we can support the first way. It doesn't sound like it could explain everything, though.

Another option could be to allow Locale objects to have further internal slots which describe further OS settings. These would be lost by toString, and not directly readable, but interpreted by Intl constructors.

[zbraniecki]

Sure,

let dtf = new Intl.DateTimeFormat(navigator.locales, {
  dateStyle: "short",
  useOSRegionalPrefs: true
});
dtf.format(now);

[littledan]

Is there even an agreed-on format for the DateTimeFormat pattern? LDML/CLDR has a format, but we have been avoiding exposing it so far because Windows uses a different format.

[zbraniecki]

Is there even an agreed-on format for the DateTimeFormat pattern?

During the conversation about it the majority of opinions were that we should not expose patterns, but either styles (like I did in the example) or at most skeletons.

See tc39/ecma402#109 and tc39/ecma402#108 for details.

[littledan]

If we logically represent OS preferences in an internal slot of the locale, and then have an option in the bag to use that, then this example would work too. We would throw an exception if used on another locale without that internal slot.

[zbraniecki]

If we logically represent OS preferences in an internal slot of the locale, and then have an option in the bag to use that, then this example would work too. We would throw an exception if used on another locale without that internal slot.

Well, yes, but we'd need to store pattern for dateShort, dateMedium, dateLong, dateFull, timeShort, timeMedium, timeLong, timeFull, dateTimeShort, dateTimeMedium, dateTimeLong, dateTimeFull... and I didn't even get to custom patterns for numbers.

Trying to squeeze custom patterns into locale string via extension keys is imho not going to fly.

[domenic]

In #3 (comment), what effect does passing navigator.locales have? I would assume it's entirely determined by useOSRegionalPrefs: true...

[zbraniecki]

I would assume it's entirely determined by useOSRegionalPrefs: true...

No, useOSRegionalPrefs only allows us to look into OS prefs for custom date/time patterns and is a separate proposal.

navigator.locales provides information about region, hourCycle, firstDayOfWeek, measuring system etc. preferred by the user.

Those bits are not only useful across all Intl APIs but also will be used by higher level APIs.
The custom date/time (and maybe number) patterns is just another step and a separate proposal not covered by UTS35, Unicode and other intl standards.

[domenic]

So what would be the difference between the results in your code if navigator.locales was en-US vs. zh-CN or similar? Assume both people have configured their computer to use Gregorian calendar, YYYY-MM-DD HH:mm:ss format, first day of week as Monday. I don't see how the locale matters in this scenario.

[zbraniecki]

I don't see how the locale matters in this scenario.

The differences may not be observable. But if they would define a format with name of the week, or month, we'd have to use the right translation, among other things.

Locale comes with a lot of defaults. You can override some of them with extension keys. Developer can ovcerride some of them with options.
The custom formats is, as I said, a separate proposal that would be only limited to customized date/time/number patterns (vs. default patterns for the given locale, which we'll use if we cant retrieve a customized pattern from the OS)

[zbraniecki]

Also, if you'll work between ar and en-US, we'll transliterate numbers to the right calendar, which we'll pick according to the locale, unless you specify a different one in extension keys :)

[littledan]

I'm not talking about actually exposing properties on the object, or even necessarily having implementations look up information ahead of time. What would be important is just that you'd need to use something from navigator.locales to be allowed to use the options to get the OS defaults.

[littledan]

Now that using the Intl constructor is based on using internal slots, rather than .toString(), I think we can safely say that this proposal will be extensible to other options that don't serialize to a BCP47 tag, if embedding environments decide to expose such options and we thread them through to formatters.