Closed Bug 322962 Opened 19 years ago Closed 11 years ago

Support for arbitrary number of l10n-defaulted prefs

Categories

(Core :: Preferences: Backend, defect)

defect
Not set
normal

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.
Blocks: 324330
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?
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.
I think you should also replace string with ACString while you're there
> 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.
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.
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?
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]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
QA Contact: preferences-backend
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.