Closed Bug 757442 Opened 9 years ago Closed 9 years ago
Native Fennec nightly always uses en-US for Java strings regardless of system language
Nightly 15.0a1 2012-05-22 Device: HTC Desire/HTC Desire Z/Samsung Galaxy Nexus OS: Android 2.2.2/Android 2.3.3/Android 4.0.2 Steps to reproduce: 1. Install the latest Nightly multi-local build. 2. Use the app to navigate a few webpages. 3. Go to Settings and change the language( I tried Polish and Check on HTC Desire, French on HTC Desire Z and Samsung Galaxy Nexus). 4. Open Nightly and verify that the labels are changed. Expected results: All the labels are changed to the correct language. Actual results: Only the more button on the non ICS phone is changed the rest remain in English. Note: The issue is not reproducible on Aurora 14.0a2 2012-05-21.
Is this a regression, or is this something expected on Nightly builds? I do see the size difference on Nightly (~17MB), vs en-US (~15MB).
Summary: English labels are displayed after changing the language → en-US applied after restart on system language change
I can reproduce this, but it seems to only affect the native UI bits. The neterror pages show up in German for me, for example. More buildlogic regressions?
(In reply to Axel Hecht [:Pike] from comment #4) > I can reproduce this, but it seems to only affect the native UI bits. > > The neterror pages show up in German for me, for example. > > More buildlogic regressions? from irc w/khuey, ted: 1) there were some makefile changes 16may, but none that we can recall in this area since then. 2) Is it possible this has been broken since 16may? Can you clarify when this started to happen?
Good build: May 12th Bad build: May 13th Possible regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22a58090fa70&tochange=c758cc9b60e5 On these builds I am seeing issues with loading about:home after a language change, however these issues are not reproducible on the latest Nightly.
Adrian, thanks for the regression range. http://hg.mozilla.org/mozilla-central/rev/c115c58ef2b1 is in there, aka bug 748470
nope, build magic more likely. Joey was the author of the build magic patch within the regression range.
Reproducible also on: Aurora 14.0a2 (2012-05-30) Device: Samsung Galaxy SII (2.3.4)(Espanol)
Matt, can you please investigate this. We'd like to know if this is a channel specific issue (i.e. due to locales not being complete in aurora and nightly) and if we can nail down what's causing this. Please renom if it is not severe enough to warrent blocking after your investigation.
Assignee: nobody → mbrubeck
tracking-fennec: ? → 14+
blocking-fennec1.0: ? → +
Was fennec quit out of before the switch of the language? I don't see this issue if I quit out of fennec first on Aurora 14.0a2 2012/5/30. This is on Samsung Galaxy S II. Also to note, I can see French and Italian just fine.
This is central/nightly only, AFAIK. If it's the build logic that I suspect, it wouldn't affect aurora.
I'm still able to reproduce the bug on my device (Samsung Galaxy SII - Android 2.3.4): Steps: 1. Install Aurora multi-local 14.0a2 (2012-05-30). 2. Start Aurora with the device OS set to English 3. Go to Menu -> More and Quit Aurora 4. Go to Settings and change the language( I tried Español and Português) 5. Open Nightly and verify that the labels are changed. Expected results: All the labels are changed to the correct language. Actual results: Only the More button is localized, the rest remain in English. Unable to reproduce on LG Optimus 2x (Android 2.2)and HTC Desire (Android 2.2) See the attached log.
re: Johnath yesterday, restarting phone does not correct the behaviour. Tested: System device language; from: English (United States), to: Français - while Nightly/Aurora are running yields: en-US System device language; from: English (United States), to: Français - while Nightly/Aurora are not running yields: en-US
So, is there any situation where en-US strings are *not* used for Java UI elements (like the options menu)? In my testing, en-US is *always* used, even if the system is set to a different locale from the start.
Summary: en-US applied after restart on system language change → Native Fennec nightly always uses en-US for Java strings regardless of system language
(In reply to adrian tamas from comment #6) > Good build: May 12th > Bad build: May 13th Comparing these builds, I see that resources.arsc is about 60% smaller in the May 13th build: May 12: 147440 resources.arsc May 13: 57592 resources.arsc So it appears likely that all the Java strings are not being packed correctly in multi-locale nightlies. I agree this is likely a regression from bug 748470. Joey, do you know what might cause this? If not, can back out bug 748470 to see if it fixes this?
> If not, can back out bug 748470 to see if it fixes this? I meant "can *we* back out..." Un-setting blocking-fennec1.0 and tracking-fennec:14+ because this appears to be a regression from a Firefox 15-only patch, so it will not affect the 14.0 release.
tracking-fennec: 14+ → ?
blocking-fennec1.0: + → ?
makefile edits from 748470 allow make to behave properly wrt dependencies, only regenerating files when content changes are made instead of regenerating on every call. What may be missing/still needed are locale specific deps for handling multi-locale generation in parallel. Working on a multi-locale build now to try and track this down. [ps] unit tests will also need to be written to detect problems like these automatically.
Revert the patch if needed, locale deps may take a little while to track down.
(In reply to Joey Armstrong [:joey] from comment #22) > Revert the patch if needed, locale deps may take a little while to track > down. Joey - can you prepare the backout patches for bug 748470 and nominated for mozilla-aurora approval?
Bug 748470 was backed out. Aurora's nightly should have the fix as of Tuesday night. Mozilla-central's nightly should have the fix as of last night.
(In reply to Aki Sasaki [:aki] from comment #24) > Bug 748470 was backed out. > Aurora's nightly should have the fix as of Tuesday night. > Mozilla-central's nightly should have the fix as of last night. I've marked the status to reflect my understanding (please correct me if wrong). Can this be closed out now?
Aiui, this should be fixed, and resolving will put this in QA's list for verification.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Unable to reproduce the issue on: Firefox Mobile 16.0b5 / Firefox Mobile 15 Samsung Galaxy R (Android 2.3.4) Marking as verified on Firefox Mobile 16
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.