Re: GLib and translations
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GLib and translations
- Date: Thu, 23 Aug 2001 17:25:27 +0200 (CEST)
On 22 Aug 2001, Owen Taylor wrote:
>
> Currently, in GLib, translated error messages are not in UTF-8. In GTK+,
> all .po files are in UTF-8, and we call bind_textdomain_codeset() to
> make sure that they don't get translated back for non-UTF locales. We
> don't do this in GLib.
>
> I think this is pretty clearly wrong ... if you try to display a translated
> error message in a dialog, it will be in the wrong encoding. However,
> we do need to deal with the common:
>
> g_message (_("Error reading file %s"), error->message);
>
> Thinking about this, I think we should make g_logv(), and probably also
> g_print() translate from UTF-8 to the encoding of the locale.
hm, i'm feeling a bit uncomfortable about doing more stuff
in g_logv(), especially if it's going to to call out new code
portions that are already, or might one day, use g_malloc() and
friends.
i don't think the prime problem is the idea to use utf8 conversions
in g_logv() however. instead i think we should just change our
g_malloc() error/warning handling in order to not use g_logv() there
anymore, so we're pretty free to use normal API in g_logv() and
its handlers. it's not like this'd be a huge problem, in case malloc
throws an error and aborts the program, you can't display that
via a log handler in a message window anyways ;)
i don't like the idea of changing g_print() however, it's simply
doing printf()'s job without including stdio.h and should stay
that way. this just reminds me, somenoe should finally implement
g_errprint() doing the equivalent of dprintf(2) or fprintf(stderr).
> Things are going to be perfect until everybody uses UTF locales, but
> this should make things better.
>
> Thoughts?
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]