12482 - [feature] Fallbacks in LoadResources() based on locale

Status: RESOLVED INVALID

(Core Graveyard :: Installer: XPInstall Engine, defect, P5)

Description

[Samir Gehani]

We need to append the locale info in a hierarchical fallback mechanism to the
basename supplied as the sole parameter in Install.LoadResources().

Given a base name of "rsrc" we will first look for "rsrc_en_US.properties", then
"rsrc_en.properties", and finally "rsrc.properties" (the actual locale used will
be based on the current runtime environment).

Comment 1

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 2

[Cathleen]

cut feature
putting on helpwanted

Comment 3

[Daniel Veditz [:dveditz]]

Changing fictional "M30" to reality

Comment 4

[Samir Gehani]

Over to Syd for installer bug triage

Comment 5

[Tim Powell]

Is there an alternative technique or workaround for this missing feature? Is
there any way to determine the locale in a XPI? In Netscape 4 SmartUpdate code
you could use Java to get it:

locale = java.util.Locale.getDefault();
language = locale.getLanguage();

It'd be great if XPInstall could use the HTTP Accept Language so the install
would be able to show up in the language of the web page.

Comment 6

[Karsten Düsterloh]

Taking.
To match the current practice of having locale directories named like the
locale, I'm planning to implement this fallback algorithm:

Given ./install.js in the XPI, then Install.loadResources("some.properties")
should do this:
 - get the current locale, e.g. mo-ZI
 - try to load ./mo-ZI/some.properties
 - if that fails, try ./mo/some.properties
 - if that fails, try ./mo-firstOtherRegion/some.properties
 - if that fails, try ./some.properties
 - if that fails, throw an error just like today

Comment 7

[Benjamin Smedberg]

>  - get the current locale, e.g. mo-ZI

*what* current locale?  I don't want to introduce another dependency of
xpinstall on the chrome registry... please see bug 215212 for my plans (soon,
hopefully), to move locale-selection into a more logical place in the interface
hierarchy.

>  - if that fails, try ./mo-firstOtherRegion/some.properties

firstOtherRegion?

--BDS

Comment 8

[Karsten Düsterloh]

> *what* current locale?  I don't want to introduce another dependency
> of xpinstall on the chrome registry

Good point.
How about using the prefs general.useragent.[content]locale and
intl.accept_languages, then?

>> - if that fails, try ./mo-firstOtherRegion/some.properties
> 
> firstOtherRegion?

If you have mo-ON ad mo-RE as locales, but no mo-ZI or mo, take the first of
those you find.
Of course, this would mean reading chrome, so I'm dropping that.

Apart from that, my first proposal would possibly introduce *lots* of main level
directories into the XPI. Since already "block" the name |install.js| for free
use, it'd make sense to put all the locale directories under the main level
directory |install|.

So the steps would be, given ./install.js and Install.loadResources("some.file"):
- get the current locale from general.useragent.locale, eg. mo-ZI
- try ./install/mo-ZI/some.file
- if that fails, try ./install/mo/some.file
- if that fails, read intl.accept_languages and try those we haven't tried yet
- if that fails, try ./install/some.file
- if that fails, try ./some.file
- if that fails, set error condition as today

Comment 9

[Tim Powell]

Why use locale directories instead of modifying the filename with the locale as
suggested by the bug reporter? Modifying the name is consistent with the
behavior of Java properties files. Although it's somewhat irrelevant now, the
predecessor of XPInstall, Netscape 4 SmartUpdate, was Java-based (see my comment
5). If other parts of Mozilla localization use the directory style, that's fine;
I haven't looked. I'm actually interested in using XPInstall for product install
as part of a web-based application, not for browser modifications (such as
extensions or themes) so the way Mozilla does it elsewhere isn't important to me.

Regardless of the mechanism, using the HTTP Accept Language to find the
appropriate locale-specific version would be very nice. This would allow
xpinstall packages to be displayed in the same locale as the web page hosting
the install.

The one work around I've thought of for the current limitation of not knowing
the web page's locale was to pass it as part of the argument string to the
install. For example, startSoftwareUpdate("http://webserver/install.xpi?LOCALE")
You could read the LOCALE as Install.arguments and then load the appropriate file.

Comment 10

[Karsten Düsterloh]

> Why use locale directories instead of modifying the filename with the
> locale as suggested by the bug reporter?
> Modifying the name is consistent with the behavior of Java properties
> files. [...] If other parts of Mozilla localization use the directory
> style, that's fine; I haven't looked.

Well, modifications to file names are just plain ugly. ;-)
We should follow a convention and have two to choose from...
But it shouldn't actually be difficult to integrate yours:

...
- if that fails, try ./install/some.file
- if that fails, try ./some_mo_ZI_.file
- if that fails, try ./some_mo.file
- if that fails, try ./some.file
...

> Regardless of the mechanism, using the HTTP Accept Language to find
> the appropriate locale-specific version would be very nice. This
> would allow xpinstall packages to be displayed in the same locale as
> the web page hosting the install.

The HTTP Accept Language information *is* intl.accept_languages.

> The one work around I've thought of for the current limitation of not
> knowing the web page's locale was to pass it as part of the argument
> string to the install. For example,
> startSoftwareUpdate("http://webserver/install.xpi?LOCALE") You could
> read the LOCALE as Install.arguments and then load the appropriate
> file.

Nice.

Comment 11

[Jens Bannmann]

(In reply to comment #9)
> Regardless of the mechanism, using the HTTP Accept Language to find the
> appropriate locale-specific version would be very nice. This would allow
> xpinstall packages to be displayed in the same locale as the web page hosting
> the install.

As an extension author, I'd prefer having the install process in the same locale
as the browser. For example, multi-locale extensions are (hopefully) be set to
the matching locale after the install, but during the install we don't know.

IMO, it would be best to simply have a property in the Install object, analogous
to "platform" instead of or in addition to the fallback in LoadResources().
Mozilla seems to initially set a new package's locale to the first one that is
registered via install.js, regardless if it's the application locale or not. A
script could circumvent this if it knew the app locale.

> The one work around I've thought of for the current limitation of not knowing
> the web page's locale was to pass it as part of the argument string to the
> install.

That's not enough, as you do not always control how the XPI is started: Think of
update.mozilla.org, or drag and drop of local files...

(In reply to comment #7)
> *what* current locale?  I don't want to introduce another dependency of
> xpinstall on the chrome registry... please see bug 215212 for my plans (soon,
> hopefully), to move locale-selection into a more logical place in the interface
> hierarchy.

If bug 215212 still needs time, this could start with a dependency on the chrome
registry which could later easily be changed (after all, it's only the retrieval
of one simple value)...

Comment 12

[Jens Bannmann]

Karsten, in the meanwhile the chrome registry was changed to read the selected
locale from the pref "general.useragent.locale". nsEmbedLocale from bug 215212
has been postponed - how about implementing this with the pref for now? A
subsequent change of the retrieval once bug 215212 gets resolved should be trivial.

Comment 13

[Dave Townsend [:mossop]]

install.js is no longer supported