Globalization API Feedback

Nicholas C. Zakas standards at
Mon Nov 21 11:12:57 PST 2011

As promised, more verbose feedback for the Globalization API. My general 
feeling is that the API is overly verbose for what it's doing. I'll 
state my bias up front: I'm not a fan of introducing a bunch of new 
types to handle formatting. I'd much rather have additional methods that 
perform formatting on existing objects. My feedback is mostly about 
eliminating the new constructors - which has an added bonus of 
eliminating the Globalization namespace because there would be only one 
constructor left: Collator.

1. LocaleList

I'm not sure why this type is necessary. I don't believe that locale 
resolution is an expensive operation, and even if it is, I'd expect the 
implementation to cache the results of such resolution for later use. 
I'd just leave this as an internal construct and instruct developers to 
use arrays all the time.

2. supportedLocalesOf

I find this method name strange - I've read it several times and am 
still not sure I fully understand what it does. Perhaps 
"getSupportedLocales()" is a better name for this method? (I always 
prefer methods begin with verbs.)

3. NumberFormat

Number formatting seems simple enough that it could just be added as a 
series of methods on Number.prototype. The three types of formatting 
(currency, decimal, percent) could each have their own method. Currency 
formatting has relatively few options to specify, so it's method can be:

      * Formats the number as if it were currency
      * @param code Currency code, e.g., "EUR"
      * @param type (Optional) The way to format the currency code, 
"code", "symbol" (default),
      * @param locales - (Optional) Array of locales to use.
     Number.prototype.toCurrencyString = function(code, type, locales) {

     var num = 500;
     console.log(num.toCurrencyCode("EUR", "code"));    //"EUR 500.00"

Decimal and percent formatting options are slightly different in that 
they include significant digits options. For that, I prefer to use a 
formatting string rather than the multitude of optional properties as 
currently defined (see The 
formatting string indicates must-have digits as 0 and optional digits as 
#, allowing you to very succinctly specify how you want your number to 
be output. For example:

      * Formats the number as a decimal string.
      * @param format Format string indicating max/min significant digits
      * @param locales (Optional) Array of locales to use.
     Number.prototype.toDecimalString = function(format, locales){

      * Formats the number as a percent string.
      * @param format Format string indicating max/min significant digits
      * @param locales (Optional) Array of locales to use.
     Number.prototype.toPercentString = function(format, locales){

     var num = 1234.567;
     console.log(numtoDecimalString("000##.##")); "01234.57"

4. DateTimeFormat

As with NumberFormat, it seems like this could more succinctly be 
implemented as a method on Date.prototype. As its easiest:

      * Format a date
      * @param options The already-defined options for DateTimeFormat
      * @param locales (Optional) Array of locales to use.
     Date.prototype.toFormatString = function(options, locales){

In an ideal world, I'd like to see options overloaded so it can be an 
options object as specified now or a formatting string. I understand 
that there was a sentiment against formatting strings due to their 
limitations and edge case errors. However, I'd like to point out that 
any internationalized web application is highly likely to already be 
using formatting strings for dates, since this is pretty much how every 
other language handles date formatting. That means supporting format 
strings in JavaScript would allow application developers to reuse the 
settings they already have. As it stands now, you'd need to create two 
different ways of formatting dates for a web app: one for your 
server-side language and one for your client-side language (until the 
day everything is running on Node.js, of course). I'd prefer my 
client-side code to reuse settings and configuration that the 
server-side code uses, otherwise I end up with two very different pieces 
of code doing the exact same thing, and there be dragons.


More information about the es-discuss mailing list