views:

72

answers:

4

I have a program where i18n is handled by gettext. The program works fine, however for some reason I need to know the name of the locale used by gettext at runtime (something like 'fr_FR') under win32.

I looked into gettext sources, and there is a quite frightening function that computes it on all platforms (gl_locale_name, in a C file called "localename.h/c"). However, this file does not seem to be installed alongside gettext or libintl, so I can't seem to call the function. Is there another function provided by gettext to get this value ? Or in another package (boost, glib, anything ?)

(On a related note, there is a thing called std::locale in the C++ standard library, and according to the doc calling std::locale("") should create a locale with the settings of the system, unless I am mistaken ... but then the name is 'C' under windows. Is it a viable way of getting the locale name ? What I am doing wrong ?)

A: 

You can use setlocale(NULL) to pull the locale from the CRT. But from Windows, I've got no idea. Also, gettext is a pretty generic function and you're going to have to be more specific about what gettext.

DeadMG
Not sure I understand your remark ... I'm translating strings with the gettext() function from gettext package ... at runtime it translate things fine both under GNU/Linux and windows in the two locales for which I have translated strings. However I need to know at runtime which is the locale of the user. I figured that since gettext (or maybe libintl ?) manages to do this, there must be a way to get it.
phtrivier
So I tried this : setlocale(LC_MESSAGES, "");char * l = setlocale(LC_MESSAGES, NULL);printf("Locale : %s\n", l);(After having fried a few of my neurons getting over the fact that to get the locale, you have to call, ahem, setlocale.)Under linux I get the proper locale, under windows (after cross-compiling with mingw-cross-env, neat package, go check it out), it just prints "(null)". I guess sometimes it's *really* time to go to bed.
phtrivier
+1  A: 

On Windows typically used function GetUserDefaultLCID which returns you integer value of locale identifier. To convert from LCID to string like 'fr_FR' you need to map it based on the info from http://msdn.microsoft.com/en-us/library/ms776260

bialix
Yes, I've seen the function mentionned in the multi-headed hydra that is "gl_locale_name" from the inners of gettext. The logic and the mapping has been done there also, I was secretely hoping I could just, you know, call a function and get the value since it has to be computed to translate any message. I guess my hopes are just too high. And it's time to go to bed.
phtrivier
@phtrivier you also should be aware that LANGUAGE environment variable affects the gettext and overrides the windows settings.
bialix
A: 

Boost provides a good library for working with locales. It even gives a few suggestions when attempting to get the locale. Read the intro bit. It may not completely answer your questions but I'm hoping either it will help or provide you with a usable library that makes working with locales simpler.

wheaties
Your link melted hopefully expandable parts of my brain, especially the parts where they tell me how I can generate a locale object in a few thousands neat ways, provided I know the locale beforehand. I will try again tomorow after a few hours of sleep, and maybe inhaling the blood of some member from the Heroes cast. They I'll see if I can get something from this page, and if the fact that the Boost.Locale library is not even part of Boost *yet* is too much of a problem. Did I mention it's time to go to bed instead of ranting ? Thanks anyway...
phtrivier
A: 

Turns out the "gl_locale_name" function was not part of gettext directly, but rather part of gnulib - http://www.gnu.org/software/gnulib. I just discovered the package today.

So getting the infamous localename.h header in my project was a matter of

gnulib-tool --import localename

Then the gl_locale_name function works just fine when cross-compiling.

Thanks to everyone for the answers !

phtrivier