Closed
Bug 322962
Opened 19 years ago
Closed 11 years ago
Support for arbitrary number of l10n-defaulted prefs
Categories
(Core :: Preferences: Backend, defect)
Core
Preferences: Backend
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: Pike, Unassigned)
References
Details
For stuff like search plugin ordering, we want to have prefs fall back to l10n files which we don't know up front. There are two ways to implement this, 1) add nsIPrefBranch3 with a method string getCharPrefWithL10nDefault(in string aPrefName, in string aPropertiesPath) or 2) add a last cycle of preference file loading, going through a subdir of NS_APP_PREF_DEFAULTS_50_DIR, depending on the value of general.useragent.locale i.e. defaults/pref/de/ for german. I'll be working on this, once we decided where to go. This will be used at least for all those .1, .2, .3 prefs in all.js and friends.
Comment 1•18 years ago
|
||
I think I'd prefer something like option 1), but as a service separate from the prefservice: nsILocalizedPrefService { AString getCharPrefWithLocalizedDefault(in string aPrefName, in AUTF8String aPropertiesURLSpec); }; Darin, do you think this would be better as a separate service or as nsIPrefBranch3?
Reporter | ||
Comment 2•18 years ago
|
||
There'd still be option three, another interface on the pref service. I'm currently working on nsIPrefBranch3, but that's no decision. The ugly part of it is to hook it up somewhere, I didn't want to get in the middle of nsIPrefBranch2 and nsIPrefBranchInternal, as those two are conditional. Coming in independently confuses mRootBranch, sadly. Here's the current look of the interface, [scriptable, uuid(02e116a4-0d43-4148-a192-f68438529bf7)] interface nsIPrefBranch3 : nsISupports { /** * Called to get the state of an individual string preference. * * @param aPrefName The string preference to retrieve. * @param aPropertiesSpec The spec of a properties file from which to * retrieve the value if the preference is not set. * * @return string The value of the requested string preference. * * @see getCharPref */ AString getUnicharPrefWithDefault(in string aPrefName, in string aPropertiesSpec); /** * Called to set a preference to a string value. * * @param aPrefName The string preference to set. * @param aPrefValue The value of the preference. * * @see getUnicharPrefWithDefault */ void setUnicharPref(in string aPrefName, in AString aPrefValue); }; It has a setter, too, as js can only use setComplexValue right now, which seems much more complicated than required. It just maps to utf8 user prefs or to wide strings that the bundles return.
Comment 3•18 years ago
|
||
I think you should also replace string with ACString while you're there
Comment 4•18 years ago
|
||
> I think I'd prefer something like option 1), but as a service separate from the
> prefservice:
Why? Why not Axel's second solution? It's good to avoid extra APIs if possible.
Reporter | ||
Comment 5•18 years ago
|
||
bsmedberg, do you have time to comment here before you leave? Two additional thoughts, intl.locale.matchOS wouldn't like the 2nd option, unless we find out how to create an actually central point of language selection. I'd really love to make intl.locale.matchOS play nicely with the installed locales, something like searching for something descent in the result of getLocalesForPackage("global"). An additional note, I'm working on code that add urn support, which would take potentially localized prefs from arbitrary localization files, such that another extension could actually extend the protocol for other namespaces. Using method 1, they have to add those prefs twice, once to their locale file, once to their defaults file.
Reporter | ||
Comment 6•18 years ago
|
||
If we could get rid of foo.3 prefs for Firefox 3, that would make it much easier to work with langpacks and such. Requesting blocking1.9.
Flags: blocking1.9?
Comment 7•17 years ago
|
||
Axel, let's talk about matchOS... we should make that work well for 1.9, I think.
Assignee: prefs → l10n
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Updated•15 years ago
|
QA Contact: preferences-backend
Reporter | ||
Comment 8•11 years ago
|
||
I don't think we'll move forward with this, thus resolving INCOMPLETE.
Assignee: l10n → nobody
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•