Locale switch in Firefox doesn't work properly
prodizy
In the extension I am developing for Firefox, I am providing user, the
option of switching locale (through user interface) so that they can
use my extension in many languages. For doing this, I used the
preference "general.useragent.locale". I am setting the value for this
preference basing on the locale user chose from the UI.
After a restart, I expect Firefox to show my extension in the locale
that the user selected. But Firefox some times shows the extension in
that locale and some times it doesn't. What could be the problem?
Thanks & Regards,
Rajendra Prasad Murakonda
Axel Hecht
Switching locales for a single extension is not supposed to work. I'm
not totally sure if that's a bug.
What you're doing is that you're setting the locale for the whole app,
which might have all kind of weird and undesired side effects, in
particular, when your users had other localized extensions installed.
Which raises the question, what value are you trying to provide to your
users by doing that? There may be hacks one can use that only affect
your extension.
Axel
prodizy
> Switching locales for a single extension is not supposed to work. I'm
> not totally sure if that's a bug.
Though I wish to switch the locale only for my extension, I know it's
not possible. Is there a proper mechanism in place to take care of the
following situation:
We switch Firefox's locale and that language pack is not available for
Firefox, but some of the installed extensions have those language
strings.
When I do the above either Firefox should not respect installed
extensions' locale files or it should show them. But what Firefox is
doing in this case is not consistent. Some times It shows the regional
strings and some times it doesn't.
> Which raises the question, what value are you trying to provide to your
> users by doing that? There may be hacks one can use that only affect
> your extension.
What I was providing with my extension is a locale switcher. As you
people designed, user don't have to use it at all, as automatically his
language strings appear when they install my extension. I am doing this
as a convenience for the user. If he want to switch the locale to use
my extension in different language(which is a rarity), instead of going
to about:config or installing locale switcher extension, he can do it
from my extension only. Still If you feel I should remove it, I will do
so.
Now wouldn't it be great if we can set locales for extensions too?
though there might be performance issues, but can't that be handled
cleanly?
Thanks & Regards,
--
Rajendra Prasad Murakonda,
http://prodizy.livejournal.com/
Axel Hecht
Well, you still set the locale for the whole app, and that may yield
anything. I'm not sure if the xul cache clears everything if you switch
to a locale that doesn't exist (for content).
Really, without an example, I can't comment on the actual problem, not
sure if I'd say more than WORKSFORME with an example.
> Now wouldn't it be great if we can set locales for extensions too?
> though there might be performance issues, but can't that be handled
> cleanly?
It's a design issue. The only thing we could do is create language
settings per packagename, but that requires
- extensions properly use package names
- a spec to define what happens in mismatches
Take the following combination of installed locales:
| l1 | l2 | l3
----------------------
browser | X | | X
ext1 | | X | X
ext2 | X | |
Now go through all combinations of locale selections, specify the
intended behavior, and include things like, "oops, my extension
triggered a toolkit error message" and the like. Opening a file,
printing an extension page etc.
And then we still had to come up with a good UI for that.
Axel
prodizy
> I'm not sure if the xul cache clears everything if you switch
> to a locale that doesn't exist (for content).
That's exactly my problem. If Firefox doesn't have the current locale
strings, xul cache doesn't reload(my observation). So immediately I
can't see my extension's strings in current locale eventhough the
extension is localised to that locale. So when the XUL cache reloads I
can see the extension in the local language and Firefox in the earlier
locale(or Fall back locale, I guess). Where as .properties strings
appear immediately without restarting, as I am using
nsIStringBundleService.
Is it feasible to check whether any of the extensions' strings are
localised to current locale and, if so then reload the XUL? I guess
it's a performance bottle neck. But still, atleast this behaviour as a
preference...
> It's a design issue. The only thing we could do is create language
> settings per packagename, but that requires
[...]
> Now go through all combinations of locale selections, specify the
> intended behavior, and include things like, "oops, my extension
> triggered a toolkit error message" and the like. Opening a file,
> printing an extension page etc.
OK, may be, it is a bad idea :)
Thanks for the help,
--
Rajendra Prasad Murakonda.
http://prodizy.livejournal.com/
Axel Hecht
> Axel Hecht wrote:
>
>> I'm not sure if the xul cache clears everything if you switch
>> to a locale that doesn't exist (for content).
>
> That's exactly my problem. If Firefox doesn't have the current locale
> strings, xul cache doesn't reload(my observation). So immediately I
> can't see my extension's strings in current locale eventhough the
> extension is localised to that locale. So when the XUL cache reloads I
> can see the extension in the local language and Firefox in the earlier
> locale(or Fall back locale, I guess). Where as .properties strings
> appear immediately without restarting, as I am using
> nsIStringBundleService.
>
> Is it feasible to check whether any of the extensions' strings are
> localised to current locale and, if so then reload the XUL? I guess
> it's a performance bottle neck. But still, atleast this behaviour as a
> preference...
IIRC, the brittle nature of clearing the xul cache was the main reason
to actually remove a language switcher from the UI.
I don't think it's high on our list of things to fix, if it's on it at all.
>> It's a design issue. The only thing we could do is create language
>> settings per packagename, but that requires
> [...]
>> Now go through all combinations of locale selections, specify the
>> intended behavior, and include things like, "oops, my extension
>> triggered a toolkit error message" and the like. Opening a file,
>> printing an extension page etc.
>
> OK, may be, it is a bad idea :)
>
I really think that you're doing to heavy weight stuff for what you want.
I'm not exactly sure if there is a user category that would like to
switch back from what happens to them per default, but if it's a clear
category of users having this language combo and would like to have a
different, you should be able to hook that up just by redirecting that
second locale to the first jar inside the chrome manifest.
Axel
Robert Kaiser
> Axel Hecht wrote:
>
>> I'm not sure if the xul cache clears everything if you switch
>> to a locale that doesn't exist (for content).
>
> That's exactly my problem. If Firefox doesn't have the current locale
> strings, xul cache doesn't reload(my observation). So immediately I
> can't see my extension's strings in current locale eventhough the
> extension is localised to that locale. So when the XUL cache reloads I
> can see the extension in the local language and Firefox in the earlier
> locale(or Fall back locale, I guess). Where as .properties strings
> appear immediately without restarting, as I am using
> nsIStringBundleService.
This is a well-known bug with the XUL FastLoad Cache system, and we have
been told that "it must be resolved before Mozilla 1.1 final", back when
it first was introduced. As we found a mostly-working workaround for the
suite's integrated locale switcher, it has never been actually fixed
since back then, as noone who knows the code was sufficiently interested
in working on a fix.
(look in the suite code for pref-locales.xul to find the workaround and
in the comment to it even the bug number)
Robert Kaiser
prodizy
> I'm not exactly sure if there is a user category that would like to
> switch back from what happens to them per default,
Infact there are people like that in India and Europe and may be other
places too.
> but if it's a clear category of users having this language combo and would
> like to have a different,
This is exactly my need.
> you should be able to hook that up just by redirecting that
> second locale to the first jar inside the chrome manifest.
If possible, can you explain this a bit.
Thanks a lot,
- Raj
prodizy
> This is a well-known bug with the XUL FastLoad Cache system, and we have
> been told that "it must be resolved before Mozilla 1.1 final", back when
> it first was introduced. As we found a mostly-working workaround for the
> suite's integrated locale switcher, it has never been actually fixed
> since back then, as noone who knows the code was sufficiently interested
> in working on a fix.
>
> (look in the suite code for pref-locales.xul to find the workaround and
> in the comment to it even the bug number)
Will defintely do that when I get time.
Axel Hecht
You'd want to read
http://developer.mozilla.org/en/docs/Chrome_Registration and add some
more locale lines to your chrome.manifest.
Axel
prodizy
> You'd want to read
> http://developer.mozilla.org/en/docs/Chrome_Registration and add some
> more locale lines to your chrome.manifest.
I already have the following three lines in chrome.manifest
locale savernova en-US locale/en-US/
locale savernova de locale/de/
locale savernova fr locale/fr
I didn't understand the redirecting part you were mentioning. Above
lines are not enough?
- Raj
Axel Hecht
locale savernova es-ES locale/de/
would for example make spanish users see the german localization.
Not that I consider that to be a splendid idea in particular.
Axel
Ricardo Palomares Martinez
>
> locale savernova es-ES locale/de/
>
> would for example make spanish users see the german localization.
>
> Not that I consider that to be a splendid idea in particular.
Definitely not! :-) I don't think there is a lot of spanish people
understanding german.
Ricardo
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?