1065175 - Find My Device text appears in English

Status: VERIFIED DUPLICATE of bug 1022767

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

Description

[Marcia Knous [:marcia]]

Attachment: 2014-09-09-19-32-37.png

Sorry, not sure if this should be FMD bug or Settings....

Flame, while running:

Gaia   4acd3e69b263b54f4111e3586ff4ade84b49b4da
SourceStamp 6b8da5940f74
BuildID 20140909040219
Version 35.0a1
base: v123

STR:
1. Settings-> Find my Device
2. Observe the attached screenshot

Comment 1

[Delphine Lebédel [:delphine - Use needinfo]]

This actually affects all locales - not just Italian
Talking with Theo, it seems that all strings in settings.device.properties are affected.
It won't happen it you FOTA or flash your own gaia, but our builds are affected

Comment 2

[Francesco Lodolo [:flod]]

I can confirm: on my own Gaia everything is localized. I know Jared was looking for info about pvt builds yesterday, it this related?

Comment 3

[Francesco Lodolo [:flod]]

If I look into application.zip for settings, I see all the device specific strings in English.
https://hg.mozilla.org/gaia-l10n/en-US/file/daa9f72a63b2/apps/settings/device_type

So it might be a build issue (see also bug 1048711). Switching NI since Jared is definitely not guilty :-)

Comment 4

[Sherman Chen [:chens] (inactive)]

I can confirm this situation on flash gaia from pvt, but not happen if build and flash gaia yourself.
And this is the command to build and flash gaia: |DEVICE_DEBUG=1 GAIA_DPPX=1.5 NOFTU=1 make reset-gaia|
There could be something happened in pvt build but not sure who should ask for.

Device info (from pvt)
Gaia      4acd3e69b263b54f4111e3586ff4ade84b49b4da
Gecko     https://hg.mozilla.org/mozilla-central/rev/587f6c9b5a80
BuildID   20140908160203
Version   35.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

Device info (self-build)
Gaia      79ac97ca5d1bf2aff8bdd8c653ddac97df97332c
Gecko     https://hg.mozilla.org/mozilla-central/rev/587f6c9b5a80
BuildID   20140908160203
Version   35.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

Comment 5

[Francesco Lodolo [:flod]]

I think this is the script used for pvt builds (based on bug 1043662 comment 45)
http://hg.mozilla.org/build/mozharness/file/tip/scripts/b2g_build.py

Comment 6

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 7

[Brian Huang [:brianhuang][:brhuang]]

(In reply to Francesco Lodolo [:flod] from comment #5)
> I think this is the script used for pvt builds (based on bug 1043662 comment
> 45)
> http://hg.mozilla.org/build/mozharness/file/tip/scripts/b2g_build.py

Hi Askeing,

Could you follow up this about script issue?

Comment 8

[Askeing Yen[:askeing][:fyen]]

I'm not sure what's the different between the pvt builds and self builds.
We need RelEng's help.

Comment 9

[Askeing Yen[:askeing][:fyen]]

(In reply to Marcia Knous [:marcia - use needinfo] from comment #0)
> Created attachment 8486847 [details]
> 2014-09-09-19-32-37.png
> 
> Sorry, not sure if this should be FMD bug or Settings....
> 
> Flame, while running:
> 
> Gaia   4acd3e69b263b54f4111e3586ff4ade84b49b4da
> SourceStamp 6b8da5940f74
> BuildID 20140909040219
> Version 35.0a1
> base: v123
> 
> STR:
> 1. Settings-> Find my Device
> 2. Observe the attached screenshot
The screenshot show us:
https://hg.mozilla.org/gaia-l10n/it/file/c2ce84898772/apps/settings/settings.properties works
https://hg.mozilla.org/gaia-l10n/it/file/c2ce84898772/apps/settings/device_type/phone/settings.device.properties doesn't work

Comment 10

[Cody Roesch [:croesch]]

This bug repro's on Flame KK builds: Flame 2.2, Flame 2.1 and OpenC 2.2

Actual Results: All or some of the Find My Device section in settings appears in English when device is set to other languages than english.

Repro Rate: 6/6

Device: Flame 2.2
BuildID: 20140912061053
Gaia: b72909030e214175144342f7e5df7e88a2b52fd4
Gecko: 59d4326311e0
Version: 35.0a1 (2.2)
Firmware: v165
------------------------------------------------
Device: Flame 2.1
BuildID: 20140912081053
Gaia: 59e5c2467b7b8219ed194a0d0a94c6ed59af95be
Gecko: b09d2857b74e
Version: 34.0a2 (2.1)
Firmware: v165
------------------------------------------------
Device: Open_C 2.2
BuildID: 20140912061053
Gaia: b72909030e214175144342f7e5df7e88a2b52fd4
Gecko: 59d4326311e0
Version: 35.0a1 (2.2)
Firmware: P821A10v1.0.0B06_LOG_DL

------------------------------------------------
------------------------------------------------

This bug does NOT repro on Flame kk build: Flame 2.0

Actual Result: Find my device section in settings is translated across languages.

Repro Rate: 0/2 attempts

Environmental Variables:
Device: Flame 2.0
BuildID: 20140911220254
Gaia: 91dd0e596aa7c124dd968e1474b23e7992dc35a1
Gecko: a66168598533
Version: 32.0 (2.0) 
Firmware Version: v165

Comment 11

[Joshua Mitchell (Inactive)]

triage - just a broken string / translation issue - not nomming, so not adding regression window wanted

Comment 12

[Jason Smith [:jsmith]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #11)
> triage - just a broken string / translation issue - not nomming, so not
> adding regression window wanted

A broken translation due to a Gaia/Gecko problem is definitely going to be a blocker. Our target markets are not English-based, so untranslated strings presents a broken experience to our users.

Comment 13

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I'm seeing results that are inconsistent with the comments in this bug.  When I shallow flash to the latest master build, I do not see every language with that string being untranslated.  I grabbed a sample of languages below where the string in question is and isn't translated all checked within a single flash.  Some languages have other untranslated strings on the page (The title or the button were untranslated at time), but there was no string that was untranslated all the time.

NI? Jason and Fransisco to see if this changes anything about the work needed on this bug from a QA standpoint.

Environmental Variables:
Device: Flame 2.2
BuildID: 20140912061053
Gaia: b72909030e214175144342f7e5df7e88a2b52fd4
Gecko: 59d4326311e0
Version: 35.0a1 (2.2) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

String not translated:
French
Italian
Japanese

String is translated:
Greek
Spanish
Hungarian
German

Comment 14

[Jason Smith [:jsmith]]

Ok - Holding off the nomination then. Let's get flod's input here if this is a bug with the locales in question here rather than a unlocalizable string.

Comment 15

[Théo Chevalier]

ok, here's my understanding:

Let's take a locale where strings in FMD are displayed (Spanish) and one where they're not (French).

In French, the strings in settings/devices_types/*/settings.device.properties have been localized and are the one that should be picked up by the App, but it's not happening with pvt builds.

In Spanish, the strings in settings/devices_types/*/settings.device.properties have NOT been localized yet.
The translations we are seeing are obsoletes strings still in the main settings.properties file: https://hg.mozilla.org/gaia-l10n/es/file/0baf06600fd8/apps/settings/settings.properties#l724

So, in pvt builds only, the Settings App is trying to pick up the device specific strings in settings.properties instead of settings.device.properties, and that, I have no idea why :)
And in French, we removed those strings from settings.properties, of course, so that explains the differences between locales.

Other builds (GP builds for instance) are picking those translations from the right place: settings.device.properties

Not sure my comment is clear, thought...

Comment 16

[Jason Smith [:jsmith]]

Are you arguing this is a builds issue then?

Comment 17

[Théo Chevalier]

(In reply to Jason Smith [:jsmith] from comment #16)
> Are you arguing this is a builds issue then?

Can't tell for sure it's on RelEng side, but it seems related, yes:

-Can't repro by flashing a custom gaia on top of a pvt build
-Can't repro on GP builds

I have no idea if partner builds might be affected by this issue.

Comment 18

[Francesco Lodolo [:flod]]

Théo explained perfectly the situation in comment 15: you're seeing localized strings for locales with out-of-date localizations. As soon as they update their translation for 2.1, you'll get English text there too.

I think it's a build issue: it doesn't reproduce when flashing my own Gaia on the device, it definitely reproduces on our pvt builds, I have no idea how to test partners builds to verify if they're affected as well.

Comment 19

[Jason Smith [:jsmith]]

Nick - Could someone from rel eng look into why this is failing in pvtbuilds only?

Comment 20

[Nick Thomas [:nthomas] (UTC+12)]

If this happening on 2.0 and not higher then I suspect there is something in the build system, which is not something RelEng has much experience with. We are doing multilocale builds, is that true of these self builds too ?

As comment #5 points out, our script is at
  http://hg.mozilla.org/build/mozharness/file/production/scripts/b2g_build.py

For m-c/master non-eng we call it like this:
  scripts/b2g_build.py --target flame-kk --config b2g/releng-private-updates.py --gaia-languages-file locales/languages_all.json --gecko-languages-file gecko/b2g/locales/all-locales --config balrog/production.py

These configuration files also feed into the script
 http://hg.mozilla.org/build/mozharness/file/production/configs/b2g/releng-private-updates.py
 https://github.com/mozilla-b2g/gaia/tree/master/locales
 http://hg.mozilla.org/mozilla-central/file/default/b2g/locales/all-locales
 https://hg.mozilla.org/mozilla-central/file/default/b2g/config/flame-kk/config.json

The last has details on where the l10n source comes from. Some of the configs are in different locations for other branches (eg 2.1).

Comment 21

[Jason Smith [:jsmith]]

[Blocking Requested - why for this release]:

Based on comment 20 this sounds like it might be a Gaia::Build issue perhaps? If this happens in a production build setting, then our partner builds will hit this issue. comment 12 applies again.

Comment 22

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Nick Thomas [:nthomas] from comment #20)
> If this happening on 2.0 and not higher then I suspect there is something in
> the build system ....

Sorry, I meant not happening in 2.0, but is 2.1+ (comment #10). Comment #15 looks like a good lead.

Comment 23

[howie [:howie]]

Triage: regression, blocking.

Comment 24

[James Lal [:lightsofapollo]]

Taking a quick look...

Comment 25

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Central Regression Window:

Last working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140806134618
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: a31cd48facbf
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140806165814
Gaia: 079c5f85875b0f2eb341ca9fd375f1b905ed7157
Gecko: 16569cf5ffa5
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: 16569cf5ffa5

First broken gaia / Last working gekko - Issue DOES occur
Gaia: 079c5f85875b0f2eb341ca9fd375f1b905ed7157
Gecko: a31cd48facbf


Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/5e6ef81cb9e917657ce050f598229dfc83c58b8f...079c5f85875b0f2eb341ca9fd375f1b905ed7157


B2g-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140806141214
Gaia: 079c5f85875b0f2eb341ca9fd375f1b905ed7157
Gecko: 16569cf5ffa5
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First Broken 
Environmental Variables:
Device: Flame 2.1
BuildID: 20140806180316
Gaia: bea8355ea0c48de3a55c8cc59854f91cf2561b4a
Gecko: 4bf7a27abe2a
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 079c5f85875b0f2eb341ca9fd375f1b905ed7157
Gecko: 4bf7a27abe2a

First broken gaia / Last working gecko - Issue DOES occur

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/079c5f85875b0f2eb341ca9fd375f1b905ed7157...bea8355ea0c48de3a55c8cc59854f91cf2561b4a

Comment 26

[Joshua Mitchell (Inactive)]

not selecting any 'broken by' from the pushlogs as comment 20 and comment 21 are pointing to "Gaia::Build issues" and not a particular regression.

Comment 27

[Jason Smith [:jsmith]]

Can we double check the window here? I thought this would be a build regression, but the window points this being something else.

Comment 28

[Francesco Lodolo [:flod]]

It doesn't make sense. Separation of device specific strings landed on Gaia at the beginning of August
https://github.com/mozilla-b2g/gaia/commit/eae74908a7ab8493691b7fc6ec91d969821d9798

Comment 29

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Discussed with chens, this is a regression from bug 944604, we should properly use |isSubjectToDeviceType()| to copy correct file from l10n repository and having a integration test case will help to avoid regression for device type. so we can reproduce it by:

LOCALES_FILE=<path-to-l10n>/languages.json LOCALE_BASEDIR=<path-to-l10n> make 

|it| directory should be in <path-to-l10n> and you can see the english string in find my device on b2g-desktop.

re-assign to chens

Comment 30

[Sherman Chen [:chens] (inactive)]

Attachment: wip

Since bug 1022767 move device type detection to multilocale.js[1], it is redundant to do that in webapp-optimize.js and webapp-shared.js. Doing so will cause adding device type twice to l10n file and it's wrong.

This wip removes device type detection in those two js, but this still has some work to do. Observing the locales-obj output in build_stage directory, device type related strings still missing. And I'm guessing it could possibly relate to |getDictionary| in webapp-optimize.js[2], which may not retrieve device type strings properly. 

[1] https://github.com/mozilla-b2g/gaia/blob/02ca67948fe8efd9e07e6d60064b54d0acc29484/build/multilocale.js#L112-L118
[2] https://github.com/mozilla-b2g/gaia/blob/02ca67948fe8efd9e07e6d60064b54d0acc29484/build/webapp-optimize.js#L61

Comment 31

[Sherman Chen [:chens] (inactive)]

NI :gandalf and :flod to confirm my guessing, please correct me if I'm wrong.

Comment 32

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to Sherman Chen [:chens] from comment #30)
> Created attachment 8491559 [details] [review]
> wip
> 
> Since bug 1022767 move device type detection to multilocale.js[1], it is
> redundant to do that in webapp-optimize.js and webapp-shared.js. Doing so
> will cause adding device type twice to l10n file and it's wrong.

The problem is that currently multilocale is not launched at all if LOCALE_BASEDIR is not set. So we need this code in both places. (in the future I'd like to change it: bug 1068382)

In bug 1022767 I have a small patch that fixes the regression caused by the big patch. It's awaiting Yuren's review. It seems to me that it should fix this bug. Can you check it?

Comment 33

[Sherman Chen [:chens] (inactive)]

As comment 32, this bug should also have a fix in bug 1022767.

Comment 34

[Sherman Chen [:chens] (inactive)]

I'm closing this one since it's been fixed in bug 1022767

Comment 35

[Francesco Lodolo [:flod]]

I can confirm that the text is correctly localized now even using a pvt build
Gaia-Rev        c7ef0bf06ce1c98cbe68aa52e2ecd862acb23e9c
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/53f7f5b6d7bf
Build-ID        20140922040204
Version         35.0a1
Device-Name     flame