All users were logged out of Bugzilla on October 13th, 2018

[l10n] l10n.js failed if locale ini imports non-exist propertie files

VERIFIED FIXED in B2G C3 (12dec-1jan)

Status

P1
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: johnshih.bugs, Assigned: kaze)

Tracking

unspecified
B2G C3 (12dec-1jan)

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [target:12/21])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
## Environment :
Unagi phone, build 2012-11-30
Build info: 
gaia master : ccf5f69acf7cb9f1831ecc69d7c518c243c74c3a
mozilla-beta : 6c14548dbd4e

## Repro :
1. Enter settings app
2. Enable the Language page
3. Launch the language selection page
4. Press Hebrew first, verify the layout will left-right reverse
5. Press Francis or Mandarin 

## Expected:
* The layout will reverse back

## Actual:
* Didn't reverse back

## Note:
* Only English works normally
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Priority: -- → P2
(Reporter)

Comment 1

6 years ago
It also happened in FTU
Summary: [Settings][Language] The layout won't reverse back after switch from Hebrew to Francis or Mandarin → [FTU][Settings][Language] The layout won't reverse back after switch from Hebrew to Francis or Mandarin
Hebrew should not be in scope for v1.
blocking-basecamp: + → ?
I discovered the root cause about this issue. I can take this one if it becomes BB+ issue. Thanks
(In reply to Steve Chung from comment #3)
> I discovered the root cause about this issue. I can take this one if it
> becomes BB+ issue. Thanks

Please document your progress by writing it down here, or at least upload an WIP patch.
Not on V1
blocking-basecamp: ? → -
Duplicate of this bug: 818361
The root cause is because the localize event does not dispatch when locale file path set in ini but no actual locale file matched. It will make localization failed if we forget to update the responding locale file that set in ini. Although Fr and zh-TW is not the target language for V1, we should have better error handling for l10n parsing because such scenario could be reproduced easily in the future.
blocking-basecamp: - → ?
Summary: [FTU][Settings][Language] The layout won't reverse back after switch from Hebrew to Francis or Mandarin → [FTU][Settings][Language]Language is not applied after switch to zh-TW and French in language settings
Update title, see comment 7.

Pike, do you think fragile l10n bug like this should block?
Component: Gaia::Settings → Gaia
OS: Mac OS X → All
Hardware: x86 → All
Summary: [FTU][Settings][Language]Language is not applied after switch to zh-TW and French in language settings → [l10n] l10n.js failed if locale ini imports non-exists properties files
Summary: [l10n] l10n.js failed if locale ini imports non-exists properties files → [l10n] l10n.js failed if locale ini imports non-exist propertie files

Comment 9

6 years ago
Yes, we need this. We need confidence that the builds we do are stable against broken localizations. Right now, on any issue with a localized builds, the emails end with a pointer "and then there's this bug, who knows if it's affecting it".
BB-. Do we have a concrete example of where this is a problem for the langauges that we are shipping with?
blocking-basecamp: ? → -
Priority: P2 → P4

Comment 11

6 years ago
I can't commit to provide working localizations for either 1.0 nor 1.1 without this bug being fixed. Given that we're taking string changes on a daily basis still, there's no point to restrict the impact of this bug on current problems, but any of the pending changes can break the build to be untestable.
blocking-basecamp: - → ?
Would removing the non-working locales from the language list in Settings fix this problem?
Flags: needinfo?(l10n)
(Assignee)

Comment 13

6 years ago
Created attachment 690892 [details]
quick and dirty patch

Steve, please let me know if you have a better patch in mind.

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): ?
User impact if declined: some apps (e.g. FTU) are broken if any l10n resource is missing 
Testing completed: manual
Risk to taking this patch (and alternatives if risky): that’s just a try…catch
Attachment #690892 - Flags: review?(schung)
Attachment #690892 - Flags: approval-gaia-master?(21)

Comment 14

6 years ago
(In reply to Ben Francis [:benfrancis] from comment #12)
> Would removing the non-working locales from the language list in Settings
> fix this problem?

With the constraint that we won't be providing localizations, like I alerted at in my previous comment.

Glancing at the pull request, that should also address the issue.
Flags: needinfo?(l10n)
Comment on attachment 690892 [details]
quick and dirty patch

I think using try/catch is also the method I will apply in this fixing(for non-existing URL), thanks!
Attachment #690892 - Flags: review?(schung) → review+
Trage: Steve can you explain the problem more fully and why it prevents localisation from working. From the description it sounds like there's only an issue if the .properties file is missing.
Is this a dup of bug 816978? We could just land the bug there since it's already blocking+'d
Flags: needinfo?(nobody)
(Assignee)

Updated

6 years ago
Assignee: nobody → kaze
(Assignee)

Comment 18

6 years ago
Right, Daniel just pinged me about it. Can someone put a bb+ label on this one please?
(Assignee)

Updated

6 years ago
Duplicate of this bug: 816978
Thanks for the info Tim
blocking-basecamp: ? → +
Flags: needinfo?(nobody)
Priority: P4 → P1
Whiteboard: [target:12/21]
Target Milestone: --- → B2G C3 (12dec-1jan)
(Assignee)

Updated

6 years ago
Attachment #690892 - Flags: approval-gaia-master?(21)
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
I just installed master gaia on unagi and Spanish is working perfectly, thanks!
(Assignee)

Comment 22

6 years ago
Glad to read this, thanks for your early feedback!
(In reply to Ben Francis [:benfrancis] from comment #20)
> Thanks for the info Tim

Cool, I just realized I needinfo?'d nobody!
(In reply to Steve Chung from comment #15)
> Comment on attachment 690892 [details]
> quick and dirty patch
> 
> I think using try/catch is also the method I will apply in this fixing(for
> non-existing URL), thanks!

Kaze, I would say this deserves filing a platform bug and a mention of that bug number in the code. Would you file that bug please?
Flags: needinfo?(kaze)

Comment 25

6 years ago
Verified on Unagi device Build ID: 20130103070201
Status: RESOLVED → VERIFIED
Flags: needinfo?(kaze)
You need to log in before you can comment on or make changes to this bug.