Bug 65866 - utf-8 output needed for widgets
utf-8 output needed for widgets
Product: Red Hat Linux Beta
Classification: Retired
Component: libglade2 (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Depends On: 72693
Blocks: 67217 68332 68939 68949 69208
  Show dependency treegraph
Reported: 2002-06-03 07:49 EDT by Harald Hoyer
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-20 23:47:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Harald Hoyer 2002-06-03 07:49:00 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):

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()

add to glade_parser_parse_buffer() and glade_parser_parse_file():
    bind_textdomain_codeset(state.domain, "UTF-8");
Comment 1 Havoc Pennington 2002-06-03 08:57:47 EDT
See http://bugzilla.gnome.org/show_bug.cgi?id=83969
Comment 2 Harald Hoyer 2002-06-03 09:24:24 EDT
    bind_textdomain_codeset(domainname, "UTF-8");

maybe the gtk.glade.XML constructor should have that, too...
Comment 3 James Henstridge 2002-06-03 10:14:33 EDT
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).
Comment 4 Harald Hoyer 2002-06-03 10:53:34 EDT
since there is no python binding for bind_textdomain_codeset(), this is very
Comment 5 James Henstridge 2002-06-03 11:05:31 EDT
Well, the gtk.glade.bindtextdomain() function won't go away, and does call
bind_textdomain_codeset() for you.
Comment 6 Harald Hoyer 2002-06-03 11:07:37 EDT
workarounds, workarounds... without bind_textdomain_codeset(domainname,
"UTF-8"); the whole glade i18n is useless with gtk2 widgets...
Comment 7 James Henstridge 2002-06-03 11:35:10 EDT
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.
Comment 8 Havoc Pennington 2002-07-06 22:54:57 EDT
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?
Comment 9 Owen Taylor 2002-07-07 11:28:09 EDT
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....
Comment 10 James Henstridge 2002-07-07 22:25:36 EDT
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.
Comment 11 Aleksey Nogin 2002-07-18 19:20:00 EDT
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!
Comment 12 Havoc Pennington 2002-07-21 20:07:07 EDT
From the discussion people seem to be saying this is a bug in the apps, not
Comment 13 Daniel Walsh 2002-08-26 14:20:16 EDT
No this is definitely a bug in lib glade check out 72693 for description.

Note You need to log in before you can comment on or make changes to this bug.