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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
