831228 - [l10n][es][Settings - Cellular & Data - Network Operator] Information below network operators when no automatic selection is selected are not translated

Status: RESOLVED FIXED

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

Description

[Carlos Martínez Toral [:carlosmartinez]]

Attachment: Network operator information shows up in english

Tested in unagi with Gecko-ec7aa64 Gaia-df38c1b.

STR:
1-Open Settings app
2-Go to cellular & data -> network operator
3-Switch off automatic selection

Expected result --> Every text in the screen is translated
Actual result --> Information below available network operators is in english

Comment 1

[xiaokang.chen]

Hi there,
You can check bug #863191, then you will found all the subhead of Settings' panal not translated every time.

Comment 2

[Carlos Martínez Toral [:carlosmartinez]]

Hi, ok thank you for the info, but... What´s the info you need from me?

Comment 3

[xiaokang.chen]

(In reply to Carlos Martínez Toral [:carlosmartinez] from comment #2)
> Hi, ok thank you for the info, but... What´s the info you need from me?

Thanks for your reply. I want to find someone who's in charge of this? Can you give me some advice?

Comment 4

[Fabien Cazenave [:kaze]]

I’m in charge of this (on PTO today, though). Feel free to “needinfo” me!

Comment 5

[Fabien Cazenave [:kaze]]

Attachment: link to pull request — proper fix

This fixes the root issue: the `localized' event may be sent before the document is not fully loaded. That should fix other similar bugs but it might have too much impact for being uplifted to v1-train…

Vivien, I’ll trust your opinion on this. If you don’t feel this patch is safe, a quick-and-dirty one is proposed below.

Comment 6

[Fabien Cazenave [:kaze]]

Attachment: link to pull request — quick and dirty fix

Here’s a quick and dirty but safe patch if the former one is too risky.

Comment 7

[Evelyn Hung]

Comment on attachment 748727 [details]
link to pull request — quick and dirty fix

r=me, I think it's not so bad. :p

Comment 8

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

Comment on attachment 748724 [details]
link to pull request — proper fix

This sounds good to me. Interactive seems like a workaround that has been added at some point.

Comment 9

[Fabien Cazenave [:kaze]]

Merged on master:
https://github.com/mozilla-b2g/gaia/commit/63272747789f0a9800aaa3abadca295855a02c9e

Comment 10

[Anthony Ricaud (:rik)]

I had to revert this commit as it broke the new l10n_test.js.

The error message is not obvious. This test timeouts because of this change.
1) [gallery] "before all" hook:
Error: timeout of 2000ms exceeded
at (anonymous) (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3680)

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

Comment 11

[Julien Wajsberg [:julienw]]

MDN says :
 "interactive" once it is finished parsing but still loading sub-resources

The point is to know when DOMContentLoaded is sent: after changing to "complete" ? to "interactive" ? somewhere between "interactive" and "complete" (worst case) ? To my understanding, DOMContentLoaded is sent just when "interactive" was set, that's why "interactive" was there at that time. That means that if we change this, we might not load the translation.

However, I've also read somewhere that in some browsers (namely IE9/10), it behaves strangely in iframes. So maybe we also have a bug in gecko about that.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is this related to bug 688580?

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://developer.mozilla.org/en-US/docs/Web/API/document.readyState

What if we substitute the DOMContentLoaded events with |readystatechange|, would that make a difference?

Bug 688580 documented a case when the page is served from HTTP, the deferred script will execute *after* DOMContentLoaded. And we did exactly that on settings/index.html; I wonder if the same behavior would happen to app:// as well?

I propose we come up with a consistent way of loading l10n.js so it would fire at the same time on all Gaia app html.

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #13)
> Bug 688580 documented a case when the page is served from HTTP, the deferred
> script will execute *after* DOMContentLoaded. And we did exactly that on
> settings/index.html; I wonder if the same behavior would happen to app:// as
> well?
> 
> I propose we come up with a consistent way of loading l10n.js so it would
> fire at the same time on all Gaia app html.

I've just tested the test case on bug 688580 comment 4 on Gaia (w/ template app), the bug doesn't affect app:// protocol.

Comment 15

[Fabien Cazenave [:kaze]]

Attachment: link to pull request

I lost a lot of time on this but the issue was very simple…

Evelyn, can you review this please?

Comment 16

[Evelyn Hung]

Comment on attachment 755615 [details]
link to pull request

r=me, the bug might be a good interview question. :p

Comment 17

[Fabien Cazenave [:kaze]]

Merged on master: https://github.com/mozilla-b2g/gaia/commit/cb3d8d5d6929718ea2eba5ffc4656a6efbfc0c41