Description of Problem: Reading glade files with translatable strings results in: *** Invalid UTF8 string passed to pango_layout_set_text() and broken strings Version-Release number of selected component (if applicable): libglade2-1.99.12-4 How Reproducible: Steps to Reproduce: 1. install e.g. redhat-config-network-1.1.0 2. sudo LANG=de_DE /usr/sbin/neat Actual Results: wrong strings passed to set_text() Solution: add to glade_parser_parse_buffer() and glade_parser_parse_file(): bind_textdomain_codeset(state.domain, "UTF-8");
See http://bugzilla.gnome.org/show_bug.cgi?id=83969
./gtk/libglade.override:_wrap_glade_bindtextdomain() ... #ifdef HAVE_BIND_TEXTDOMAIN_CODESET bind_textdomain_codeset(domainname, "UTF-8"); #endif .. maybe the gtk.glade.XML constructor should have that, too...
My comments from GNOME bugzilla: It is the application's responsibility to set up its translation domains. Libglade simply makes use of the translation domains set up by the application. People don't expect gtk_init() to fool around with their domains, I wouldn't have thought they would expect libglade to either. The gtk.glade.bindtextdomain() function is included in the python bindings because there is no wrapper for it in the standard library (the gettext module in python does not call into the C gettext lib). In python 2.3, apparently there will be a locale.bindtextdomain() function to do the work (I don't know if it will handle the codeset part though -- might be worth checking).
since there is no python binding for bind_textdomain_codeset(), this is very complicated...
Well, the gtk.glade.bindtextdomain() function won't go away, and does call bind_textdomain_codeset() for you.
workarounds, workarounds... without bind_textdomain_codeset(domainname, "UTF-8"); the whole glade i18n is useless with gtk2 widgets...
Without bind_textdomain_codeset(), any gtk2 program will have issues. If this is an issue at all, then it is with gtk 2.0, or gettext.
Has this been resolved in some way? I'm not sure I understand what the issue is or if one remains. Our config tools work right?
I don't fully understand the problem here; if the Python libglade bindings have gtk.glade.bindtextdomain(), they should have gtk.glade.bindtextdomain_codeset() as well. The situation seems very parallel. *Someone* needs to call the C gettext function, since liglade is using the C gettext. Or libglade needs to provide a hook to subsitute a different translation function. We typically run in a UTF-8 locale and use UTF-8 .po files, so most of the time we won't see this problem. But for CJK locales we aren't using UTF-8 currently....
The gtk.glade.bindtextdomain() function was added to work around the lack of such a function in the standard python library (which should be addressed in Python 2.3). We added gtk.glade.bindtextdomain() as a convenient way for Python programmers to set up a translation domain for use with libglade. As libglade requires that the translation domain return UTF-8 strings, it calls bind_textdomain_codeset() for you (if it is available). However, the glade_xml_new() constructor does not call bind_textdomain_codeset(), as it simply _uses_ a translation domain that has already been set up. From what I can tell, there is no bug here. Libglade expects you to pass in a translation domain that returns UTF-8 strings. We provide a function to set up a translation domain with its codeset set to UTF-8. If I am missing something, please provide some more information.
In Limbo, I get a huge number of ** (up2date:7550): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() when running with ru_RU.KOI8-R and a huge number of ** (up2date:7728): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() when running with ru_RU.UTF-8. in both cases it seems that many places whene some text is supposed to be are just shown blank!
From the discussion people seem to be saying this is a bug in the apps, not libglade.
No this is definitely a bug in lib glade check out 72693 for description.