830782 - Homescreen is in English instead of Portuguese after flashed and Pt-BR is set in FTE

Status: VERIFIED FIXED

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

Description

[Marcia Knous [:marcia]]

Attachment: Screenshot of issue in Portuguese

unagi, running that latest nightly build 20130114 

Gaia: 45a3196a5517
Gecko: f2460bf17811

STR:
1. Flash the latest build and go through first run into Portuguese - confirm the language shows in all the usual places
2. Continue smoketesting
3. At some point I get a prompt to update Maps and Marketplace for a second time and I dismiss it - See Bug 830775.
4. UI reverts back to English everywhere, but in the settings app my language is set to Portuguese.

Attached you can see the moment that it happened, which is right after the second update prompt for Maps/Marketplace. Notice in the screenshot that some of the UI is in English, but the rest is in Portuguese. Following that I am in borked state with a half English-half Portuguese UI.

It appears as if all of the homescreen icons lose their translation, but in Settings it looks as if Portuguese is still shown.

This is quite similar to what Andrew saw in Bug 828260 - note that in his case system update was involved as well.

I have attached a logcat next with the hope it may shed some light on what happened.

Comment 1

[Marcia Knous [:marcia]]

Attachment: Logcat while testing

Comment 2

[Marcia Knous [:marcia]]

Just to clarify during this scenario there was no language switch in Settings - this was an out of the box fresh flash with Portuguese.

Also in moving around, it seems the homescreen date/time is now switching between English and Portuguese.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Was there a reboot of the phone?

Comment 4

[Marcia Knous [:marcia]]

Phone was never rebooted and I have the phone now in the same state.

(In reply to Naoki Hirata :nhirata from comment #3)
> Was there a reboot of the phone?

Comment 5

[Marcia Knous [:marcia]]

I just repeated the same steps with the build that just came out - using

Gaia: 688c601f18f2
Gecko: 67503cae6a5a

STR:
1. Fresh flash - build from pvt directory
2. Set language to Portuguese during first run
3. Connect to home wifi network
4. When I get to the homescreen:

*all the app icons on the homescreen are in English instead of Portuguese
*System update in notification tray is in English
*the date/time on the homescreen is in English
*e.me says "Loading" instead of Portuguese translation
*Individual apps including Settings when selected seem to be in Portuguese although I have not gone through all of them

Comment 6

[Marcia Knous [:marcia]]

For the last few days I have been running the build in Portuguese and I did not start seeing this until today's build.

Comment 7

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

FWIW - tried out French and Spanish versions. UI doesn't switch back to English when reproducing same steps

Comment 8

[Marcia Knous [:marcia]]

This is happening on today's build as well, with a fresh flash.

Comment 10

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

Language in UI has also been seen to switch back from English to Portuguese again, just randomly.

So once the Portuguese UI had switched back to English as described by Marcia in this bug, it just switched back to a Portuguese UI (at it should normally appear).

Comment 11

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

(happened in today's build, after a fresh flash)

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

reboot will fix the issue.

Comment 13

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

Does the UI revert back to English in HTML (eg. in most of the content) or mostly in notification messages, warnings etc.?

Comment 14

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

It reverts back to English for all the app names, for the date and on the homescreen (when unlocked - it's still in Portuguese when phone is locked), for all the ev.me, and for notifications, etc. 
But when you enter the apps, the content inside still appears translated.

Comment 15

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

yeah, so it seems that the translation of HTML stays, but dynamically fetched strings (from JS) are coming in English. Trying to reproduce.

Comment 16

[Fabien Cazenave [:kaze]]

I’m afraid this bug can't be reproduced on the master branch. :-(
There might be an error on the releng side. Staś?

Comment 17

[Fabien Cazenave [:kaze]]

Here’s the build log: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/latest/logs/log_info.log

On the master branch, we set these four environment variables:

  LOCALES_FILE=/[…]/gaia/locales/languages_basecamp.json
  LOCALE_BASEDIR=/[…]/gaia/locales
  GAIA_LOCALES_PATH=/[…]/gaia/locales
  GAIA_DEFAULT_LOCALE=en-US

but in this log I can only see these two environment variables:

  LOCALES_FILE=/[…]/gaia/locales/languages_dev.json
  LOCALE_BASEDIR=/builds/slave/b2g-m-b2g18-unagi-ntly/build/gaia-l10n

Still looking…

Comment 18

[Fabien Cazenave [:kaze]]

Well, even without the two missing environment variables I still can't reproduce this bug on Gaia master + Gecko b2g18. I don’t know what’s going on here.

Comment 19

[Etienne Segonzac (:etienne)]

FWIW I can't reproduce it (while selecting French during FTU, don't have brazilian).
I'm afraid this might be a multi-local-build-only issue :/

Comment 20

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

I also cannot reproduce it with French, but delphine said in comment 7 that it she can neither. So it may be reproducible only in Portugese.

Comment 21

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

Yeah I've only experienced it in Portuguese.
This only happens with that language

Comment 22

[Fabien Cazenave [:kaze]]

OK, I finally can reproduce this bug:
 • on the releng build [1], I can see this bug wit pt-BR only (all other locales work fine)
 • on Gaia master (+Gecko b2g18) with the “multilocale” build, all locales work fine (including pt-BR).

[1] https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/latest/unagi.zip

Comment 23

[Fabien Cazenave [:kaze]]

nhirata probably just found the trick: this bug happens when building with |make production|.

Comment 24

[Fabien Cazenave [:kaze]]

When the homescreen starts, `navigator.language' is `en-US' instead of `pt-BR'. I still don't understand why.

Comment 25

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

so, does it happen right after you start, or after this update mentioned by Marcia in comment 1?

Comment 26

[Fabien Cazenave [:kaze]]

The homescreen is started after the en of the FTU, nothing to do with the OTA update.

Comment 27

[Fabien Cazenave [:kaze]]

Attachment: link to pull request

https://github.com/mozilla-b2g/gaia/pull/7799

A stricter l10n initialization seems to fix this bug — at least for the one I’ve been able to reproduce. I’ve applied this new l10n-init method to the Homescreen and Settings app.

Pinging Cristian and Alive for the Homescreen and Settings parts, respectively.

Comment 28

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 706327 [details]
link to pull request

Looks like simple string replace and *many* lint fix, r=me.
I don't test it manually though.

Comment 29

[Cristian Rodriguez (:crdlc)]

Comment on attachment 706327 [details]
link to pull request

For me all changes on homescreen are OK. Most of them are many lint fixes except the new ready event that is perfect. Only one comment, is not better onready?

Comment 30

[Cristian Rodriguez (:crdlc)]

Comment on attachment 706327 [details]
link to pull request

upps sorry, conflicts saving changes on bugzilla :)

Comment 31

[Fabien Cazenave [:kaze]]

Thanks for your reviews, and sorry for the noise created by the linter fixes.

(In reply to crdlc from comment #29)
> Only one comment, is not better onready?

I thought of it but I would expect `onready' to be used like this:

  navigator.mozL10n.onready = function() { … };

whereas the idea here is to add an event listener. I looked at how other libraries do that, and I thought the jQuery-like `ready' would be OK:

  navigator.mozL10n.ready(function() { … });

I guess this would be a question for the webAPI team.

Comment 32

[Cristian Rodriguez (:crdlc)]

I agree with you:

navigator.mozL10n.onready = function() { … };

it is better ready than onready although maybe other alternative could be:

navigator.mozL10n.addEventListener('ready', function() { … });

thanks for your explanation

Comment 33

[Fabien Cazenave [:kaze]]

https://github.com/mozilla-b2g/gaia/commit/cbff8d447d357588c2e411c8120a59eb221a75cf

I’ll see if I can come up with a fake `addEventListener' in a follow-up. Thanks Cristian!

Comment 34

[Fabien Cazenave [:kaze]]

Marking as FIXED but requesting some QA love on this one. Marcia, Naoki, would you please double-check that this patch has fixed this bug?

Comment 35

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted to v1-train:
https://github.com/mozilla-b2g/gaia/commit/363151789b2636b7c0584aceaf2cc0b4d0435025

Uplifted to v1.0.0:
https://github.com/mozilla-b2g/gaia/commit/c47396cc278918acc1798b513cab9dc21d0f83f5

Comment 36

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Oddly, I can still repro this with my own built master gaia: 
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/32c2cc3e19ff
Gaia   4b42b089bf9e3fbc841062ceb61fac742f4aec3b
BuildID 20130124140859
Version 18.0

Looking at the gitlog, I do have the changeset :
commit cbff8d447d357588c2e411c8120a59eb221a75cf
Merge: 5df0c69 d7db6c0
Author: Fabien Cazenave <[e-mail]>
Date:   Fri Jan 25 04:25:08 2013 -0800

    Merge pull request #7799 from fabi1cazenave/l10n-homescreen
    
    Bug 830782 - better l10n initialization, r=alive, r=crdlc

commit d7db6c00c10e029ef716749d4612a1df9d90eaad
Author: Fabien Cazenave <[e-mail]>
Date:   Fri Jan 25 13:23:34 2013 +0100

    Bug 830782 - better l10n initialization (homescreen + settings), r=alive, r=


The main thing I came to realize is... I never set the path parameters as Fabien had mentioned to me in berlin work week... and that he mentioned in Comment 17.

Comment 37

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Meh.  I was incorrect; made sure that the settings were there, and it still occurs.
The only other thing I can think of instead of initialization of the homescreen is possibly some wierd translation issue that borks it initially? or something not quite defined:

01-25 10:42:50.977: E/GeckoConsole(693): [JavaScript Warning: "Expected pseudo-element but found '-moz-placeholder'.  Ruleset ignored due to bad selector." {file: "app://communications.gaiamobile.org/shared/style/input_areas.css" line: 39}]
01-25 10:42:50.997: E/GeckoConsole(693): [JavaScript Warning: "Unknown property 'user-select'.  Declaration dropped." {file: "app://communications.gaiamobile.org/ftu/css/style.css" line: 10}]


01-25 10:44:27.807: E/GeckoConsole(772): [JavaScript Warning: "Propriedade desconhecida -moz-align-self.  Declara��o ignorada." {file: "resource://gre-resources/ua.css" line: 44}]

Comment 38

[Fabien Cazenave [:kaze]]

Now I can’t reproduce this bug any more… I wonder what’s so different in the releng build process.

(In reply to Naoki Hirata :nhirata from comment #36)
> The main thing I came to realize is... I never set the path parameters as
> Fabien had mentioned to me in berlin work week... and that he mentioned in
> Comment 17.

Yes, it seems like that neither GAIA_LOCALES_PATH nor GAIA_DEFAULT_LOCALE are set by the releng build system. The former should be replaced by LOCALE_BASEDIR anyway, and the latter should default to `en-US'…

Comment 39

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

Stas, could you please advise if RelEng needs to change any environment vars ?

Comment 40

[Fabien Cazenave [:kaze]]

Un-assigning. I can’t reproduce this bug any more with my current build system. Either it’s a releng issue or I’m too tired to be useful.

Comment 41

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to Nick Thomas [:nthomas] from comment #39)
> Stas, could you please advise if RelEng needs to change any environment vars
> ?

Comment 42

[Aki Sasaki (not active)]

Summing up conversation from IRC:

* It looks like :kaze's been testing against master and the log in comment 17 points at gaia-v1-train.  We should see if it's still reproducible on that branch.
https://github.com/mozilla-b2g/gaia/compare/master...v1-train has the differences between branches.

* Releng can set the env vars in comment 38 in the build if helpful.

Comment 43

[Lukas Blakk [:lsblakk] use ?needinfo]

updating b2g18-v1.0.0 flag based on landing on comment 35 and the appearance that issues remaining are infrastructure and not the fix itself.

Comment 44

[Aki Sasaki (not active)]

I suspect that it's fixed on non-1.0.x and broken on 1.0.0 and v1-train, but that's only a suspicion.

Comment 45

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Aki Sasaki [:aki] from comment #44)
> I suspect that it's fixed on non-1.0.x and broken on 1.0.0 and v1-train, but
> that's only a suspicion.

I suspect that this bug is related to the multilocale Gecko build actually. The steps to reproduce I use are:
 1.Use the unagi.zip build from https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/latest/unagi.zip
 2. ./flash.sh the device and wait for the first run experience to appears
 3. On the first run page wait 5 seconds for the prelaunch process to be launched. You can verify that it has been launched with |adb shell b2g-ps| and see if the is a 'Preallocated' line
 4. Once the process has been launched change the locale to pt-BR
 5. Go to the homescreen and it is in English.

This works 100% of the time for me if I follow those steps.


Now the the reasons why I suspect this is a multilocale build issue. 
 - Using a custom mozilla-b2g18 build that is non-multilocale makes it impossible to reproduce the bug
 - Changing the content of shared/resources/languages-dev.json in Gaia to replace 'es' by 'es-ES' I can reproduce the issue with Spanish as well
 - Changing the content of shared/resources/languages-dev.json in Gaia to replace 'pt-BR' by 'pt' the issue goes away
 - Changing the content of shared/resources/languages-dev.json in Gaia to replace 'fr' by 'fr-FR' has not effect.

There is file in Gecko/b2g/locales/all-locales that contains my 2 suspects: es-ES and pt-BR.

I'm trying to compile a multilocale Gecko build to see if I can reproduce in this case...

Comment 46

[Aki Sasaki (not active)]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #45)
> There is file in Gecko/b2g/locales/all-locales that contains my 2 suspects:
> es-ES and pt-BR.

Ok.

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Building?redirectlocale=en-US&redirectslug=Mozilla%2FFirefox_OS%2FBuilding_Boot_to_Gecko#Building_multilocale

has the multilocale instructions.

Comment 47

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Aki Sasaki [:aki] from comment #46)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #45)
> > There is file in Gecko/b2g/locales/all-locales that contains my 2 suspects:
> > es-ES and pt-BR.
> 
> Ok.
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/
> Building?redirectlocale=en-
> US&redirectslug=Mozilla%2FFirefox_OS%2FBuilding_Boot_to_Gecko#Building_multil
> ocale
> 
> has the multilocale instructions.

I have been able to make a multilocale build - thanks for the instructions that was helpful.  Making such a build make the issue appears because the way the intl.accept_languages preference change differs in those builds (for good).

I have a one liner that I need to confirm that should not alter the way it works (which is something that is expected by l10n I believe) but force the value to be reflected on the homescreen app.

Comment 48

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

Always having a user value on intl.accept_languages will force it to be on the child even if the value has been change after the prelaunch process has been created.

Comment 49

[[:fabrice] Fabrice Desré]

Comment on attachment 708415 [details] [diff] [review]
Patch

Review of attachment 708415 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comment fixed.

::: b2g/chrome/content/settings.js
@@ +114,5 @@
>                                            Ci.nsIPrefLocalizedString).data;
>    } catch(e) {}
>  
> +  // Bug 830782 - Homescreen is in English instead of selected locale after
> +  // the first run experience.

Instead of quoting the bug, explain what you're doing there.

Comment 50

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://hg.mozilla.org/mozilla-central/rev/cbeab7da0e3a
https://hg.mozilla.org/releases/mozilla-b2g18/rev/e65d8eece1cc

Does this patch needs to land on something else before beeing closed?

Comment 52

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #50)
> https://hg.mozilla.org/mozilla-central/rev/cbeab7da0e3a
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/e65d8eece1cc
> 
> Does this patch needs to land on something else before beeing closed?

If this fix is to ship in v1.0.0, it should also land in https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0

Comment 53

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

It does not seems fixed on v1.0.0 then so I changed the status back from what Marcia put (which I believe is a mistake or is it me?).
I don't have a local branch handy so I will let someone else merge it on v1.0.0. Thanks.

Comment 54

[Staś Małolepszy :stas]

(In reply to John O'Duinn [:joduinn] from comment #41)
> (In reply to Nick Thomas [:nthomas] from comment #39)
> > Stas, could you please advise if RelEng needs to change any environment vars
> > ?

We should be setting:

  LOCALES_FILE=/[…]/gaia/locales/languages_basecamp.json
  LOCALE_BASEDIR=/[…]/gaia/locales

For better perfomance, we can set

  GAIA_DEFAULT_LOCALE=en-US

It doesn't matter if we set GAIA_LOCALES_PATH=/[…]/gaia/locales - it's only used in DEBUG.  The name is unfortunate.

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0/rev/f02716af8217

Comment 56

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

\o/

Verified fixed:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/13ef7b7a792c
Gaia   143fda9f0cfcbc7d03bf828cba090e05041f05df
BuildID 20130213070201
Version 18.0
Unagi