Closed
Bug 757442
Opened 12 years ago
Closed 12 years ago
Native Fennec nightly always uses en-US for Java strings regardless of system language
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox14 affected, firefox15+ verified, firefox16+ verified, blocking-fennec1.0 -, fennec15+)
People
(Reporter: AdrianT, Assigned: joey)
References
Details
(Keywords: regression)
Attachments
(4 files)
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.
Reporter | ||
Comment 1•12 years ago
|
||
Reporter | ||
Comment 2•12 years ago
|
||
Comment 3•12 years ago
|
||
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).
Updated•12 years ago
|
Summary: English labels are displayed after changing the language → en-US applied after restart on system language change
Comment 4•12 years ago
|
||
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?
Comment 5•12 years ago
|
||
(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?
Updated•12 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 6•12 years ago
|
||
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.
Keywords: regressionwindow-wanted
Comment 7•12 years ago
|
||
Adrian, thanks for the regression range.
http://hg.mozilla.org/mozilla-central/rev/c115c58ef2b1 is in there, aka bug 748470
Updated•12 years ago
|
Comment 8•12 years ago
|
||
Rel-eng issue?
Comment 9•12 years ago
|
||
nope, build magic more likely. Joey was the author of the build magic patch within the regression range.
Comment 10•12 years ago
|
||
Reproducible also on:
Aurora 14.0a2 (2012-05-30)
Device: Samsung Galaxy SII (2.3.4)(Espanol)
blocking-fennec1.0: --- → ?
status-firefox14:
--- → affected
Comment 11•12 years ago
|
||
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.
Comment 13•12 years ago
|
||
This is central/nightly only, AFAIK. If it's the build logic that I suspect, it wouldn't affect aurora.
Comment 14•12 years ago
|
||
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.
Comment 15•12 years ago
|
||
Comment 16•12 years ago
|
||
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
Comment 17•12 years ago
|
||
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
Comment 18•12 years ago
|
||
(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?
Blocks: 748470
Comment 19•12 years ago
|
||
> 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: + → ?
Updated•12 years ago
|
Assignee | ||
Comment 20•12 years ago
|
||
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.
Updated•12 years ago
|
status-firefox16:
--- → affected
tracking-firefox16:
--- → ?
Updated•12 years ago
|
Assignee: mbrubeck → joey
Comment 21•12 years ago
|
||
Any update?
Assignee | ||
Comment 22•12 years ago
|
||
Revert the patch if needed, locale deps may take a little while to track down.
Updated•12 years ago
|
Comment 23•12 years ago
|
||
(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?
Comment 24•12 years ago
|
||
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.
Updated•12 years ago
|
Comment 25•12 years ago
|
||
(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?
Comment 26•12 years ago
|
||
Aiui, this should be fixed, and resolving will put this in QA's list for verification.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 27•12 years ago
|
||
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
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•