Hi David, I'm one of the editors of ECMA 402 and a champion of multiple proposals there. I'd like to respond to your comment:
On Saturday, April 30, 2016 at 1:26:53 PM UTC-7, David Baron wrote: > I still find it sad that ECMAScript Intl came (as I understand it) > very close to just standardizing on a piece of software (ICU), and > also find it disturbing that we're going to extend that > standardization on a particular piece of software (possibly even > more rigidly) into other areas. I think many of the arguments we > made against standardizing on SQLite seem to apply to ICU as well, > such as security risk and needing to reverse-engineer when writing > future implementations of parts of the Web platform. I disagree with this statement. While we are definitely looking into ICU APIs as one of the prior knowledge cases, we don't necessarily follow ICU. We design APIs based on what we see people request the most. In some cases, we align our API with ICU because we believe ICU got it right (DateTimeFormat), in others we go with our own API (PluralRules, UnitFormat, DurationFormat) and in yet others, we standardize something that ICU wants to pick from us (NumberFormat.formatToParts). What's important here, is that we deliberately write the spec to not depend on ICU and our reference implementation (Intl.js) is pure JS with no dependency on ICU so we are fairly certain that you don't need ICU to implement JS Intl API. What we do try to standardize around is CLDR as a kind of "wikipedia for i18n data". CLDR is just a database and having all major companies contribute to it makes it very powerful in giving us access to all the data we may need for internal and JS Intl API needs. > > While I expect that some of the features that Intl provides (from > ICU data) are worthwhile in terms of codesize, I'm certainly not > confident that they all are. I have similar worries about other > large chunks of code that land in our tree... > > And when I say worthwhile, I'm talking not just about whether the > feature is intrinsically valuable, but whether it's actually going > to be used by Web developers to get that value to users. We create APIs based on user needs. The way we determine what should stay in user land and what is worth standardizing is of course subjective, but we try to aim for lowering the barrier to write good multi-lingual applications so, obviously, we prioritize what's commonly used. > How much value does ICU get from dropping Windows XP support? Can > we push back on their plans to do so, at least for the parts that we > use? (It also seems to be that we need to answer the question, > already raised in this thread, about whether the parts that are > expensive for them to support intersect at all with the parts that > we use.) Unfortunately, it seems that ICU decided to drop Win XP support in ICU 58. Maybe we can provide them strong reasons for not doing that? We're currently starting an effort to deploy new L10n/I18n infrastructure for Firefox. While working on some of our most common needs (PluralRules, RelativeTimeFormat, UnitFormat), we reported bugs in CLDR and they are being fixed in time for CLDR 30. So while we may not need to update ICU for a while and could potentially get stuck on ICU 57 (I don't have enough knowledge to understand what might be the cost of that), I'd like to make sure we can move forward with updating CLDR in Gecko. Thanks, zb. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
