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

VERIFIED FIXED in Firefox 21

Status

defect
--
blocker
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: marcia, Assigned: vingtetun)

Tracking

({unagi})

unspecified
B2G C4 (2jan on)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 fixed)

Details

(Whiteboard: [triaged:1/15])

Attachments

(4 attachments)

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.
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.
Was there a reboot of the phone?
Assignee: nobody → kaze
blocking-b2g: tef? → tef+
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?
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
For the last few days I have been running the build in Portuguese and I did not start seeing this until today's build.
FWIW - tried out French and Spanish versions. UI doesn't switch back to English when reproducing same steps
Whiteboard: [triaged:1/15]
This is happening on today's build as well, with a fresh flash.
Duplicate of this bug: 833417
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).
(happened in today's build, after a fresh flash)
Summary: [settings] UI switched back to English from Portuguese with no user intervention → [settings] UI is in English instead of Portuguese after flashed and Pt-BR is set in FTE
Does the UI revert back to English in HTML (eg. in most of the content) or mostly in notification messages, warnings etc.?
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.
yeah, so it seems that the translation of HTML stays, but dynamically fetched strings (from JS) are coming in English. Trying to reproduce.
I’m afraid this bug can't be reproduced on the master branch. :-(
There might be an error on the releng side. Staś?
Flags: needinfo?(stas)
Summary: [settings] UI is in English instead of Portuguese after flashed and Pt-BR is set in FTE → [settings] Homescreen is in English instead of Portuguese after flashed and Pt-BR is set in FTE
Component: Gaia::Settings → Gaia::Homescreen
Summary: [settings] Homescreen is in English instead of Portuguese after flashed and Pt-BR is set in FTE → Homescreen is in English instead of Portuguese after flashed and Pt-BR is set in FTE
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…
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.
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 :/
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.
Yeah I've only experienced it in Portuguese.
This only happens with that language
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
nhirata probably just found the trick: this bug happens when building with |make production|.
Component: Gaia::Homescreen → Gaia::Settings
Component: Gaia::Settings → Gaia::Homescreen
When the homescreen starts, `navigator.language' is `en-US' instead of `pt-BR'. I still don't understand why.
so, does it happen right after you start, or after this update mentioned by Marcia in comment 1?
The homescreen is started after the en of the FTU, nothing to do with the OTA update.
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.
Attachment #706327 - Flags: review?(crdlc)
Attachment #706327 - Flags: review?(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.
Attachment #706327 - Flags: review?(alive) → review+
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?
Attachment #706327 - Flags: review?(crdlc)
Attachment #706327 - Flags: review?(alive)
Attachment #706327 - Flags: review+
Comment on attachment 706327 [details]
link to pull request

upps sorry, conflicts saving changes on bugzilla :)
Attachment #706327 - Flags: review?(alive) → review+
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.
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
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!
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?
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
QA Contact: mozillamarcia.knous
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 <fabien@cazenave.cc>
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 <fabien@cazenave.cc>
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.
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}]
Status: RESOLVED → REOPENED
Flags: needinfo?(stas)
Resolution: FIXED → ---
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'…
Stas, could you please advise if RelEng needs to change any environment vars ?
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.
(In reply to Nick Thomas [:nthomas] from comment #39)
> Stas, could you please advise if RelEng needs to change any environment vars
> ?
Flags: needinfo?(stas)
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.
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.
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.
(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...
(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.
(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.
Posted patch PatchSplinter Review
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.
Attachment #708415 - Flags: review?(fabrice)
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.
Attachment #708415 - Flags: review?(fabrice) → review+
Assignee: kaze → 21
(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
QA Contact: mozillamarcia.knous → lebedel.delphine
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
(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.
Flags: needinfo?(stas)
\o/

Verified fixed:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/13ef7b7a792c
Gaia   143fda9f0cfcbc7d03bf828cba090e05041f05df
BuildID 20130213070201
Version 18.0
Unagi
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.