Re: Globalization API holiday summary

[Allen Wirfs-Brock]

On Jan 16, 2012, at 7:45 PM, Norbert Lindenberg wrote:
> 
> On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:
> 
>> Proposed changes to the original API:
> [snip]
>>  2a. What happens with toLocaleString methods when user doesn't load 
>> @globalization module?
> 
> I think they should work as specified in the Globalization API spec 
> regardless. You don't want to get different results from these methods 
> depending on whether some component on the page has loaded the module or none 
> has.

What about backwards compatibility?  Some pages may be doing browser sniffing 
to customize themselves for the current implementation dependent behavior of 
toLocaleString and friends.  For this reason, continuing to specify the 
behavior as implementation defined in the absence of loading the @globalization 
module may be a reasonable alternative

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Globalization API holiday summary

[Luke Hoban]

According to the current API on 
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders along with an 
assumption (not yet decided) that the system loader would be at Object.system, 
you would want this for the example shown below:

  var intl = Object.system.loaded['@globalization']
  intl.setLocaleList(new intl.LocaleList(['sr', 'fr', 'de']));

Dave Herman suggested that both the "Object.system" part and the "loaded" part 
were likely to change in an upcoming update of the module_loaders proposal.

With the default module loader, I believe the plan is for the intl object to be 
the single shared module instance object for the globalization module.  You are 
right that the module instance object has only getter properties, so you would 
need to call a function like setLocaleList to set it's locale.  

For the second case - the DateTimeFormat object should be able to capture a 
reference to state associated with its defining module.

Luke

-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On 
Behalf Of Norbert Lindenberg
Sent: Monday, January 16, 2012 7:59 PM
To: Nebojša Ćirić; David Herman; Sam Tobin-Hochstadt
Cc: es-discuss@mozilla.org
Subject: Re: Globalization API holiday summary

I can't find a specification for Object.system.load - does it return a 
reference to a single globally shared object representing the module, or does 
it return a new object that contains the exported functions/items of the module?

In the first case, I'd assume the object returned is immutable for security 
reasons, so we can't set its localeList. In the second case, how would the 
DateTimeFormat constructor find the intl variable that it's attached to?

Norbert


On Dec 14, 2011, at 10:17 , 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);
> 
> 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?
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Norbert Lindenberg]

I can't find a specification for Object.system.load - does it return a 
reference to a single globally shared object representing the module, or does 
it return a new object that contains the exported functions/items of the module?

In the first case, I'd assume the object returned is immutable for security 
reasons, so we can't set its localeList. In the second case, how would the 
DateTimeFormat constructor find the intl variable that it's attached to?

Norbert


On Dec 14, 2011, at 10:17 , 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);
> 
> 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?
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Norbert Lindenberg]

A few comments below.

Norbert


On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:

> 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

The specification draft of December 1 already includes an improved version of 
the toLocaleString/localeCompare redefinitions.

> Proposed changes to the original API:
[snip]
>   2a. What happens with toLocaleString methods when user doesn't load 
> @globalization module?

I think they should work as specified in the Globalization API spec regardless. 
You don't want to get different results from these methods depending on whether 
some component on the page has loaded the module or none has.

>  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("").

These are not the same at all. According to the current spec, {year:'long'} is 
a request "give me a pre-made format with a longish date and no other component 
if you have such a format; otherwise give me whatever pre-made format you feel 
fits best, for example one including a year and a month and some decorative 
characters." If patterns work as in LDML, then {pattern: ""} means "format 
the year of the given date into a number with at least four digits" and nothing 
else.

[snip]

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Nicholas C. Zakas]

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ć > је написао/ла:


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
mailto:standa...@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ć mailto:c...@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("").

 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.

D

Re: Globalization API holiday summary

[Nebojša Ćirić]

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ć  је написао/ла:

> 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 је 
> написао/ла:
>
>  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ć  је написао/ла:
>>
>>> 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("").
>>>
>>>   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ć
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Nebojša Ćirić]

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
је написао/ла:

>  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ć  је написао/ла:
>
>> 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("").
>>
>>   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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Sam Tobin-Hochstadt]

On Thu, Dec 8, 2011 at 1:25 PM, Nebojša Ćirić  wrote:
>
>  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)

Just to clarify, although Dave and I haven't totally nailed down the
API for this, we definitely plan for module loaders to support
synchronous loading of built-in modules.
-- 
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Mark Davis ☕]

Mark
*— Il meglio è l’inimico del bene —*
*
*
*
[https://plus.google.com/114199149796022210033]
*



On Thu, Dec 8, 2011 at 10:25, Nebojša Ćirić  wrote:

> 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).
>
+1

>
>  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("").
>
+1

>
>  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.
>
I agree with keeping separate.

>
> Did I miss anything?
>

> 6. Ability to set global locale list.


>
> --
> Nebojša Ćirić
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Rick Waldron]

I also still support a single object API exactly as Nicholas mentioned.

Rick

On Dec 9, 2011, at 5:51 PM, "Nicholas C. Zakas"  
wrote:

> 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ć  је написао/ла:
>> 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("").
>> 
>>  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
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Nicholas C. Zakas]

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ć > је написао/ла:


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("").

 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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Globalization API holiday summary

[Nebojša Ćirić]

6. Ability to set global locale list.

08. децембар 2011. 10.25, Nebojša Ćirić  је написао/ла:

> 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("").
>
>  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ć
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Globalization API holiday summary

[Nebojša Ćirić]

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("").

 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss