After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597801 - i18n problems with gtkbuilder on Windows
i18n problems with gtkbuilder on Windows
Status: RESOLVED INVALID
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.16.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-10-08 13:24 UTC by Tor Lillqvist
Modified: 2009-10-15 08:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample programs and message catalog provided by bug reporter (1.52 KB, application/x-tar)
2009-10-08 13:27 UTC, Tor Lillqvist
Details

Description Tor Lillqvist 2009-10-08 13:24:34 UTC
Paul Fertser mails gtk-list:

First of all, i'd like to thank you and all other developers for the cool
software and for all the help you've provided me so far.

I want to report a problem that is most probably related to the gettext
itself rather than to gtk and is (as far as i understand) caused by
weirdness of environment and data handling for windows DLLs.

The simple example (attached) creates a minimal window with translatable
strings. Message catalog location is set to "." on start, so when i place
ru.mo in ./ru/LC_MESSAGES/ and start in appropriate locale, i see
everything translated, just as expected. This is how it is supposed to work
and actually works on my Debian host.

On windows there're several problems:

1. Gettext called by gtkbuilder searches for translation only in default
catalog (messages.mo).

2. The default catalog needs to be located at absolute path, for the binary
version of gettext-runtime it's
c:\devel\target\771ce8fe54ee95a0ed4056d5304498cd\share\locale\ru\LC_MESSAGES

3. When i copy the catalog to that fixed location, gettext returns strings
in 8bit codepage (cp1251) which confuses Pango and no text is seen (no
bind_textdomain_codeset helps here).

Surprisingly, with the version of gettext-runtime for windows i
cross-compiled myself (0.17, the same as the binary), i do not experience
3.

So far, i'm now able to get my app to work in an acceptable manner in adhoc
way (3. is solved automagically, 2. can be fixed by patching
gettext-runtime prior to recompiling, 1. is workarounded by calling
gtk_builder_set_translation_domain()) but it would be nice to see a real
fix of course.

TIA
Comment 1 Tor Lillqvist 2009-10-08 13:27:21 UTC
Created attachment 145044 [details]
Sample programs and message catalog provided by bug reporter
Comment 2 Tor Lillqvist 2009-10-09 13:36:35 UTC
Guess what, the program works fine for me with the GTK+ 2.16.6 bundle from http://ftp.gnome.org/pub/GNOME/binaries/win32/gtk+/2.16/ . I have the "bin" from that in PATH, no other GTK+ related directories in PATH, and I verified with gdb that the DLLs really are from that bundle. I have i18ntest.exe in a folder, runb msgfmt -o ru/LC_MESSAGES/i18ntest.mo ru.po, and then run LANG=ru ./i18ntest. The label says Русский тест . 

(If a create a Swedish message catalog, and run i18ntest without any LANG environment variable, I get the Swedish translation just fine, too, as my Windows locale is Swedish (Finland).) 

I also tested with the 2.16.1 bundle, and with the 2.14.7 bundle, also worked fine.
Comment 3 Paul Fertser 2009-10-15 08:47:44 UTC
For the sake of other idiots like me it was indeed a problem between the chair and the keyboard. Sorry for wasting everyone's time :(

It appeared i didn't realise that gettext-runtime and gettext-runtime-dev archives are exactly those that contain libintl. So i downloaded libintl from gnuwin32. And completely forgot about that. Well, i'll try to do better the next time.