Globalization API holiday summary

Nebojša Ćirić cira at google.com
Wed Dec 14 10:17:20 PST 2011


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);

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?

14. децембар 2011. 09.47, Nebojša Ćirić <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>је написао/ла:
>
>  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> је написао/ла:
>>
>>> 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ć
>



-- 
Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111214/f44b59a5/attachment.html>


More information about the es-discuss mailing list