Globalization API holiday summary

Nicholas C. Zakas standards at nczconsulting.com
Wed Dec 14 13:15:31 PST 2011


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.

-N
>
> 14. децембар 2011. 09.47, Nebojša Ćirić <cira at google.com 
> <mailto:cira at google.com>> је написао/ла:
>
>     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
>     <standards at nczconsulting.com <mailto:standards at nczconsulting.com>>
>     је написао/ла:
>
>         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ć <cira at google.com
>>         <mailto:cira at google.com>> је написао/ла:
>>
>>             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. Zakas
>         http://www.nczonline.net
>
>
>
>
>     -- 
>     Nebojša Ćirić
>
>
>
>
> -- 
> Nebojša Ćirić


-- 
___________________________
Nicholas C. Zakas
http://www.nczonline.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111214/2d7442d6/attachment.html>


More information about the es-discuss mailing list