Globalization API: Customers

Nicholas C. Zakas standards at
Tue Nov 29 13:09:32 PST 2011

Question about #5: are you also considering this to be server-side 
Node.js developers?

I'll take a stab at breaking this down. Admittedly, this is much harder 
than I thought it would be, so consider these numbers as order of 
magnitude indicators more than anything else:

Monolingual non-library users:        5%
Monolingual library users:              57%
Multilingual library users:               25%
Library developers:                        10%
Web service developers*:               3%

If Node.js developers are grouped into this category, then I would 
expect this number to grow.

A word of caution that I usually throw out in API discussions: I think 
it's a mistake to design an API with the intent that a library will 
smooth out the interface for you. IMHO, core language features should be 
usable out-of-the-box.


On 11/28/2011 12:09 PM, Norbert Lindenberg wrote:
> Looking at the feedback we've received on the Globalization API, it seems at least some of it is based on divergent assumptions about the developers who are going to use the API. Maybe we should step back and define the different developer groups we want to serve. Here's a first cut:
> 1: Developers of simple monolingual applications, using ECMAScript and DOM APIs directly without assistance from libraries. May need precise control over formatted strings in the language of their application.
> 2: Developers of simple or somewhat complex monolingual applications, using libraries such as jQuery, Dojo, YUI to wrap and enhance ECMAScript and DOM APIs. May need precise control over formatted strings in the language of their application.
> 3: Developers of complex multilingual applications, using libraries of course. May be willing to trade off precise control over formatted strings for support of many languages.
> 4: Developers of libraries. Need well-specified behavior of underlying ECMAScript API so that they can support both groups 2 and 3.
> 5: Developers of web services. Similar needs to 4.
> Are there any groups missing or mischaracterized? Also, can those of you who interact a lot with developers try and attach percentages to the groups? The ratio between groups 1 and 2, for example, could drive the decision whether we need default locale management in the standard API or whether we can lean on libraries to provide this functionality.
> Thanks to Nicholas, who pointed out that we may have been focusing too much on "the big boys", group 3.
> Norbert
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list