Does not honor LC_MESSAGES

[GoogleCodeExporter]

Followup for ubuntu bug #1404947

LC_ALL="" LANG=de_DE.UTF-8 LC_MESSAGES=C hedgewars

that should run the standard english version of the program interface but in 
fact the German version is shown. Check "man 7 locale" for the hierarchy of 
locale-related environment variables.

Original issue reported on code.google.com by costamag...@gmail.com on 24 Mar 2015 at 6:11

[GoogleCodeExporter]

Unable to reproduce.
If I ran with a clean config I got the standard english version.
If I ran in my normal config I got the french version.

I'm going to guess it is simply the user's explicit config preference 
overriding the env var.

Original comment by kyberneticist@gmail.com on 24 Mar 2015 at 10:12

[GoogleCodeExporter]

quoting from bug
https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1435643

"mmm seems that there is no bug...

do you have language-pack-de-base installed?
I guess the package is needed to set the locale.

After moving my .hedgewars config dir I tried to reproduce and I can switch 
correctly between italian end english (the two locale I use on my machine)"

is that a reasonable explanation for the issue?

Original comment by costamag...@gmail.com on 24 Mar 2015 at 6:53

[GoogleCodeExporter]

Sure. Specifically is ~/.hedgewars/hedgewars.ini  locale=de_DE

And yeah, the reason is to allow the user to override system locale in the game 
config, in case, say, a translation is incomplete or they just prefer another 
language.

Original comment by kyberneticist@gmail.com on 24 Mar 2015 at 7:01

• Changed state: Invalid

[GoogleCodeExporter]

So, hedgewars gets locale language using QLocale.system()
This may not be correct, since that does return the system language which is... 
well, who knows, but I bet it isn't LC_MESSAGES.

I see that QLocale does have QLocale::uiLanguages()

This may be more appropriate, although I don't know yet if it would fix this 
issue.

Original comment by kyberneticist@gmail.com on 25 Mar 2015 at 4:33

[GoogleCodeExporter]

Welp...

$ cat qlocale.cpp 
#include <QLocale>
#include <QStringList>
#include <QString>
#include <iostream>
using namespace std;
int main(int argc, char **argv) 
{
    QLocale l;
    cout << l.system().name().toLocal8Bit().constData() << endl;
    cout << l.uiLanguages()[0].toLocal8Bit().constData() << endl;
}

$ g++ -I /usr/include/qt4 -I /usr/include/qt4/QtCore qlocale.cpp -lQtCore
$ ./a.out
en_CA
en-CA

$ HOME=/tmp/t LC_ALL="" LANG=de_DE.UTF-8 LC_MESSAGES=C ./a.out
C
C

So... I dunno... We are getting a locale of C I guess in either case.

Original comment by kyberneticist@gmail.com on 25 Mar 2015 at 4:41

[GoogleCodeExporter]

Ah. duh.

            // Fallback to current input locale if "C" locale is returned                                                                             
            if(cc == "C")                                                                                                                             
                cc = HWApplication::keyboardInputLocale().name();                                                                                     

LOL.

$ HOME=/tmp/t LC_ALL="" LANG=de_DE.UTF-8 LC_MESSAGES=en_US ./a.out              

en_US
en-US

Soo, I think that's pretty reasonable for "C" and clearly LC_MESSAGES is 
honoured.

Original comment by kyberneticist@gmail.com on 25 Mar 2015 at 4:42

• Changed state: Invalid

[GoogleCodeExporter]

Oh, and if the bug reporter is reading this.
$ LANGUAGE=de_DE LC_ALL=C ./a.out                                               

C
de_DE

With the sample program above.  That is, uiLanguages seems to prefer LANGUAGE 
over LC_*

But, that doesn't seem too useful, so not going to change anything.

Original comment by kyberneticist@gmail.com on 25 Mar 2015 at 5:45

[GoogleCodeExporter]

Hello, I am the original bug reporter in Launchpad.

Thank you for these tests.  There seems to be more at play here.  It seems that 
hedgewars get the locale information from different places and not 
consistently.  I can delete my ~/.hedgewars directory and still get a 
mixed-language interface and certainly not what I'd expect from the environment 
variables I gave.  I haven't yet made sense of it.

'LC_ALL="C" LANGUAGE="de" LC_MESSAGES=de LANG=de hedgewars' should definitely 
give me everything in English but about half the buttons or their tooltips are 
in German.  'LC_ALL="en_US" LANGUAGE="de" LC_MESSAGES=de LANG=de hedgewars ' 
does work and results in all-English as it should be.  I hope this is enough to 
convince you to have another, closer look.  Something is amiss here.

'LC_ALL="C" LANGUAGE="en_US" LC_MESSAGES=de_DE LANG=en_US hedgewars' should be 
all-English but also gives me half of German and half of English, depending on 
the button.

Original comment by rolf.leg...@gmail.com on 26 Mar 2015 at 4:34

[GoogleCodeExporter]

The status of this ticket was set prematurely. I hope you care more deeply 
about your software than this.

Original comment by rolf.leg...@gmail.com on 26 Mar 2015 at 4:36

[GoogleCodeExporter]

I run version 0.9.20.5-2 of the software package on Ubuntu trusty.

Original comment by rolf.leg...@gmail.com on 26 Mar 2015 at 4:40

[GoogleCodeExporter]

(please try 0.9.21 from trusty-backports)
https://help.ubuntu.com/community/UbuntuBackports

Original comment by costamag...@gmail.com on 26 Mar 2015 at 4:58

[GoogleCodeExporter]

That is a weird mess of flags there. My guess if you get half in one language, 
half in another, it may be due to our localised strings vs Qt's.

Frankly, I'm rather confused as to what you are trying to do, but I don't think 
using posix locale is a good idea.  If you want english, specify en. simple.

It is because we care about user experience in the first place that someone put 
that fallback there if posix is returned.  It is often an error. Pretty sure 
what you're doing is not typical or even a good idea.

Original comment by kyberneticist@gmail.com on 27 Mar 2015 at 2:58