Globalization API - Sample Use Cases
Nicholas C. Zakas
standards at nczconsulting.com
Tue Dec 6 11:42:10 PST 2011
On 12/2/2011 1:35 PM, Nebojša Ćirić wrote:
> 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).
I agree that object literals are more readable. The price you pay for
that readability is opacity and many, many characters to get the correct
behavior. Also, as mentioned before, it makes externalizing
internationalized settings into a configuration file much more complicated.
> 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.
I like it. I'd even go one step further to suggest that the first
argument be allowed as either a string or an object. If a string, then
treat as a pattern, otherwise, treat as an options object.
> 02. децембар 2011. 13.28, Nicholas C. Zakas
> <standards at nczconsulting.com <mailto:standards at nczconsulting.com>> је
> 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
> 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.
> Nicholas C. Zakas
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> Nebojša Ćirić
Nicholas C. Zakas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss