Globalization API: Customers
Nicholas C. Zakas
standards at nczconsulting.com
Tue Nov 29 13:09:32 PST 2011
Question about #5: are you also considering this to be server-side
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
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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss