Intl.UnitFormat is in a pretty early stages of design, and there's at least one proposal to merge it into NumberFormat. In order to get a simple UnitFormat from ICU, I'd like to first land it directly into mozIntl so that we can use it in Firefox until we get a solid proposal within ECMA402.

Andre - in bug 1449505 comment 4 you calculated the bundle size increase from enabling lang/region/script data in ICU to be close to 3mb. > This will increase config/external/icu/data/icudt60l.dat from 11,585,936 bytes to 14,464,288 bytes. But the pool.res files in both are much smaller. > 112K ./lang/pool.res > 80K ./region/pool.res Can you help me understand how those 200kb translate to 3mb? I'm asking here because it seems that we're also cutting out unit measurements which is > 80K ./unit/pool.res If that's also a substantial size increase, I'll be tempted to do here the same thing as in bug 1449505 and ship the data per-locale as part of lang resources to minimize the impact on the build size. On the other hand, with the proposal for revised numberformat it seems like we'll have units in Intl.NumberFormat [0] at some point and we'll need to include it. Does it mean we'll have to add ~1.5mb to the build size? (1.5mb is my estimation based on 200kb of pool.res from lang/region adding 3mb) [0] https://github.com/tc39/ecma402/issues/215

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #1) > Can you help me understand how those 200kb translate to 3mb? Unfortunately I don't know how ICU packs the data internally and why the size difference the pool.res files and the resulting icudt61l.dat is that large.

It's a nice to have, but wont block Preferences

This is now superseeded by the revision of Intl.NumberFormat https://github.com/tc39-transfer/proposal-unified-intl-numberformat