I replied that, according to my (poor) knowledge of java, it was not currently possible (that is to say - not hackish). Is that true ? Is there any chance freecol could support that in a distant future ?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2007-June.txt, java uses LC_CTYPE to determine the default locale. As far as I know, java does not distinguish locale categories like LC_COLLATE or LC_MESSAGES. Nor is it possible to access environment variables directly these days (as explained here: http://www.javaworld.com/javaworld/javaqa/2001-07/01-qa-0706-env.html\). We could pass the LC_MESSAGES setting (or, indeed, all LC_* settings) via the command line if necessary. I would even implement that feature, provided that a localization expert tells me that LC_MESSAGES should be used for Unix-like operating systems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't think about a command-line option, but then, a simple --lang=... command-line option and a simple shell wrapper would do the trick. Probably the command-line option should be overridden by the saved configuration, because users would expect that if they change the language in the settings, it should be kept across game sessions (and should therefore override the always-given --lang command-line option).
Thanks !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Typical Unix behaviour would be to grant a command line option precedence over a saved setting. Therefore, the command line option should only apply to the default locale, which is used if nothing else was configured.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have added the command line switch "--default-locale=LOCALE" to FreeCol. A startup script could use this to set "--default-locale=$LC_MESSAGES", for example. However, I really consider this to be a java bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to add that I also consider it a Java bug. It's just that greater portability also means less specificity - therefore a somehow less smooth integration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, you might sacrifice the distinction between different LC classes for the sake of portability, but they still should not have used CTYPE to determine the locale.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
A user recently reported that freecol does not respect the LC_MESSAGES environment variable:
http://bugs.debian.org/450944
I replied that, according to my (poor) knowledge of java, it was not currently possible (that is to say - not hackish). Is that true ? Is there any chance freecol could support that in a distant future ?
Thanks
According to this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2007-June.txt, java uses LC_CTYPE to determine the default locale. As far as I know, java does not distinguish locale categories like LC_COLLATE or LC_MESSAGES. Nor is it possible to access environment variables directly these days (as explained here: http://www.javaworld.com/javaworld/javaqa/2001-07/01-qa-0706-env.html\). We could pass the LC_MESSAGES setting (or, indeed, all LC_* settings) via the command line if necessary. I would even implement that feature, provided that a localization expert tells me that LC_MESSAGES should be used for Unix-like operating systems.
Hello,
man locale is fairly precise: LC_MESSAGES is what governs the messages sent to the user; see there for instance:
http://linux.die.net/man/1/locale
I didn't think about a command-line option, but then, a simple --lang=... command-line option and a simple shell wrapper would do the trick. Probably the command-line option should be overridden by the saved configuration, because users would expect that if they change the language in the settings, it should be kept across game sessions (and should therefore override the always-given --lang command-line option).
Thanks !
Typical Unix behaviour would be to grant a command line option precedence over a saved setting. Therefore, the command line option should only apply to the default locale, which is used if nothing else was configured.
I have added the command line switch "--default-locale=LOCALE" to FreeCol. A startup script could use this to set "--default-locale=$LC_MESSAGES", for example. However, I really consider this to be a java bug.
I've just pulled it from SVN, and with the following script wrapper, it works like a charm !
if [ "$LC_CTYPE" != "$LC_MESSAGES" -a "$LC_MESSAGES" ]; then
lang_argument="--default-locale=$LC_MESSAGES"
fi
exec $JAVA -Xmx128M -jar /usr/share/java/freecol.jar --freecol-data \
/usr/share/games/freecol $lang_argument "$@"
(with some debian-specific stuff).
Great thanks for such a quick fix !!
I forgot to add that I also consider it a Java bug. It's just that greater portability also means less specificity - therefore a somehow less smooth integration.
Well, you might sacrifice the distinction between different LC classes for the sake of portability, but they still should not have used CTYPE to determine the locale.