Re: GLib and translations



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]