I'm currently trying to create a project in Visual C++ on MFC that uses .po files to handle its translations. I have tried to integrate GnuWin32 Gettext but have met with several obstacles.
My program can set it's language independent of the system language. I've using setlocale(LC_ALL, "ja_JP") but the language doesn't change. I've treid putting the mo files files in several places but to no success.
The gettext function returns a char*. If I pass in a unicode string such as 'こんにちは世界', i will get '‚±‚ñ‚É‚¿‚Í¢ŠE'. I've tried to use bind_textdomain_codeset("sample", "UTF-8") but it doesn't help.
I've tried searching the net and found a gettext ported to windows by Franco and can get the translation using the gettext library provided by him but I still encountered problem 2 as stated above.
PLease, is there someone who can point me to the right direction? Thanks.
Thanks for the quick reply. Using SetThreadLocale() solved both of my problems. I also found that using bind_textdomain_codeset() isn't necessary. The test program was especially helpful. Once again, thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-28
There are two issues here that you need to understand:
Firstly the setlocale() function in the Microsoft C library does not accept locale strings in the same syntax as its counterparts on Linux (and (most?) POSIX systems in general). It does not use the ISO639 and ISO3166 language and country codes. Instead it uses a syntax like "Swedish_Finland.1252", i.e. the name of the language in English, followed by an underscore and the name of the country in English (and optionally followed by a period and the code page). In your case setlocale(LC_ALL, "Japanese_Japan") should do the trick.
The C library's locale affects things like whether to use decimal comma or point, names of weekdays as produced by strftime() etc.
The second issue is that even if you manage to set the C library's locale with setlocale(), that does not affect the locale of the thread as known to the Windows kernel. To do that you need to call SetThreadLocale(). And of course, this again uses a different form of locale identifier, a LCID. (This affects the current thread only, so if you call this you better do it early in the lifetime of the process if you intend to start more threads.)
The gettext library uses the GetThreadLocale() call to find out what language to use.
Note that the gettext library first looks for LC_ALL and LANG environment variables, so to affect just gettext, it is enough to set one of these environment variables. Not that unlike on POSIX systems, these environment variables have no effect on the C library, though.
The thread locale affects locale-specific things in the Win32 API, but not the C library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-11-28
> The thread locale affects locale-specific things in the Win32 API, but not the C library.
That is not entirely true. I forgot to mention that when you call setlocale(LC_ALL, ""), it is from the thread locale that the C library sets up its locale. (Before calling setlocale(LC_ALL, "") the locale of the C library is the default "C" locale, which is like en_US.)
--tml
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm currently trying to create a project in Visual C++ on MFC that uses .po files to handle its translations. I have tried to integrate GnuWin32 Gettext but have met with several obstacles.
My program can set it's language independent of the system language. I've using setlocale(LC_ALL, "ja_JP") but the language doesn't change. I've treid putting the mo files files in several places but to no success.
The gettext function returns a char*. If I pass in a unicode string such as 'こんにちは世界', i will get '‚±‚ñ‚É‚¿‚Í¢ŠE'. I've tried to use bind_textdomain_codeset("sample", "UTF-8") but it doesn't help.
I've tried searching the net and found a gettext ported to windows by Franco and can get the translation using the gettext library provided by him but I still encountered problem 2 as stated above.
PLease, is there someone who can point me to the right direction? Thanks.
Resources:
GnuWin32 GetText [http://gnuwin32.sourceforge.net/packages/gettext.htm]
Franco's GetText [http://freenet-homepage.de/franco.bez/gettext/gettext_win32_en.html]
Thanks for the quick reply. Using SetThreadLocale() solved both of my problems. I also found that using bind_textdomain_codeset() isn't necessary. The test program was especially helpful. Once again, thank you.
There are two issues here that you need to understand:
Firstly the setlocale() function in the Microsoft C library does not accept locale strings in the same syntax as its counterparts on Linux (and (most?) POSIX systems in general). It does not use the ISO639 and ISO3166 language and country codes. Instead it uses a syntax like "Swedish_Finland.1252", i.e. the name of the language in English, followed by an underscore and the name of the country in English (and optionally followed by a period and the code page). In your case setlocale(LC_ALL, "Japanese_Japan") should do the trick.
The C library's locale affects things like whether to use decimal comma or point, names of weekdays as produced by strftime() etc.
The second issue is that even if you manage to set the C library's locale with setlocale(), that does not affect the locale of the thread as known to the Windows kernel. To do that you need to call SetThreadLocale(). And of course, this again uses a different form of locale identifier, a LCID. (This affects the current thread only, so if you call this you better do it early in the lifetime of the process if you intend to start more threads.)
The gettext library uses the GetThreadLocale() call to find out what language to use.
Note that the gettext library first looks for LC_ALL and LANG environment variables, so to affect just gettext, it is enough to set one of these environment variables. Not that unlike on POSIX systems, these environment variables have no effect on the C library, though.
The thread locale affects locale-specific things in the Win32 API, but not the C library.
Check out this test program: http://tml.pp.fi/localetest.c which should show all the above aspects in great detail.
--tml
> The thread locale affects locale-specific things in the Win32 API, but not the C library.
That is not entirely true. I forgot to mention that when you call setlocale(LC_ALL, ""), it is from the thread locale that the C library sets up its locale. (Before calling setlocale(LC_ALL, "") the locale of the C library is the default "C" locale, which is like en_US.)
--tml