Native Fennec nightly always uses en-US for Java strings regardless of system language

VERIFIED FIXED

Status

()

Firefox for Android
General
--
major
VERIFIED FIXED
5 years ago
9 months ago

People

(Reporter: AdrianT, Assigned: joey)

Tracking

({regression})

15 Branch
ARM
Android
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox14 affected, firefox15+ verified, firefox16+ verified, blocking-fennec1.0 -, fennec15+)

Details

Attachments

(4 attachments)

(Reporter)

Description

5 years ago
Created attachment 626007 [details]
logs

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

5 years ago
Created attachment 626008 [details]
menu screenshot
(Reporter)

Comment 2

5 years ago
Created attachment 626009 [details]
settings screenshot
(Reporter)

Updated

5 years ago
Blocks: 713464
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

5 years ago
Summary: English labels are displayed after changing the language → en-US applied after restart on system language change

Updated

5 years ago
No longer blocks: 713464
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?

Updated

5 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 6

5 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
Adrian, thanks for the regression range.

http://hg.mozilla.org/mozilla-central/rev/c115c58ef2b1 is in there, aka bug 748470

Updated

5 years ago
Severity: normal → major
tracking-fennec: --- → ?
status-firefox15: --- → affected
Rel-eng issue?
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)
blocking-fennec1.0: --- → ?
status-firefox14: --- → affected
Blocks: 713464
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.
Created attachment 628673 [details]
Log Samsung Galaxy SII
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?
Blocks: 748470
> 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: + → ?
tracking-fennec: ? → 15+
blocking-fennec1.0: ? → -
tracking-firefox15: --- → +
(Assignee)

Comment 20

5 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

5 years ago
status-firefox16: --- → affected
tracking-firefox16: --- → ?
Assignee: mbrubeck → joey
Any update?
(Assignee)

Comment 22

5 years ago
Revert the patch if needed, locale deps may take a little while to track down.

Updated

5 years ago
tracking-firefox16: ? → +
(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

5 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

5 years ago
status-firefox15: affected → fixed
status-firefox16: affected → fixed
(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

5 years ago
Aiui, this should be fixed, and resolving will put this in QA's list for verification.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 27

5 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
status-firefox15: fixed → verified
status-firefox16: fixed → verified
You need to log in before you can comment on or make changes to this bug.