Globalization API Feedback - moar!

Nebojša Ćirić cira at google.com
Fri Dec 2 13:28:12 PST 2011


>
> At this point we have 3 proposals:
>
> 1. Tie in to toLocaleString type of methods
> 2. Functional proposal
> 3. Object-based proposal
>
> I think 1. suffices for a casual user that doesn't care about what got
> resolved to what, and which locale or pattern fallback was used.
>
> We could expose either 2. or 3. to an advanced user who needs more
> control. Now, if 1. is sufficiently functional (it's built in anyways),
>
>
> (1) is all we need in the way of functional (methodical) API, IMHO. If I
> recall correctly, it includes new methods, not just toLocaleString -- is
> that correct?
>

Norbert's list (
http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration)
contains only what's currently available in ES. It is possible that in some
future iteration of both standards we may have to add new built in methods
(say to handle time zones, calendars, break iterators...) - but that's out
of scope for the current spec.

We would need to flesh out actual mechanizm of combining (1) and (3) -
importing, what to do if i18n support is not available...

I am leaning towars having (1) and (3) available, skipping (2) completely.
We can't remove (1) from the language so we better improve it. The question
is - should we use (2) or (3) to achieve that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111202/8da7a4c5/attachment.html>


More information about the es-discuss mailing list