Follow-up Comment #8, bug #8807 (project wesnoth):
Okay, I've been digging around some more in how Wesnoth acquires localised
strings; it uses GNU LibIntl for Windows. The documentation for that mentioned
that several environment variables influence what gettext does, so I had a
look at my environment variables. Sure enough, there was a LANGUAGE variable.
LANGUAGE overrides everything else and since it didn't follow the format
expected by LibIntl all text displayed in English.
Note: It said "LANGUAGE=Nederlands"; I think it must have been put there by
(the installer of) some other program.
Some observations.
* The average user would never have figured this out.
* There is only one environment namespace without any arbiter. Using any
nonstandard names, especially short reasonable ones, is inviting trouble. It's
incredibly bad architecture.
* There is an official way to determine the UI language; see here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd374098(v=vs.85).aspx
(Indeed, this must be what LibIntl uses when LANGUAGE and LANG are empty and
the second argument to setlocale is "".)
* Where the above yields something different from the LANGUAGE variable, the
LANGUAGE variable is wrong.
* Clearing the LANGUAGE variable when the program is running before selecting
a new language has no effect; this is probably because the program only calls
setlocale at the very beginning. So as it stands, once the override has taken
hold you can't get rid of it by selecting a different language.
* LibIntl should move away from environment variables; it already has a good
way to pass the desired locale to the library, namely via the argument to
setlocale.
* _putenv is deprecated.
What should for now change in Wesnoth:
* I think that pending a change in LibIntl the best thing to do is to clear
the LANGUAGE variable at the very start of the program.
SetEnvironmentVariableA("LANGUAGE", NULL) should do the trick.
* The setlocale(LC_ALL, "English") call at the start contains a malformed
locale and should probably be setlocale(LC_ALL, "") if I read the
documentation correctly. This is also probably how the present call gets
interpreted, but if some future version of LibIntl recognises "English" as an
alias for "en" then we could be in trouble.
* Of the two calls to SetEnvironmentVariableA, one of them is redundant; I've
tried skipping either call and though I didn't test extensively, it seemed to
work okay just the same. Since some work needs to be done to get to e.g.
"French" from "fr_FR", I suggest that unless we know that the xx_XX style
locale identifiers don't work everywhere, we get rid of the second call.
* Possibly use the second argument of setlocale instead of the LANG variable.
Pending a change in LibIntl, clear LANG at the start of the program, just like
LANGUAGE.
* Unless we're targetting Windows 9x without the Unicode layer, it's probably
better to use SetEnvironmentVariableW.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?8807>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
