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. 09. децембар 2011. 14.51, Nicholas C. Zakas <[email protected]>је написао/ла: > I'm still holding out hope for a Locale object that handles everything. > :) Other than that, I think you have covered everything else. > > -N > > > On 12/8/2011 12:55 PM, Nebojša Ćirić wrote: > > 6. Ability to set global locale list. > > 08. децембар 2011. 10.25, Nebojša Ćirić <[email protected]> је написао/ла: > >> 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ć >> > > > > -- > Nebojša Ćirić > > > > -- > ___________________________ > Nicholas C. Zakashttp://www.nczonline.net > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
