Closed Bug 1039854 Opened 6 years ago Closed 5 years ago

[1.4] Dialing screen messages are not using translations when system language is set to anything other than English


(Firefox OS Graveyard :: Gaia::Build, defect)

Not set


(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 unaffected, b2g-v2.1 unaffected)

2.1 S3 (29aug)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected


(Reporter: nulti.korisnik, Assigned: yurenju)




(2 files)

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.
Component: Gaia → Gaia::Dialer
QAWanted to check if this is a build issue on the reporter or if it's a real 1.4 issue.
Keywords: qawanted
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?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
[Blocking Requested - why for this release]: Untranslated text on 1.4.
blocking-b2g: --- → 1.4?
Ever confirmed: true
Duplicate of this bug: 1056614
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.
Flags: needinfo?(yurenju.mozilla)
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:

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/
@import url(../../communications/contacts/locales/
@import url(../../communications/dialer/locales/

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(
@import url(../../dialer/locales/

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.
Flags: needinfo?(yurenju.mozilla)
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/
/home/pehrsons/td-temps/B2G-td/gaia/apps/communications/dialer/locales/ could not be found.

### returning (in LOCALE_BASEDIR): /home/pehrsons/td-temps/B2G-td/gaia-l10n/bn-BD/apps/callscreen/ions/contacts/
/home/pehrsons/td-temps/B2G-td/gaia/apps/communications/contacts/locales/ could not be found.

### returning (in LOCALE_BASEDIR): /home/pehrsons/td-temps/B2G-td/gaia-l10n/bn-BD/apps/callscreen/ions/dialer/
/home/pehrsons/td-temps/B2G-td/gaia/apps/communications/dialer/locales/ 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.
Flags: needinfo?(yurenju.mozilla)
Flags: needinfo?(etienne)
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.
Flags: needinfo?(pehrsons)
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.
Attachment #8477992 - Flags: review?(timdream)
Attachment #8477992 - Flags: review?(poirot.alex)
Attachment #8477992 - Flags: review?(gduan)
Attachment #8477992 - Flags: review?(21)
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.
Flags: needinfo?(pehrsons)
Attachment #8477992 - Flags: review?(timdream) → review+
Attachment #8477992 - Flags: review?(poirot.alex)
Attachment #8477992 - Flags: review?(gduan)
Attachment #8477992 - Flags: review?(21)
retrigger Gij test since it's red.
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.
Closed: 5 years ago
Resolution: --- → FIXED
bug 1057924 is filed for master branch.
Target Milestone: --- → 2.1 S3 (29aug)
You need to log in before you can comment on or make changes to this bug.