Globalization API - Sample Use Cases

Nebojša Ćirić cira at
Fri Dec 2 13:35:39 PST 2011

I agree that object literals are more verbose, but they are also more
readable. I did hear some complains about formatting strings missing from
the latest spec (we had them before), and mostly from people that know how
to use them (I still need to look up CLDR docs to write a semi complex one).

The easy solution to that is to add 2 more fields to the options (or have
them as separate parameter):

1. pattern - as is, I know what I want - MM/yy always generates 9/74 no
matter the locale.
2. skeleton - MM/yy will get you closest matching pattern for a given

If pattern or skeleton fields are specified, we ignore the rest of the
options object.

We had this approach before and removed it from the spec to simplify the
API, but it shouldn't be hard to get it back in.

02. децембар 2011. 13.28, Nicholas C. Zakas
<standards at>је написао/ла:

> Instead of continuing with the previous thread, I figured it would be
> easier to start a new one.
> One of my main points about the current Globalization API is that the API
> seems to be designed around complex use cases vs. simple use cases. Whether
> intentional or unintentional the Globalization API fills two gaps in
> ECMAScript: number formatting and date formatting. Setting aside the
> ability to internationalize currencies and dates, this is a capability that
> has long been missing from ECMAScript and developers will rejoice if/when
> it arrives.
> That being said, I think there's a strong possibility that simple
> date/number formatting will end up being a popular use case of the API as
> opposed to those who are actively looking for locale-specific changes due
> to an internationalized product. I'd venture a guess to say that the common
> uses would end up being:
> 1. Date formatting
> 2. Number formatting
> 3. Comparing/sorting (with the current Collator)
> I would love it if the ability to format numbers and dates were simpler
> than currently spec'ed, more specifically, if the object literals could be
> done away with in favor of formatting strings. Yes, I know formatting
> strings have some limitations, however the way I have created
> internationalized applications in the past has been by abstracting out the
> internationalized parts into configuration files (such as a Java properties
> file). The data from that could then be passed into a JS API that Did The
> Right Thing. Formatting strings make this trivial, needing to code up an
> object literal makes this trickier (JSON is not a great format for config
> files).
> Just a few extra cents.
> -N
> ___________________________
> Nicholas C. Zakas
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list