getSelectedLocale in chrome registry should allow overwritten provider

RESOLVED FIXED in mozilla23

Status

()

Core
Localization
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: Pike, Assigned: Pike)

Tracking

(Blocks: 2 bugs)

22 Branch
mozilla23
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

5 years ago
We want sparse localizations of toolkit for both Android and Firefox OS multilocale builds.

The easiest way to do that is to overload the files that are actually used with a different package, but then getSelectedLocale() is wrong. So is GetLocalesForPackage().

Let's allow to tell the chrome registry which provider to ask a different package by adding a pref branch.
(Assignee)

Comment 1

5 years ago
Let's see what try thinks, https://tbpl.mozilla.org/?tree=Try&rev=cd9a6eb14d45
(Assignee)

Comment 2

5 years ago
Created attachment 726393 [details] [diff] [review]
add a prefbranch to override getSelectedLocale

I didn't get feedback from the Android folks yet, but I expect we'll end up needing this for b2g RSN, so requesting review.
Attachment #726393 - Flags: review?(benjamin)

Comment 3

5 years ago
Comment on attachment 726393 [details] [diff] [review]
add a prefbranch to override getSelectedLocale

I don't want to hold the long-lived branch object, and we don't need the special safe-mode behavior. Please just have nsChromeRegistryChrome::OverrideLocalePackage use mozilla::Preferences directly and skip the branch goop.
Attachment #726393 - Flags: review?(benjamin) → review-
(Assignee)

Comment 4

5 years ago
Created attachment 732328 [details] [diff] [review]
now with easier pref logic

Addressing the review comments, using the mozilla::Preferences api, don't store a pref branch.
Attachment #726393 - Attachment is obsolete: true
Attachment #732328 - Flags: review?(benjamin)

Comment 5

5 years ago
Comment on attachment 732328 [details] [diff] [review]
now with easier pref logic

This really sucks and if there isn't a bug filed on removing this hack, please file one. But it's ok for now.
Attachment #732328 - Flags: review?(benjamin) → review+
(Assignee)

Comment 6

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/21cd4d9e679b, and I'll file a follow-up next.
https://hg.mozilla.org/mozilla-central/rev/21cd4d9e679b
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
(In reply to Axel Hecht [:Pike] from comment #6)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/21cd4d9e679b, and
> I'll file a follow-up next.

What is the follow up bug number?
(Assignee)

Updated

5 years ago
Blocks: 869385
(Assignee)

Updated

5 years ago
Blocks: 869387
(Assignee)

Comment 9

5 years ago
I've filed two follow-ups, bug 869385 to not use prefs if we have a better storage for this data, and bug 869387 to rip out this code path completely once we support sparse localizations/l10n fallback at runtime.
(Assignee)

Updated

4 years ago
Blocks: 915721
You need to log in before you can comment on or make changes to this bug.