GNOME Bugzilla – Bug 676543
Cannot load translations from a locale dir other than the default
Last modified: 2012-05-24 07:44:56 UTC
Not sure if I should file this one here or against pygobject, so please feel free to move around if necessary. I've got an application that needs to be installed in /opt, and I've noticed that its translations are not loaded by GtkBuilder. It turns out that even if I specify the location to load them from (with gettext's bindtextdomain() function), GtkBuilder ignores that and tries to find them in '/usr/share/locale'. I've also tried to use the gtk-builder-set-translation-domain() function to explicitly set the domain for GtkBuilder, but that did not make any difference. I'd probably rather need a gtk-builder-bind-text-domain one, which does not exist. In any case, I don't quite follow why gtk-builder-set-translation-domain() is needed at all and GtkBuilder does not just pick the translation domain and the locale dir values from gettext. In short, GtkBuilder ignores any attempt to define a locale dir and just uses the default from the system. I'm attaching a Python example for testing purposes. To run the example: * Copy the build/share/locale/ca/LC_MESSAGES/testglade.mo file to /tmp/share/locale/ca/LC_MESSAGES * Run the app with LANGUAGE=ca ./testglade.py Notice that the message output on the command line is translated, whereas those from the UI are not. I'm also aware of this old PyGTK bug [2], but none of the tentative workarounds there work to make GtkBuilder load translations from another location than '/usr/share/locale'. Any help or comments would be appreciated, thanks! [1]: http://developer.gnome.org/gtk3/stable/GtkBuilder.html#gtk-builder-set-translation-domain [2]: https://bugzilla.gnome.org/show_bug.cgi?id=574520
Created attachment 214641 [details] Test app to reproduce the bug
Just some quick notes: > In any case, I don't quite follow why gtk-builder-set-translation-domain() is needed at all It's not necessary. You can set it if your .ui files use a different domain than strings in the actual source code of your application. But that's not the common case. I had a quick look at the source, and there is no obvious reason why GtkBuilder translatable strings should not Just Work. _gtk_builder_parser_translate() just calls g_dgettext(), so as long as bindtextdomain() and textdomain() are called before loading the .ui, it should be alright. I haven't seen the test case yet (no attachment yet), but if that does set the locale properly and early enough, and GtkBuilder doesn't spit out translated attributes, we indeed have a bug.
Thanks Martin, that makes it clear why the gtk_builder_set_translation_domain() method is there for these special needs. For some reason the attachment didn't make it in the original report, but it should have been there by now, at least I can see it listed in here.
I've found a solution: use the locale Python module instead of gettext import locale from locale import gettext as _ locale.bindtextdomain('qreator', '/opt/extras.ubuntu.com/qreator/share/locale/') locale.textdomain('qreator') Thanks to Juha Sahakangas on the #gtk+ IRC channel for providing the explanation: For this particular case the locale module needs to be used instead of gettext. Python's gettext module is pure python, it doesn't actually set the text domain in a way that the C library can read, but locale does (by calling libc). So long as that's done, GtkBuilder already works the way you're asking it to. So in summary, this seems not to be a bug in GtkBuilder, so I believe it can safely be closed.
(In reply to comment #4) > So in summary, this seems not to be a bug in GtkBuilder, so I believe it can > safely be closed. Doing so... :)
Ah, thanks David for the investigation! Nasty trap to fall into indeed..