Discuss
  • Globalization API holiday summary

Globalization API holiday summary

# Nebojša Ćirić (14 years ago)

There are couple of threads going on and I wanted to wrap up current state before the holidays...

API:

  1. Use built in toLocaleString family of methods in simple, functional case*
  2. Use Globalization API as proposed (with some tweaks) for complex scenarios**

strawman:globalization-integration ** - globalization:specification_drafts

Proposed changes to the original API:

  1. Remove global namespace Globalization (give an internal name to remove chance of conflicts, i.e. __Globalization).

  2. Use module loading logic instead (we need a way to do a blocking load of built-in library - Object.system.load() is async at the moment) 2a. What happens with toLocaleString methods when user doesn't load @globalization module?

  3. Accept either a String (LDML) or an option Object as a format parameter in formatters. Simplifies the simple use case and loading resources from files. 3a. In addition to DateTimeFormat({year:'long'}) one can DateTimeFormat("yyyy").

  4. Come up with the name of the built-in library - module intl import '@globalization' doesn't sound so terrible to me as one time operation.

  5. Move locale list parameter into the options. I think that clashes with item 3. where options are being replaced with the string in some cases. Keeping locales separate removes the conflict. 5a. Instead of DateTimeFormat(locList, options) have DateTimeFormat(options), where options hold locale info.

Did I miss anything?

# Nebojša Ćirić (14 years ago)

  1. Ability to set global locale list.

  2. децембар 2011. 10.25, Nebojša Ćirić <cira at google.com> је написао/ла:

# Nicholas C. Zakas (14 years ago)

I'm still holding out hope for a Locale object that handles everything. :) Other than that, I think you have covered everything else.

# Rick Waldron (14 years ago)

I also still support a single object API exactly as Nicholas mentioned.

# Mark Davis ☕ (14 years ago)

Mark — Il meglio è l’inimico del bene — * * * [plus.google.com/114199149796022210033] *

On Thu, Dec 8, 2011 at 10:25, Nebojša Ćirić <cira at google.com> wrote:

There are couple of threads going on and I wanted to wrap up current state before the holidays...

API:

  1. Use built in toLocaleString family of methods in simple, functional case*
  2. Use Globalization API as proposed (with some tweaks) for complex scenarios**

strawman:globalization-integration ** - globalization:specification_drafts

Proposed changes to the original API:

  1. Remove global namespace Globalization (give an internal name to remove chance of conflicts, i.e. __Globalization).

+1

  1. Use module loading logic instead (we need a way to do a blocking load of built-in library - Object.system.load() is async at the moment) 2a. What happens with toLocaleString methods when user doesn't load @globalization module?

  2. Accept either a String (LDML) or an option Object as a format parameter in formatters. Simplifies the simple use case and loading resources from files. 3a. In addition to DateTimeFormat({year:'long'}) one can DateTimeFormat("yyyy").

+1

  1. Come up with the name of the built-in library - module intl import '@globalization' doesn't sound so terrible to me as one time operation.

  2. Move locale list parameter into the options. I think that clashes with item 3. where options are being replaced with the string in some cases. Keeping locales separate removes the conflict. 5a. Instead of DateTimeFormat(locList, options) have DateTimeFormat(options), where options hold locale info.

I agree with keeping separate.

# Sam Tobin-Hochstadt (14 years ago)

On Thu, Dec 8, 2011 at 1:25 PM, Nebojša Ćirić <cira at google.com> wrote:

2. Use module loading logic instead (we need a way to do a blocking load of built-in library - Object.system.load() is async at the moment)

Just to clarify, although Dave and I haven't totally nailed down the API for this, we definitely plan for module loaders to support synchronous loading of built-in modules.

# Nebojša Ćirić (14 years ago)

I have a feeling that the main group prefers module approach (Object.system.load('@globalization') kind) over a new global object given the future direction of the standard. Please correct me if I am wrong.

Global Locale approach could be implemented with thin wrapper over our object proposal (very similar to tie in to the built in toLocaleString method). Should we make that wrapper part of the standard or not is a different question (maybe as a v2.0 of the standard?).

I'll start implementing the latest proposal in v8 soon. If anybody has any major issues with the current state please yell.

  1. децембар 2011. 14.51, Nicholas C. Zakas <standards at nczconsulting.com>је написао/ла:
# Nebojša Ćirić (14 years ago)

Item we discussed the least is the global default locale. I would propose __Globalization.localeList property as a way of setting/reading default locale list. For example:

var intl = Object.system.load('@globalization'); intl.localeList = new intl.LocaleList(['sr', 'fr', 'de']);

Date.now().toLocaleString(options);

or

var dtf = new intl.DateTimeFormat(options); dtf.format(new Date());

Both toLocaleString call and DateTimeFormat constructor would use intl.localeList as default locale list with the current value.

There are 3 ways of picking which locale list to use:

  1. DateTimeFormat has a valid localeList parameter. That parameter gets used - globals and defaults are ignored.
  2. DateTimeFormat doesn't have localeList parameter specified: 2a. Use intl.localeList if defined. 2b. Use implementation specific default locale if intl.localeList was not defined.
  3. Ultimate fallback is implementation specific default locale.

What do you think?

  1. децембар 2011. 09.47, Nebojša Ćirić <cira at google.com> је написао/ла:
# Nicholas C. Zakas (14 years ago)

On 12/14/2011 10:17 AM, Nebojša Ćirić wrote:

Item we discussed the least is the global default locale. I would propose __Globalization.localeList property as a way of setting/reading default locale list. For example:

var intl = Object.system.load('@globalization'); intl.localeList = new intl.LocaleList(['sr', 'fr', 'de']);

Date.now().toLocaleString(options);

I think you mean:

 (new Date()).toLocaleString(options);

Date.now() returns a number, not a Date object.

Are you saying that intl.localeList would be initialized prior to being loaded via Object.system.load("@globalization")? And then a developer could override that property to create a new global localList?

FWIW: One issue with using toLocaleString() for formatting is that it already exists, so there isn't a straightforward way to feature detect that it's the new implementation instead of the old implementation.

or

var dtf = new intl.DateTimeFormat(options); dtf.format(new Date());

Both toLocaleString call and DateTimeFormat constructor would use intl.localeList as default locale list with the current value.

There are 3 ways of picking which locale list to use:

  1. DateTimeFormat has a valid localeList parameter. That parameter gets used - globals and defaults are ignored.
  2. DateTimeFormat doesn't have localeList parameter specified: 2a. Use intl.localeList if defined. 2b. Use implementation specific default locale if intl.localeList was not defined.
  3. Ultimate fallback is implementation specific default locale.

What do you think?

Part of the reason I was proposing the change to a single Locale object is because, with a single authority such as this, any script on a page would be capable of overriding the default locale and, therefore, changing the behavior of everything on the page. That seems like a very problematic behavior.

# Norbert Lindenberg (14 years ago)

A few comments below.

Norbert

On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:

There are couple of threads going on and I wanted to wrap up current state before the holidays...

API:

  1. Use built in toLocaleString family of methods in simple, functional case*
  2. Use Globalization API as proposed (with some tweaks) for complex scenarios**

The specification draft of December 1 already includes an improved version of the toLocaleString/localeCompare redefinitions.

Proposed changes to the original API: [snip] 2a. What happens with toLocaleString methods when user doesn't load @globalization module?

I think they should work as specified in the Globalization API spec regardless. You don't want to get different results from these methods depending on whether some component on the page has loaded the module or none has.

  1. Accept either a String (LDML) or an option Object as a format parameter in formatters. Simplifies the simple use case and loading resources from files. 3a. In addition to DateTimeFormat({year:'long'}) one can DateTimeFormat("yyyy").

These are not the same at all. According to the current spec, {year:'long'} is a request "give me a pre-made format with a longish date and no other component if you have such a format; otherwise give me whatever pre-made format you feel fits best, for example one including a year and a month and some decorative characters." If patterns work as in LDML, then {pattern: "yyyy"} means "format the year of the given date into a number with at least four digits" and nothing else.

[snip]

# Norbert Lindenberg (14 years ago)

I can't find a specification for Object.system.load - does it return a reference to a single globally shared object representing the module, or does it return a new object that contains the exported functions/items of the module?

In the first case, I'd assume the object returned is immutable for security reasons, so we can't set its localeList. In the second case, how would the DateTimeFormat constructor find the intl variable that it's attached to?

Norbert

# Luke Hoban (14 years ago)

According to the current API on harmony:module_loaders along with an assumption (not yet decided) that the system loader would be at Object.system, you would want this for the example shown below:

var intl = Object.system.loaded['@globalization'] intl.setLocaleList(new intl.LocaleList(['sr', 'fr', 'de']));

Dave Herman suggested that both the "Object.system" part and the "loaded" part were likely to change in an upcoming update of the module_loaders proposal.

With the default module loader, I believe the plan is for the intl object to be the single shared module instance object for the globalization module. You are right that the module instance object has only getter properties, so you would need to call a function like setLocaleList to set it's locale.

For the second case - the DateTimeFormat object should be able to capture a reference to state associated with its defining module.

Luke

# Allen Wirfs-Brock (14 years ago)

On Jan 16, 2012, at 7:45 PM, Norbert Lindenberg wrote:

On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:

Proposed changes to the original API: [snip] 2a. What happens with toLocaleString methods when user doesn't load @globalization module?

I think they should work as specified in the Globalization API spec regardless. You don't want to get different results from these methods depending on whether some component on the page has loaded the module or none has.

What about backwards compatibility? Some pages may be doing browser sniffing to customize themselves for the current implementation dependent behavior of toLocaleString and friends. For this reason, continuing to specify the behavior as implementation defined in the absence of loading the @globalization module may be a reasonable alternative