Closed Bug 1039854 Opened 6 years ago Closed 5 years ago
.4] Dialing screen messages are not using translations when system language is set to anything other than English
797 bytes, patch
|Details | Diff | Splinter Review|
46 bytes, text/x-github-pull-request
|Details | Review|
User Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140605174243 Steps to reproduce: This is reporduced on v1.4 for keon (Gecko-d977c31 Gaia-393d729). Steps: - set device language to Serbian cyrillic ("Српски"); - open "Phone" app and call any number; - notice the untranslated strings in dialer ("Connecting", "Call Ended" etc.). This *was* translated before 2 weeks however something must gone wrong in the latest builds. Everything is translated already so it just needs to be applied. Actual results: Some strings were not translated. Expected results: Everything should be translated.
Summary: [1.4] Dialing screen and messages there are not translated in Serbian → [1.4] Dialing screen and messages there are not using Serbian translation when system language is set to Serbian
Summary: [1.4] Dialing screen and messages there are not using Serbian translation when system language is set to Serbian → [1.4] Dialing screen messages are not using translations when system language is set to anything other than English
I just tested this and it appears that this bug is present when you select any language other than English. I tried this with Serbian and Spanish for now.
QAWanted to check if this is a build issue on the reporter or if it's a real 1.4 issue.
This bug repro's on: Flame 1.4 Actual Results: Connecting and Call Ended messages are not translated in the Dialer. Repro Rate: 5/5 Environmental Variables: Device: Flame 1.4 BuildID: 20140818062816 Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae Gecko: 07d78d0f9bef Version: 30.0 (1.4) Firmware Version: v123 ------------------------------------------------ ------------------------------------------------ This bug does NOT repro on: Flame 2.1, Flame 2.0, Buri 2.1 Actual Result: Proper translations seen for Calling and Call Ended in the Dialer Repro Rate: 0/5 attempts Environmental Variables: Device: Flame Master BuildID: 20140819225026 Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8 Gecko: ffdd1a398105 Version: 34.0a1 (Master) Firmware Version: v123 ------------------------------------------------- Environmental Variables: Device: Flame 2.0 BuildID: 20140819175131 Gaia: 88db39a0826086024631049d83ae6aa397f0918d Gecko: 2092ac87eceb Version: 32.0 (2.0) Firmware Version: v123 --------------------------------------------------- Environmental Variables: Device: Buri Master BuildID: 20140818072913 Gaia: ba1992f2addc5a84afc2eab426f222a6bf2962ba Gecko: bf27e27c994d Version: 34.0a1 (Master) Firmware Version: v1.2device.cfg
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
[Blocking Requested - why for this release]: Untranslated text on 1.4.
Status: UNCONFIRMED → NEW
blocking-b2g: --- → 1.4?
Ever confirmed: true
In my testing, French is translated but not Spanish. Therefore I believe this is a build issue. But I have no idea who has expertise on our multilocale builds and can help on this.
I'd give a blank stare at Yuren.
The locales in apps/callscreen/locales/locales.ini seem to work (i.e., en-US, ar, fr, zh-TW), but not external ones. Yuren, could you have a look please? This is blocking release for Telenor.
Blocking this for regression and user impact.
blocking-b2g: 1.4? → 1.4+
checked sr-Cyrl.json have callEnded property in communications app. I'm finding a phone to reproduce it.
bisected and this is a regression came from bug 990003, so it's not a build system bug. regression commit: c4bfa26c5555f9ecbbbe9402a241794d726dfa57 Bug 990003 - Introducing a dedicated callscreen app for better performance Etienne, can you take a look?
Flags: needinfo?(yurenju.mozilla) → needinfo?(etienne)
Bug 990003 moved the callscreen from the dialer app to a dedicated app, and is now referencing the comms translations like so: $ cat apps/callscreen/locales/locales.ini @import url(../../communications/dialer/locales/dialer.en-US.properties) @import url(../../communications/contacts/locales/contacts.en-US.properties) @import url(../../communications/dialer/locales/shared.en-US.properties) (...) For the bn-BD repo, these properties files exist and contain the correct translations, but are not picked up for callscreen. However, the contacts app does the same kind of referencing: $ cat apps/communications/contacts/locales/locales.ini @import url(contacts.en-US.properties) @import url(../../dialer/locales/shared.en-US.properties) (...) And this works. The only difference between these two that I can see is that apps/communications/contacts/locales exist in the bn-BD repo, while apps/callscreen/... does not. This makes me believe that the underlying issue is a build issue although bug 990003 was the first to trigger it. It might be a simpler/smoother solution to fix the build issue than to back out bug 990003. Yuren, if you could have a look it would be immensely appreciated. We'd need this fixed tomorrow (monday) evening for our release or we will have to find a workaround.
I added a dump call in L10nManager:getPropertiesFile, to print the returned value. I now get the following output for callscreen. Looks like string magic gone wrong. ### returning (in LOCALE_BASEDIR): /home/pehrsons/td-temps/B2G-td/gaia-l10n/bn-BD/apps/callscreen/ions/dialer/dialer.properties /home/pehrsons/td-temps/B2G-td/gaia/apps/communications/dialer/locales/dialer.bn-BD.properties could not be found. ### returning (in LOCALE_BASEDIR): /home/pehrsons/td-temps/B2G-td/gaia-l10n/bn-BD/apps/callscreen/ions/contacts/contacts.properties /home/pehrsons/td-temps/B2G-td/gaia/apps/communications/contacts/locales/contacts.bn-BD.properties could not be found. ### returning (in LOCALE_BASEDIR): /home/pehrsons/td-temps/B2G-td/gaia-l10n/bn-BD/apps/callscreen/ions/dialer/shared.properties /home/pehrsons/td-temps/B2G-td/gaia/apps/communications/dialer/locales/shared.bn-BD.properties could not be found
because dialer is just a folder in communications app, but callscreen is an another app (or iframe), not in communications app, we didn't consider using l10n files from another app when we were implementing multilocale.js.
Assignee: nobody → yurenju.mozilla
Component: Gaia::Dialer → Gaia::Build
root cause is in removeLocale().
Thanks for taking it Yuren! I found that this patch fixes the issue for me. Feel free to use it if you want. I'll keep it as a workaround in case this bug isn't fixed on 1.4 in time for our release.
the patch looks fine, I also verify the result between previous and after applied the patch and looks good. :pehrsons, do you mean the patch will be used on your local branch and won't be landed to 1.4? I will also make a pull request for master if this bug exists on master, but it will not the top priority.
send pull request with :pehrsons's patch. ask 4 reviewers but I would land this pr if got one r+ since this is a critical bug.
If it lands on v1.4 before our release build starts, we'll merge it in. Otherwise I'll merge this to our private tree. Our deadline is the evening of Aug 26th (Tuesday), and we'll start building on the morning of the 27th.
Attachment #8477992 - Flags: review?(timdream) → review+
retrigger Gij test since it's red.
merged for 1.4 branch. https://github.com/mozilla-b2g/gaia/commit/3c092847dac7407b60319f853f59904ee1fc731b
I will file another bug for master since we don't have the same issue on 2.0 and master, but we still can add the capacity to access l10n files from another app. so mark as resolved.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
bug 1057924 is filed for master branch.
You need to log in before you can comment on or make changes to this bug.