Globalization API holiday summary

Luke Hoban lukeh at
Mon Jan 16 22:16:29 PST 2012

According to the current API on 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.


-----Original Message-----
From: es-discuss-bounces at [mailto:es-discuss-bounces at] On Behalf Of Norbert Lindenberg
Sent: Monday, January 16, 2012 7:59 PM
To: Nebojša Ćirić; David Herman; Sam Tobin-Hochstadt
Cc: es-discuss at
Subject: Re: Globalization API holiday summary

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?


On Dec 14, 2011, at 10:17 , 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']);
> 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?

es-discuss mailing list
es-discuss at

More information about the es-discuss mailing list