I think that we have agreement on being able to set global locale and to
move locale list into options (anybody against?).
I have couple questions with toLocaleString approach:
1. Who imports the @g11n module in this case? Implementation (under which
name) or the user (what happens if they don't, and then try to use
toLocaleString)?
2. Do we keep original API (new DateTimeFormat(), and its methods) as an
alternative that would let user:
2.a. Find out if there were fallbacks through object state
2.b. Apply format repeatedly using the same options (internal caching may
remove this requirement)
3. Does it make sense to hang Collator on String or any other built-in type?
4. Would we hang calendars in the future on Date?
18. новембар 2011. 13.16, Erik Arvidsson <erik.arvids...@gmail.com> је
написао/ла:
> On Fri, Nov 18, 2011 at 12:41, Norbert Lindenberg
> <ecmascr...@norbertlindenberg.com> wrote:
> > With that, the first example would become:
> >
> > var price = 300,
> > currency = price.toLocaleString(localeList, {style: "currency",
> currency: "USD"});
>
> We also talked about moving the localeList into the options and
> defaulting to the default localelist which would make it even more
> concise.
>
> var price = 300;
> var currency = price.toLocaleString({style: "currency", currency: "USD"});
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
