Globalization API holiday summary

Nebojša Ćirić cira at google.com
Wed Dec 14 09:47:49 PST 2011


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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111214/e0c5c0c5/attachment.html>


More information about the es-discuss mailing list