Closed Bug 831228 Opened 12 years ago Closed 12 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g18+)

RESOLVED FIXED
blocking-b2g -
Tracking Status
b2g18 + ---

People

(Reporter: carlosmartinez, Assigned: kaze)

References

Details

(Whiteboard: l10n, u=fx-os-user c=scravag-sprint p=1)

Attachments

(2 files, 2 obsolete files)

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
blocking-b2g: tef? → -
Whiteboard: l10n
Assignee: nobody → kaze
Whiteboard: l10n → l10n, u=fx-os-user c=may-6-17 p=1
Hi there, You can check bug #863191, then you will found all the subhead of Settings' panal not translated every time.
Flags: needinfo?(carlos.martinez)
Hi, ok thank you for the info, but... What´s the info you need from me?
Flags: needinfo?(carlos.martinez)
(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?
I’m in charge of this (on PTO today, though). Feel free to “needinfo” me!
Attached file link to pull request — proper fix (obsolete) (deleted) —
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.
Attachment #748724 - Flags: review?(21)
Attached file link to pull request — quick and dirty fix (obsolete) (deleted) —
Here’s a quick and dirty but safe patch if the former one is too risky.
Attachment #748727 - Flags: review?(ehung)
Comment on attachment 748727 [details] link to pull request — quick and dirty fix r=me, I think it's not so bad. :p
Attachment #748727 - Flags: review?(ehung) → review+
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.
Attachment #748724 - Flags: review?(21) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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.
Blocks: 874441
Whiteboard: l10n, u=fx-os-user c=may-6-17 p=1 → l10n, u=fx-os-user c=scravag-sprint-may-20-31 p=1
Whiteboard: l10n, u=fx-os-user c=scravag-sprint-may-20-31 p=1 → l10n, u=fx-os-user c=scravag-sprint p=1
(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.
Blocks: 876350
Attached file link to pull request (deleted) —
I lost a lot of time on this but the issue was very simple… Evelyn, can you review this please?
Attachment #748724 - Attachment is obsolete: true
Attachment #748727 - Attachment is obsolete: true
Attachment #755615 - Flags: review?(ehung)
Comment on attachment 755615 [details] link to pull request r=me, the bug might be a good interview question. :p
Attachment #755615 - Flags: review?(ehung) → review+
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: