Firefox interface language set to LANG, ignores LANGUAGE

Amazing how fast you guys responded to this!

Thank you!

I am looking forward ot the update.

Martin

2010/5/6 Steve Langasek <email address hidden>

> ** Changed in: firefox (Ubuntu)
> Milestone: ubuntu-10.04 => None
>
> --
> Firefox interface language set to LANG, ignores LANGUAGE
> https://bugs.launchpad.net/bugs/550222
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Marking this Triaged as we have an upstream bug.

shankao,

Thanks for adding the amule task. However, this particular bug is for Firefox, so it would be great if you could file a separate bug for amule instead.

Using LANG instead of LANGUAGE is not the default behavior of Firefox. For some reason, Debian seems to have created the problem through a firefox.js file with Debian specific preferences:

$ grep -B1 'matchOS' /etc/firefox/pref/firefox.js
// Use LANG environment variable to choose locale
pref("intl.locale.matchOS", true);

I figured out how to change the behavior to our liking, and the solution is described in the patch (or hack) I attached to this bug. The same solution works just as well for Thunderbird, btw.

Just adding the user_pref("intl.locale.matchOS", false); line to user.js fixes the problem for me. Thank you for the tip.

Do we know why (and by whom) that option was set in the Debian-provided preferences override?

#15:
Of course, it fixes the problem for me by setting the language to English, which is the default. You still need to tell Firefox which language to use if you want any other language.

The fix works fine for me, but are you sure that this is really a Debian-specific problem?
I have absolutely no idea of the Mozilla code, but considering the very serious and advanced discussion at the Mozilla bugtracker, I can't really believe that the whole thing is only about a Debian config file.

Resetting bug to Triaged. matchOS was added so Firefox automatically uses the language of the host system. I'll have to look at the UILocale startup option since we do have a wrapper script in place already.

Does the patch also fix language preferences order, if the more preferred language is not available?

Can you please not mark attachments as patches unless they really are patches.

Thanks

And please don't link branches to the bug, unless they contain a fix for the issue

Since I'm questioning a Debian specific configuration, I filed a Debian bug also:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598244

We don't get Firefox from Iceweasel, I'm closing that bug.

Indeed. And setting intl.locale.matchOS is intentional (not a bug). Without it, Firefox gets the language from the general.useragent.locale preference rather than the users environment. I've got no idea how that could work reliably on Ubuntu, seeing as we localize that preference....

@Jeroen Hoek, comment #15
You are welcome. I don't know why or by whom.

@Felix Dreissig, comment #17
No, I'm not sure. What I know about the background is included in the bug I filed with Debian (see comment #22), and that firefox.js file indicates that the problem is Debian-specific IMO.

@Micah Gersten, comment #18
The Ubuntu l10n / i18n model, not least the language-selector package, seems to assume that LANGUAGE is for language while LANG is for other locale stuff. Also, please see my comment #21 in bug 553162.

As regards the wrapper, I suppose there is a more suitable place for that code. Great if you check it out!

@Nicolò Chieffo, comment #19
Well, no. English is always there as a fall back language, but AFAIK Ubuntu cannot currently handle a non-English fall back language.

@Chris Coulson, comment #20 and comment #21
I hesitated as regard the patch mark... Sorry! Pls bear with a newbie in this community.

@Micah Gersten, comment #23
I disapprove of your action. I identified a possible issue, and tried to communicate it with "upstream". Obviously we got some configuration stuff from Debian, and Debian wants the applicable package name just like that.

@Chris Coulson, comment #24
Also intentional code may become a bug later on, if it proves to cause unexpected problems, right?

> I've got no idea...
I for one have a very clear idea. How about testing the solutions I shared here and in bug 553162? Only after that I think it will be meaningful to talk about pros and cons.

 As I wrote, Firefox doesn't come from Debian, therefore, Debian isn't
upstream in this case.

On 09/27/2010 06:07 PM, Gunnar Hjalmarsson wrote:
> @Felix Dreissig, comment #17
> No, I'm not sure. What I know about the background is included in the
bug I filed with Debian (see comment #22), and that firefox.js file
indicates that the problem is Debian-specific IMO.
>
> @Micah Gersten, comment #23
> I disapprove of your action. I identified a possible issue, and tried
to communicate it with "upstream". Obviously we got some configuration
stuff from Debian, and Debian wants the applicable package name just
like that.

I have modified the GDM patch attached to bug 553162, and now that patch fixes the problem with programs, e.g. Firefox, that don't recognize $LANGUAGE. Even if the solution provided as an attachment to this bug works well, the code in the GDM patch is more elegant IMO.

If you want to deal with this issue, without implementing the bug 553162 patches, and assuming that you want menus and messages translated into German, you can just add this line to the bottom of your ~/.profile file:

    export LC_MESSAGES="de_DE.utf8"

Being completely out of the programming in this case,
my 5 öre is to say that it is not really good to have two
global variables with almost same names, but slightly
different meanings, and also same but slightly different
meanings for their names. It could be a good idea to change
both the variable names LANG and LANGUAGE to something
more descriptive, I think.

Martin

2010/10/5 Gunnar Hjalmarsson <email address hidden>

> I have modified the GDM patch attached to bug 553162, and now that patch
> fixes the problem with programs, e.g. Firefox, that don't recognize
> $LANGUAGE. Even if the solution provided as an attachment to this bug
> works well, the code in the GDM patch is more elegant IMO.
>
> If you want to deal with this issue, without implementing the bug 553162
> patches, and assuming that you want menus and messages translated into
> German, you can just add this line to the bottom of your ~/.profile
> file:
>
> export LC_MESSAGES="de_DE.utf8"
>
> --
> Firefox interface language set to LANG, ignores LANGUAGE
> https://bugs.launchpad.net/bugs/550222
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (576162).
>

@ Martin A.
It's true that descriptive variable names is good programming practice as a general rule. However, here we are talking about two environment variables, whose names are beyond the control of the Ubuntu community. When you deal with i18n and l10n as a programmer, you simply need to learn the meaning of those variables.

This shouldn't be a duplicate as Firefox is not respecting the environment variables properly. There is already a partial patch in the upstream tracker for this issue.

@ Micah Gersten, David Planella
I marked this bug, and with that its duplicates, as a duplicate of bug 553162, since the issue reported here will be solved by the solution being discussed at bug 553162. Please feel free to test the patches for yourself:

https://launchpad.net/~gunnarhj/+archive/locale-test

I have noticed that you reverted my action, so I now understand that you, unlike me, prefer to consider inability to recognize LANGUAGE to be a bug per se. But isn't that disputable as regards non-GNU apps? Anyway, it's of course good if as many apps as possible recognize LANGUAGE and its priority list feature. My apologies if you concluded from my action that I'm of another opinion.

El ds 16 de 10 de 2010 a les 22:53 +0000, en/na Gunnar Hjalmarsson va
escriure:
> @ Micah Gersten, David Planella
> I marked this bug, and with that its duplicates, as a duplicate of bug 553162, since the issue reported here will be solved by the solution being discussed at bug 553162. Please feel free to test the patches for yourself:
>
> https://launchpad.net/~gunnarhj/+archive/locale-test
>

Hi Gunnar,

Both Micah and I gave clear information on why we undid the duplication.
they are two different bugs:

* One affecting the interaction between gdm and language-selector in
setting LANG and LANGUAGE (and somewhere along the way it seems
language-selector seems to fail setting LC_* as well?).

* One affecting Firefox (and also other apps such as OpenOffice.org, for
which there is a task in one of the duplicates), where it does not
support the $LANGUAGE variable.

It does not matter if fixing gdm/language-selector will hide the second
bug: Firefox and other apps will still not support $LANGUAGE. If they
are used in environments where the vast majority of applications support
gettext, I think it's a valid request to expect them to implement the
gettext variables, so they do not have to be special-cased.

> I have noticed that you reverted my action, so I now understand that
> you, unlike me, prefer to consider inability to recognize LANGUAGE to be
> a bug per se.

Yes, as explained in the Firefox bug, both upstream and downstream.

> But isn't that disputable as regards non-GNU apps? Anyway,
> it's of course good if as many apps as possible recognize LANGUAGE and
> its priority list feature. My apologies if you concluded from my action
> that I'm of another opinion.
>

No need to apologize. It's completely fine to disagree!

Thanks for your work on this so far.

As regards disagreement... While I may think that a request for recognizing LANGUAGE is a feature request, you think it's a bug. Not much of a disagreement to mind about, I'd say. :) Let's talk about the issue at hand instead.

The patches attached to bug 553162 make sure that the first item in LANGUAGE coresponds with LC_MESSAGES, whose value Firefox respects. Consequently, once those patches have been implemented, the simple Firefox patch that Wolfgang Rosenauer wrote, and which only supports one LANGUAGE item, would in effect become a no-op.

The point with the gettext variable LANGUAGE is its priority list.
http://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable

Hence I'd say that making an app recognize LANGUAGE ought to mean that it's given the ability to respect the whole list, or else it doesn't matter.

see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/820333