Re: Should gtk call bind_textdomain_codeset() also for glib20?
- From: Owen Taylor <otaylor redhat com>
- To: Tor Lillqvist <tml iki fi>
- Cc: gtk-devel-list gnome org
- Subject: Re: Should gtk call bind_textdomain_codeset() also for glib20?
- Date: Fri, 8 Mar 2002 00:46:09 -0500 (EST)
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
strings.
* 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
implementation.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]