Turn on ENABLE_INTL_API=yes on Android's release build

RESOLVED FIXED in Firefox 56

Status

()

enhancement
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: m_kato, Assigned: zbraniecki)

Tracking

(Depends on 2 bugs, {dev-doc-complete})

Trunk
mozilla56
Unspecified
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 wontfix, firefox55 wontfix, firefox56 fixed)

Details

Attachments

(2 attachments)

I turn off ENABLE_INTL_API=yes on release build of Fennec. This is tracking bug that ENABLE_INTL_API=yes is turned on release build.
Depends on: 945123
Blocks: 866344
Joe, Jet, we've disabled ICU 4 months ago on release of Fennec with an intention to push for moving localization resources out of the build and then enable ICU.
With the recent decision to move the localization refactor to Q3, can we now unblock enabling ICU on release and cleaning up Gecko of off the non-ICU codepaths?
The engineering overhead, maintenance burden and accruing number of `gotchas` due to new APIs relying on ICU and not being present in Fennec is increasing with time.

In bug 1369544 comment 4 :rnewman stated that he's supporting enabling ICU unconditionally.
Flags: needinfo?(jcheng)
Flags: needinfo?(bugs)
Blocks: 1375236
Duplicate of this bug: 1342033
James offered to check for any blockers and see if we can get a green light now
Flags: needinfo?(snorp)
Flags: needinfo?(jcheng)
Flags: needinfo?(bugs)
Yeah, I think we should revisit this. Andreas, Joe, Connor: this will add APK size, but will reduce engineering friction which I think is desperately needed considering current resources dedicated to Fennec. It will also allow downloadable locales, which could reduce some of the APK size increase.
Flags: needinfo?(snorp)
Flags: needinfo?(mconnor)
Flags: needinfo?(jcheng)
Flags: needinfo?(abovens)
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #4)
> Yeah, I think we should revisit this. Andreas, Joe, Connor: this will add
> APK size, but will reduce engineering friction which I think is desperately
> needed considering current resources dedicated to Fennec. It will also allow
> downloadable locales, which could reduce some of the APK size increase.

How much additional APK size are we talking about?
Flags: needinfo?(abovens)
According to bug 1215247 comment 105 the change is 2.7mb. We should win those bytes back by the end of the year with the transition to the new localization API which will allow us to remove l10n data from the apk size (~2-3mb back).

re-requesting approval.
Flags: needinfo?(abovens)
No longer blocks: 1378782
Andres over email: "Sure, please go ahead."
Flags: needinfo?(abovens)
:gandalf, when do you expect to turn this on?
Flags: needinfo?(gandalf)
As soon as I get go-ahead from :jcheng. I'd like to try to land this in 56 to give us some time to confirm stability before we start removing old-APIs and with/after 57 there's going to be a lot of that (bug 1347507).
Flags: needinfo?(gandalf)
hi Zibi, please go ahead and land this feature but let's make sure we continue to work towards downloadable locales so we can reverse the apk size hit. Thanks
Flags: needinfo?(jcheng)
Flags: needinfo?(mconnor)
(In reply to Joe Cheng [:jcheng] (please needinfo) from comment #10)
> hi Zibi, please go ahead and land this feature but let's make sure we
> continue to work towards downloadable locales so we can reverse the apk size
> hit. Thanks

We're making good progress on that actually. It's a low priority for now, so I'm making sure not to take time from people working on 57, but here's the progress:

 - MessageContext is in review in bug 1347801
 - L10nRegistry is in review in bug 1333980
 - New langpack build system is in review in bug 1365440
 - New langpack runtime consumption is in development in bug 1365709

I expect them to land before 58, which means that by the time we're done with 57 we can start talking about transitioning toolkit strings to the new API which, in turn, will allow us to use langpacks for those strings in Android and reduce the apk size.
Comment on attachment 8887321 [details]
Bug 1344625 - Turn on ENABLE_INTL_API=yes on Android's release build.

https://reviewboard.mozilla.org/r/158144/#review163328

test_interfaces.html etc will be failure on beta and release channel.  So could you add backout patch of bug 1349879?  If adding it, it is OK.
Comment on attachment 8887321 [details]
Bug 1344625 - Turn on ENABLE_INTL_API=yes on Android's release build.

https://reviewboard.mozilla.org/r/158144/#review163338
Attachment #8887321 - Flags: review?(m_kato) → review+
Comment on attachment 8887334 [details]
Bug 1344625: Revert "Bug 1349879 - Intl object is hidden on Android beta and release channel".

https://reviewboard.mozilla.org/r/158164/#review163340
Attachment #8887334 - Flags: review?(m_kato) → review+
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c9951ce87dc
Turn on ENABLE_INTL_API=yes on Android's release build. r=m_kato
https://hg.mozilla.org/integration/autoland/rev/8bb928212540
Revert "Bug 1349879 - Intl object is hidden on Android beta and release channel". r=m_kato
https://hg.mozilla.org/mozilla-central/rev/5c9951ce87dc
https://hg.mozilla.org/mozilla-central/rev/8bb928212540
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Blocks: 676965
We are about to go to 55 RC. Mark 55 won't fix.
Developer release notes:
https://developer.mozilla.org/en-US/Firefox/Releases/56#JavaScript

Updated compat tables here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/prototype
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/supportedLocalesOf
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/compare
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/resolvedOptions
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/prototype
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/supportedLocalesOf
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/format
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/prototype
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/supportedLocalesOf
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/format
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/resolvedOptions
Blocks: 1400463
No longer blocks: 1400463
Depends on: 1400463
Blocks: 1416113
You need to log in before you can comment on or make changes to this bug.