- Even if test is failure, we turn off INTL_API on release build now. - Re-implement DateTimeFormater for non-INTL_API build - After re-implementing it, turn off INTL_API on Android/x86 only even if not released build (for test)

does it mean Intl API won't be available on release build? in that case the documentation should be updated.

(In reply to Tooru Fujisawa [:arai] from comment #1) > does it mean Intl API won't be available on release build? > in that case the documentation should be updated. Yes, this is current decision. But it won't be final.

Can you provide some timeline for this? (timeline for when we'll be able to release Android with ICU and get rid of the non-ICU codepaths) I'm working on a lot of elements that rely on INTL_API like LocaleService (with language negotiation), OSPreferences, mozIntl, L10nRegistry.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #3) > Can you provide some timeline for this? (timeline for when we'll be able to > release Android with ICU and get rid of the non-ICU codepaths) > > I'm working on a lot of elements that rely on INTL_API like LocaleService > (with language negotiation), OSPreferences, mozIntl, L10nRegistry. :snorp, could you answer it?

In that case bug 1200494 part 1 (https://hg.mozilla.org/mozilla-central/rev/e07ec12de6c0) will need backing out again.

Do we leave untested-until-it-reaches-beta code path indefinitely? I don't think it works well. We should either: 1. Stand-up Intl/non-Intl jobs in automation (like e10s/non-e10s), or 2. Disable Intl on Android completely.

For test, - I will add skip-if for some xpshell test such as test_localeCompare.js. - mochitest doesn't run on android-x86, so even if android-x86's all build turns off INTL API, we don't cover all tests on android-api-15. (Maybe, snorp or blassy misunderstands it) - I will add skip code for mochitest's interface tests such as test_interfaces.html - gtest doesn't run on all Android. So we can ignore this - Like comment #5, we need back out it. (for test_DownloadUtils.js)

I don't think there is a specific timeline for when we'll be able to ship ICU on Android. It will depend on the efforts to get the APK size down.

I've tried disabling the Intl API on Nightly for testing purposes, but all I'm getting is a busted build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150 Is that to be expected because of bug 1343766, or is this something else that need reverting again?

(In reply to Jan Henning [:JanH] from comment #9) > I've tried disabling the Intl API on Nightly for testing purposes, but all > I'm getting is a busted build: > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150 > > Is that to be expected because of bug 1343766, or is this something else > that need reverting again? bug 1344596 and bug 1343766

Builds pass, but there are at least some xpcshell failures.

Forgot the link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=68413037ea33b83c9cd2ecec8ebe8212fa28786f

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #8) > I don't think there is a specific timeline for when we'll be able to ship > ICU on Android. It will depend on the efforts to get the APK size down. Is there some documented criterion for the APK size and some documented rationale for that criterion? Is there an ongoing effort to slim down the non-libxul parts of the APK?

(In reply to Henri Sivonen (:hsivonen) from comment #13) > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #8) > > I don't think there is a specific timeline for when we'll be able to ship > > ICU on Android. It will depend on the efforts to get the APK size down. > > Is there some documented criterion for the APK size and some documented > rationale for that criterion? Is there an ongoing effort to slim down the > non-libxul parts of the APK? There may be some documented rationale somewhere, but AFAIK there is no target number. Only that "smaller is better". My understanding is that there are ongoing conversations right now with product/BD about this.

One such effort is led by me in tracking bug 1347797. The bug itself is deceivingly calm, but look at the dependency tree.

I'll change the documentation listed in bug 1215247 comment #104 to say it's nightly-only.

updated: https://developer.mozilla.org/en-US/Firefox/Releases/54 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare 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/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 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales

all issues are closed and this is meta bug. So I close this.

Thanks for the docs!