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** * - http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration ** - http://wiki.ecmascript.org/doku.php?id=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ć
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
