1433325 - Replace --with-intl-api=false with building ICU with just en data.

Status: NEW

(Core :: Internationalization, enhancement, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

Spinoff from bug 1402379 comment 8:

Currently, per request from the research team, we kept the build time option to build SpiderMonkey without Intl API (and in result without ICU).

The motivation is to preserve ability to build a JS engine without the cost of including all of the ICU that we ship.

I'd like to propose to switch this to an option of building SpiderMonkey with ICU only with data for en locale.

This has several benefits:

 - It would clean up our build system and remove ifdefs.
 - It would make SpiderMonkey stop breaking on code that expects Intl API to be present (which is supported by all modern engines and thus we cannot expect libraries to test for Intl object presence anymore[0])
 - It would allow us to further rely on ICU operations that are data independent (locale validation/canonicalization etc.) further reducing maintenance cost.


My hypothesis is that building SpiderMonkey/Firefox with just en data vs building it without ICU at all is not going to result in any substantial package size increase, but I don't know how to test that assumption.

[0] http://kangax.github.io/compat-table/esintl/

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

:jfkthame, :m_kato, :waldo, :anba - thoughts?

Comment 2

[Makoto Kato [:m_kato]]

When I tested en only data for bug 1418296, jsreftest and jit test crashed.  (I don't investigate why these test crashes)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b8e2af73aa5bd730dd1179eb013f0f44e5bf6f3

If we add task cluster job for this pattern, we might need additional investigation.

Comment 3

[André Bargull [:anba]]

(In reply to Makoto Kato [:m_kato] from comment #2)
> When I tested en only data for bug 1418296, jsreftest and jit test crashed. 
> (I don't investigate why these test crashes)
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=6b8e2af73aa5bd730dd1179eb013f0f44e5bf6f3
> 
> If we add task cluster job for this pattern, we might need additional
> investigation.

Some browsers tests will fail because we expect to always have support for all supported locales: https://searchfox.org/mozilla-central/source/js/src/tests/non262/Intl/Collator/supportedLocalesOf.js

Other parts could fail because our fallback locale is "en-GB" and not "en-US": https://searchfox.org/mozilla-central/rev/062e1cf551f5bf3f0af33671b818f75a55ac497b/js/src/builtin/Intl.js#582-586

Comment 4

[André Bargull [:anba]]

As mentioned in bug 1402235 comment #5, we currently already require ICU for certain non-Intl functions and we will also require ICU for bug 1361876 and bug 1346211. So embedders using ENABLE_INTL_API=no will need to cope with having certain built-in non-Intl functionality not being available. 

Do we care about the use case reported by :sfink in bug 1402235 comment #3?

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to André Bargull [:anba] from comment #3)
> Other parts could fail because our fallback locale is "en-GB" and not
> "en-US":
> https://searchfox.org/mozilla-central/rev/
> 062e1cf551f5bf3f0af33671b818f75a55ac497b/js/src/builtin/Intl.js#582-586

I was a bit surprised by this choice; I'd have expected en-US as the last-ditch fallback, because this is (I suspect) the most widely-used default in the tech world, and consistency with other software people are exposed to is worth something.

While it's probably true that many of the en-[non-US] locales around the world are more similar to en-GB than to en-US, I think this is countered by the fact that most non-native-English speakers are heavily exposed to US English (through technology and media of all kinds), and probably more accustomed to seeing this than to any specific other en-* locale.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

> While it's probably true that many of the en-[non-US] locales around the world are more similar to en-GB than to en-US, I think this is countered by the fact that most non-native-English speakers are heavily exposed to US English (through technology and media of all kinds), and probably more accustomed to seeing this than to any specific other en-* locale.

That's true for localization, but not internationalization.

US date format, US imperial measurement system, US temperature units and US number patterns are less popular around the World than GB (which is more similar to all other en-*).

I think it's the right choice for internationalization TBH.

Comment 7

[Jonathan Kew [:jfkthame]]

Hmm.... yes, that's a fair point. Just forget I mentioned it! :)

Comment 8

[André Bargull [:anba]]

Do we care about bug 1264836/bug 1322212 before potentially removing "--with-intl-api=false"?

Comment 9

[Jeff Walden [:Waldo]]

This doesn't seem like a bad idea to me.  I doubt there's a way to test size increase other than by just doing it.

Big-endian is not t1, so I don't think we care.  Shouldn't be impossible for affected embedders to add support, seems like.