On Dec 3, 2012, at 11:48 , Benjamin Smedberg wrote: > On 12/3/2012 2:32 PM, Norbert Lindenberg wrote: >> As part of implementing the ECMAScript Internationalization API [1, 2] in >> SpiderMonkey, and as an aid in internationalizing other functionality in >> Mozilla products [3], I need to integrate the ICU library (International >> Components for Unicode [4]) into the source tree and the build. > This has been brought up many times over the years, and each time previously > we decided not to import ICU. At first, the license was incompatible; that > has since been fixed. Now the question is mainly about whether the features > ICU provides are worth the really cost in terms of binary size.
OK, just as an introduction, why we're doing this: The ECMAScript Internationalization API (which has been approved by Ecma TC 39 and is on track to become an Ecma standard next week) provides web applications with the ability to format numbers, dates, and times and sort strings according to the rules of the language that the application is using, not the one that browser and OS default to. Many users are multilingual and go to web sites in different languages, and even users who aren't sometimes have to use browsers that don't support their language. The API in addition lets applications tailor the results to their specific needs, e.g., specify the currency with which numbers are displayed, select the date-time components used in a date format, or ignore punctuation in sorting. To implement that, we need good library support, and ICU fits the bill. > How much size does ICU cost, if we took the entire library? How much of that > is data (which can be shared in 32/64 mac universal builds) and how much is > code which cannot be shared? On my Mac (64 bit), the full data library is 20.8 MB, the six code libraries combined 4.2 MB. > How much smaller can we make it if we take only the bits we need for the JS > APIs? I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for two code libraries. > Can we remove or replace some of our existing intl code with ICU, to reduce > the impact? (Have you discussed this with smontagu?) The functionality needed for the internationalization API and for the existing intl code don't overlap much - the existing code relies on the OS for number and date formatting and string comparison. The biggest chunk of intl code that could be replaced with ICU is encoding conversion, which I've currently cut from my ICU build. > Is ICU already available on Android, or would we have to include it in our > Android package? I'm told Android has ICU, but it's only available for system apps. Chrome installs its own copy. > What are our other options if we decide the ICU is just too large or unwieldy? Well, the first question is what size increase would be acceptable given the benefits that ICU provides. Obviously, there's a wide range options from cutting the set of locales and possibly some features from ICU, to trying to build as much of the internationalization API as possible on top of the various OS APIs, with various trade-offs between download size, available functionality, supported locales, compliance with the standard, and engineering effort. Norbert _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
