Closed
Bug 1265486
Opened 8 years ago
Closed 8 years ago
Mixed localization in 48
Categories
(Firefox Build System :: Android Studio and Gradle Integration, defect)
Firefox Build System
Android Studio and Gradle Integration
Tracking
(firefox47 unaffected, firefox48blocking fixed, firefox49 fixed)
RESOLVED
FIXED
mozilla49
Tracking | Status | |
---|---|---|
firefox47 | --- | unaffected |
firefox48 | blocking | fixed |
firefox49 | --- | fixed |
People
(Reporter: mstanke, Assigned: glandium)
References
Details
Attachments
(3 files)
202.19 KB,
image/jpeg
|
Details | |
248.16 KB,
image/jpeg
|
Details | |
58 bytes,
text/x-review-board-request
|
chmanchester
:
review+
lizzard
:
approval-mozilla-aurora+
|
Details |
I just installed nightly on my phone and noticed Chinese symbols together with Czech.
Reporter | ||
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
flod, any idea what could be going on here?
Flags: needinfo?(francesco.lodolo)
Reporter | ||
Comment 3•8 years ago
|
||
Just an update, the strings seems to match zh-TW translations.
Comment 4•8 years ago
|
||
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)
Reporter | ||
Comment 5•8 years ago
|
||
I have unzipped the Nightly .apk and contained omni.ja and the zh-TW strings are there in the "cs" folder.
Comment 6•8 years ago
|
||
(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?
Comment 7•8 years ago
|
||
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/
Reporter | ||
Comment 8•8 years ago
|
||
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.
Comment 9•8 years ago
|
||
(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.
Comment 10•8 years ago
|
||
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)
Comment 11•8 years ago
|
||
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
Reporter | ||
Comment 13•8 years ago
|
||
(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?).
Comment 14•8 years ago
|
||
It'd be really helpful to get a regression range here.
Keywords: regressionwindow-wanted
Comment 15•8 years ago
|
||
I see one in https://bugzilla.mozilla.org/show_bug.cgi?id=1265269#c1 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=91115264629dfaacf2d60d52a3eff89c18c5af0d&tochange=afd82f887093e5e9e4015115ca5795ec82a6f732 There seems to be a lot of build stuff, maybe bug 1264527?
Comment 16•8 years ago
|
||
(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)
Comment 17•8 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 19•8 years ago
|
||
[Tracking Requested - why for this release]: This should be fixed before 48 Aurora updates are enabled.
Assignee | ||
Comment 20•8 years ago
|
||
(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)
Comment 21•8 years ago
|
||
Tracking as it is critical
Updated•8 years ago
|
Summary: Mixed localization in nightly builds → Mixed localization in 48
Comment 22•8 years ago
|
||
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
Assignee | ||
Comment 23•8 years ago
|
||
(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 | ||
Comment 24•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/49909/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/49909/
Attachment #8747483 -
Flags: review?(cmanchester)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → mh+mozilla
Comment 25•8 years ago
|
||
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 27•8 years ago
|
||
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 28•8 years ago
|
||
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+
Comment 29•8 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/3f5062c662dab3cda0c88b2d5b2971c729e2e1c3
Comment 30•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/13a690e057e7
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
Comment 31•8 years ago
|
||
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)
Comment 32•8 years ago
|
||
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?
Comment 33•8 years ago
|
||
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.
Comment 34•8 years ago
|
||
OK great. I will consider this signoff on aurora.
Updated•8 years ago
|
Flags: needinfo?(kbrosnan)
Reporter | ||
Comment 35•8 years ago
|
||
Updated on my phone and Chinese is not there anymore. Works.
Updated•5 years ago
|
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.
Description
•