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ć <[email protected]
<mailto:[email protected]>> је написао/ла:
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] <mailto:[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]
<mailto:[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. Zakas
http://www.nczonline.net
--
Nebojša Ćirić
--
Nebojša Ćirić
--
___________________________
Nicholas C. Zakas
http://www.nczonline.net
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
