Closed Bug 1265486 Opened 3 years ago Closed 3 years ago

Mixed localization in 48

Categories

(Firefox Build System :: Android Studio and Gradle Integration, defect, major)

defect
Not set
major

Tracking

(firefox47 unaffected, firefox48blocking fixed, firefox49 fixed)

RESOLVED FIXED
mozilla49
Tracking Status
firefox47 --- unaffected
firefox48 blocking fixed
firefox49 --- fixed

People

(Reporter: MikkCZ, Assigned: glandium)

References

Details

Attachments

(3 files)

I just installed nightly on my phone and noticed Chinese symbols together with Czech.
flod, any idea what could be going on here?
Flags: needinfo?(francesco.lodolo)
Just an update, the strings seems to match zh-TW translations.
I confess I have no idea of what's going on. CCing a couple of people that might know more in case it's a build issue (that would be my first guess).

Both strings are localized for Italian in 2016-04-17, in 2016-04-19 I only see the Cisco plugin. 

My only explanation would be that strings from zh-TW remain around in the build system (from aurora?), and are used in cs since there's no locale working on nightly until es-ES
https://transvision.mozfr.org/string/?entity=dom/chrome/plugins.properties:widevine_description&repo=central
Flags: needinfo?(francesco.lodolo)
I have unzipped the Nightly .apk and contained omni.ja and the zh-TW strings are there in the "cs" folder.
(In reply to Francesco Lodolo [:flod] from comment #4)
> My only explanation would be that strings from zh-TW remain around in the
> build system (from aurora?), and are used in cs since there's no locale
> working on nightly until es-ES

I forgot that we have multi-locale builds on Android. Which package did you install? Multi-locale or single locale?
I've unzipped both .apk (multi, cs) from here but can't see any Chinese string outside of zh-TW
http://archive.mozilla.org/pub/mobile/nightly/latest-mozilla-central-android-api-15-l10n/
Multilocale from https://nightly.mozilla.org/ (for ARM devices).

I see them at least in fennec-48.0a1.multi.android-arm.apk/assets/omni.ja/chrome/cs/locale/cs/browser/overrides/dom/dom.properties and fennec-48.0a1.multi.android-arm.apk/assets/omni.ja/chrome/cs/locale/cs/browser/browser.properties.
(In reply to Michal Stanke (Mozilla.cz) [:MikkCZ] from comment #8)
> Multilocale from https://nightly.mozilla.org/ (for ARM devices).
> 
> I see them at least in
> fennec-48.0a1.multi.android-arm.apk/assets/omni.ja/chrome/cs/locale/cs/
> browser/overrides/dom/dom.properties and
> fennec-48.0a1.multi.android-arm.apk/assets/omni.ja/chrome/cs/locale/cs/
> browser/browser.properties.

Thanks, they're indeed there. I did check the files, but it was from a different multilocale apk (fennec-48.0a1.cs.linux-androideabi-arm, no clue what this is).

Nightly page points to
https://archive.mozilla.org/pub/mobile/nightly/latest-mozilla-central-android-api-15/fennec-48.0a1.multi.android-arm.apk

And all strings in browser.properties and dom.properties are from zh-TW, not just the ones missing.
From a quick look this affects all locales besides en-US, es-ES, fr, it, ru. So it almost seems to fallback to zh-TW instead of en-US.

But if you check some of the files (e.g. appstrings.properties), you'll see English strings at the bottom that I assume were added by compare-locales.

@nalexander
Are you aware of any change in the build system that could cause this (or know who would know it)?
Flags: needinfo?(nalexander)
Adding Pike's note received via email (he's not in front of a computer with Bugzilla login)

> This is using one mergedir for all locales, most likely
Duplicate of this bug: 1265269
(In reply to Francesco Lodolo [:flod] from comment #10)
> From a quick look this affects all locales besides en-US, es-ES, fr, it, ru.
> So it almost seems to fallback to zh-TW instead of en-US.

Exactly those 100% complete in central. To me it looks like all incomplete files are replaced by their zh-TW version (because it's alphabetically the last locale?).
It'd be really helpful to get a regression range here.
(In reply to Francesco Lodolo [:flod] from comment #10)

> @nalexander
> Are you aware of any change in the build system that could cause this (or
> know who would know it)?

Nick is occupied working on Tofino, redirecting to glandium.
Flags: needinfo?(nalexander) → needinfo?(mh+mozilla)
This is a regression from bug 1256979, which now symlinks into the merge dir, which makes us ship the last locale of the file for anything that's merged.

There are three ways out of here:

- go back to flat staging for Android
- just use flat staging for multilocale builds in the chrome-% step
- use different mergedirs per locale in the mozharness code

Glandium, which of those sounds best to you?
Component: Locale switching and selection → Build Config & IDE Support
Depends on: 1256979
Duplicate of this bug: 1266031
[Tracking Requested - why for this release]: This should be fixed before 48 Aurora updates are enabled.
(In reply to Axel Hecht [:Pike] from comment #17)
> This is a regression from bug 1256979, which now symlinks into the merge
> dir, which makes us ship the last locale of the file for anything that's
> merged.
> 
> There are three ways out of here:
> 
> - go back to flat staging for Android
> - just use flat staging for multilocale builds in the chrome-% step
> - use different mergedirs per locale in the mozharness code
> 
> Glandium, which of those sounds best to you?

Probably the second.
Flags: needinfo?(mh+mozilla)
Tracking as it is critical
Summary: Mixed localization in nightly builds → Mixed localization in 48
Since yesterdays build several (all?) things that are affected by this language bug are not working anymore at all:
- long-pressing a link does not show the popup for "open link in new tab" etc
- closing a tab does not show "undo close tab"
- error pages are not shown
...

Changing the language to US-English fixes the problem. My system default is German.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=86730d0a82093d705e44f33a34973d28b269f1ea&tochange=8c3fd523d75bd30f691ca2d6cfdad18d576392a1
Severity: normal → major
(In reply to Mike Hommey [:glandium] from comment #20)
> (In reply to Axel Hecht [:Pike] from comment #17)
> > This is a regression from bug 1256979, which now symlinks into the merge
> > dir, which makes us ship the last locale of the file for anything that's
> > merged.
> > 
> > There are three ways out of here:
> > 
> > - go back to flat staging for Android
> > - just use flat staging for multilocale builds in the chrome-% step
> > - use different mergedirs per locale in the mozharness code
> > 
> > Glandium, which of those sounds best to you?
> 
> Probably the second.

Let's go with the first, it's easier. Long term, the third is probably better.
Assignee: nobody → mh+mozilla
Comment on attachment 8747483 [details]
MozReview Request: Bug 1265486 - Use flat chrome format for mobile/android builds. r?chmanchester

https://reviewboard.mozilla.org/r/49909/#review46639
Attachment #8747483 - Flags: review?(cmanchester) → review+
Comment on attachment 8747483 [details]
MozReview Request: Bug 1265486 - Use flat chrome format for mobile/android builds. r?chmanchester

Approval Request Comment
[Feature/regressing bug #]: 1256979
[User impact if declined]: Continued regressions in localized builds  
[Describe test coverage new/current, TreeHerder]: Tested manually to confirm the effect of bug 1256979 for Android builds was reverted by this patch.
[Risks and why]: Minimal, this is equivalent to backing out one piece of bug 1256979
[String/UUID change made/needed]: None
Attachment #8747483 - Flags: approval-mozilla-aurora?
Comment on attachment 8747483 [details]
MozReview Request: Bug 1265486 - Use flat chrome format for mobile/android builds. r?chmanchester

Needed for mixed locale issue, blocking aurora release.
Please uplift
Attachment #8747483 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/13a690e057e7
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
Kevin can you verify the fix and let me know when we can then enable aurora updates?  (or let me know who can/should do that)
Flags: needinfo?(kbrosnan)
I am attempting to reproduce. I've not had a ton of luck with this one. People whom have filed bugs on this does the current nightly 2016-05-02 solve the problem?
I'm looking at the strings in omni.ja of https://archive.mozilla.org/pub/mobile/nightly/latest-mozilla-central-android-api-15/fennec-49.0a1.multi.android-arm.apk

I see some English strings (and not full Chinese) at the bottom of dom/chrome/plugins.properties for nb-NO and pt-BR, added by compare-locales, so I think we should be good.
OK great. I will consider this signoff on aurora.
Flags: needinfo?(kbrosnan)
Updated on my phone and Chinese is not there anymore. Works.
Product: Firefox for Android → Firefox Build System
Target Milestone: Firefox 49 → mozilla49
You need to log in before you can comment on or make changes to this bug.