Red Hat Bugzilla – Bug 65866
utf-8 output needed for widgets
Last modified: 2008-05-01 11:38:02 EDT
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):
Steps to Reproduce:
1. install e.g. redhat-config-network-1.1.0
2. sudo LANG=de_DE /usr/sbin/neat
wrong strings passed to set_text()
add to glade_parser_parse_buffer() and glade_parser_parse_file():
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
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
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
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
No this is definitely a bug in lib glade check out 72693 for description.