Re: en_US.po
- From: Noah Levitt <nlevitt columbia edu>
- To: Owen Taylor <otaylor redhat com>
- Cc: Matthias Clasen <maclas gmx de>, Sven Neumann <sven gimp org>, carlos gnome org, gtk-devel-list gnome org, gnome-i18n gnome org
- Subject: Re: en_US.po
- Date: Thu, 6 Mar 2003 11:56:30 -0500
Is there a problem with documentation strings using
non-ascii characters?
I'm not quite sure what the conclusion is about console
strings. Are you saying there aren't any?
To my surprise, this code
g_print ("foo ª»ÌÝÝî ‘ooo’\n");
gave me this output
foo ?????? ?ooo?
with the locale set to en_US.UTF-8.
I wonder what this means for other languages and encodings.
Noah
On Thu, Mar 06, 2003 at 10:58:41 -0500, Owen Taylor wrote:
> On Thu, 2003-03-06 at 08:52, Matthias Clasen wrote:
>
> > Maybe it would be a good idea if the pot files would contain comments to
> > tell the translator if a message is going to be displayed on the console or in
> > the ui, so that the translator can use a restricted character repertoire for
> > console messages and provide "nice" messages for the ui. I guess one way to
> > achieve that would be to use separate domains for these messages...
>
> Yeah, though it would be even more important to split GTK+ into
> two domains:
>
> - One for user visible strings
> - One for doc strings
>
> Because right now, getting GTK+ 100% coverage is a major job,
> but the vast majority of those strings have no relevance to
> end users.
>
> I don't think there are actually many translated messages in GTK+
> that are exclusively displayed on the console ... we don't
> mark warning messages for programming errors for translation ...
> rather we have GError strings which might occur either on
> the console or on the screen.
>
> I have to agree with Sven that as of right now, we shouldn't
> use non-ASCII/latin-1 characters in the GError strings.
>
> But perhaps we should consider making the g_logv() and g_print()
> functions do smart fallbacks and if the target encoding doesn't
> have nice quotes, convert them to vertical quotes.
>
> (A little difficult because the behavior of iconv() for characters
> not in the target encoding is completely undefined, but not
> impossible ... g_convert_with_fallback() has logic in it for
> similar situations)
>
> Regards,
> Owen
> Z
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]