Closed Bug 1111575 Opened 10 years ago Closed 10 years ago

Header displays "Language" instead of "Data"

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.2 S2 (19dec)

People

(Reporter: gerard-majax, Assigned: sfoster)

Details

(Keywords: polish, regression, Whiteboard: [systemsfe])

Attachments

(2 files)

Reproduced since several weeks on my Flame/master.

STR:
 0. ./build.sh && ./flash.sh
 1. Follow FTU

Expected:
 When configuring the data connection, the header should be "Data"

Actual:
 Header shows "Langue" (fr).
Flags: needinfo?(sfoster)
Attached image 2014-12-15-14-29-28.png
We're mid-transition, so this is misleading - details below. Looking at the fr strings at https://hg.mozilla.org/gaia-l10n/fr/file/391266f46a4d/apps/ftu/ftu.properties it looks like this header will get translated as "Données mobiles". 

I checked in with the l10n folks about this before to get clarification. Historically, the Gaia repo has had a subset of locales allowing devs and testers to switch language and see Gaia apps translated/localized. That is no longer the case, all current translations and localization work takes place in the dedicated repo for that locale. The Arabic, French and Chinese languages we see in the gaia repo are *not* current and will eventually be removed. 

The pseudo-localizations are intended to allow l10n testing on the gaia repo. Once you enable pseudo-localizations in the developer settings, you can preview translation, right-to-left etc with the Accented English and Mirrored English pseudo-locales. 

For this particular case, as the Cellular Data header gets correctly localized with accented english, and the correct translated string appears in that locale's l10n repo, there's no bug to fix.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(sfoster)
Resolution: --- → WORKSFORME
And yet, the string you are pointing at is properly localized in the french locale burned in Gaia repo, even if this is expected to die: https://github.com/mozilla-b2g/gaia/blob/master/apps/ftu/locales/ftu.fr.properties#L110

So I don't buy your argument, and I still think there is something broken here.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
See comment 3: the fr locale in the gaia repo has the proper string for this, I don't see why it would not display this as expected.
Flags: needinfo?(sfoster)
(In reply to Alexandre LISSY :gerard-majax from comment #4)
> See comment 3: the fr locale in the gaia repo has the proper string for
> this, I don't see why it would not display this as expected.

Fair enough, we do swap the data-l10n-id on that header so its possible we're not re-translating or the translation is getting cached or somesuch. I'll take a look, thanks.
Assignee: nobody → sfoster
Flags: needinfo?(sfoster)
The patch ensures we only add a data-l10n-id on #main-title if one has not yet been added. We use navigator.mozL10n.ready as the entry point to start the FTU, but when you select a different language mozL10n.ready fires again. Previously we had a race condition that allowed the #main-title to get set to Language even if the user was no longer on that screen.
Attachment #8536847 - Flags: review?(fernando.campo)
Note we don't really need to re-request the versionInfo each time the language changes, but rather than refactor this I've just added the guard to avoid resetting the data-l10n-in on #main-title. If settings access is demonstrated to slow this noticably, we could consider fixing this, but YAGNI is strong in 2.2
Whiteboard: [systemsfe]
Target Milestone: --- → 2.2 S2 (19dec)
Comment on attachment 8536847 [details] [review]
PR: Conditionally set mainTitle on mozL10N.ready

Code looks good, enough to avoid that race condition you mention, but I'm testing in the dark in here, as I'm unable to reproduce the bug in the first place. 

On master, every time I tried, with any language, header gets translated properly, so I'd like to ask :gerard-majax to test it instead, to double check.
Flags: needinfo?(lissyx+mozillians)
Attachment #8536847 - Flags: review?(fernando.campo) → review+
Comment on attachment 8536847 [details] [review]
PR: Conditionally set mainTitle on mozL10N.ready

Looks like it does fix the issue I was seeing.
Flags: needinfo?(lissyx+mozillians)
Attachment #8536847 - Flags: feedback+
Thanks for confirming Alexandre. Merged to master: https://github.com/mozilla-b2g/gaia/commit/936568333c4c3bd31a511fef08c876b7d0fdd5ca
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: