Globalization API holiday summary

Nebojša Ćirić cira at
Thu Dec 8 10:25:35 PST 2011

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

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

* -
** -

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
  3a. In addition to DateTimeFormat({year:'long'}) one can

 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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list