Re: Should gtk call bind_textdomain_codeset() also for glib20?

Owen Taylor <otaylor redhat com> writes:

> Tor Lillqvist <tml iki fi> writes:
> > Shouldn't gtk_init_check() call
> > 
> > 	  bind_textdomain_codeset("glib20","UTF-8")? 
> > 
> > Otherwise localised error strings from GLib (used at least in
> > gtkfilesel.c) might be in some random codeset?
> > 
> > What about error messages from strerror() (through g_strerror()), they
> > are presumably in the locale's default codeset, and should be
> > converted with g_locale_to_utf8()?
> This area is a mess, and something that we can't really deal with
> right now before 2.0.0.
> I sent mail to this list some while ago saying that the GLib
> translated strings should in fact be in UTF-8, and the 
> g_print(), g_warning(), etc, functions should do encoding conversion
> to the encoding of the locale.

OK, thinking on this some more, I don't think we can implicitely
let this issue slide and have people start calling g_locale_to_utf8()
where they shouldn't. What I'm planning to do before the release tomorrow
morning is:

 - Adding bind_textdomain_codeset.

 - Add the following embarrassing release notes to glib/README.

* On systems without the libintl from GNU gettext() or a recent version
  of the GNU C library, the encoding of translated error messages will be 
  incorrect (they should be in UTF-8). A workaround for this is to install 
  GNU gettext and use that libintl. This is expected to be fixed in GLib-2.0.1.
  Application programmers should not call g_locale_to_utf8() on these

* The results of g_strerror() are currently in the encoding of the locale
  rather than in UTF-8. Again, this is a bug, and not behavior that
  should be relied upon.

* Similarly, the GLib error logging functions such as g_print(),
  g_warning(), g_error(), currently do not convert the strings they
  are passed from UTF-8 to the encoding of the locale, or check that
  the strings they are passed are valid UTF-8. They should, despite
  this, be assumed to take UTF-8 arguments.

If I get ambitious, I'll fix g_strerror() ... shouldn't be hard to do a simple


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]