Re: report on [bad] status of i18n of gnome apps - somebody should explicitly care about it

[Colm Smyth <Colm Smyth Sun COM>]

> As for this particular problem  - I guess just moving iso8859-5 after koi8-r
>description in /camel/camel-charset-map-private.h will make koi8-r the
>default encoding for russian.

I realise in this case we're talking about a default, but it would make
things easier and more flexible if the association of encoding and
locales is configurable. GConf would be an excellent choice, but the
main thing is to make it configurable and thus adaptable; a user might
have a number of preferred encodings with some order of precedence.

Ideally we would have an API that provides information about the
association between locales and the preferred encodings so that
all GNOME applications would behave consistently in a specific
locale. This would be part of an i18n encoding API suite that
can do codeset detection and conversion.

One slight complexity is that there are recommended encodings for
specific contexts, for example Japanese e-mail is preferred in
ISO-2022-JP. The ideal configuration mechanism would store
a set of preferred encodings for each locale for a "default" context,
but also allow specific contexts to be configured independently,
like "mail" or "mime".

Also, in general whenever some transmittable content is being edited
(document, mail, appointment, ...) I think the user would benefit from
having the final choice about the encoding.

I'd welcome more discussion on the topic of dealing with multiple encodings
from other hackers interested in improving GNOME i18n, including Vlad and also
Yukihiro Nakai who has done the GNOME community a service with his i18n
development guidelines page at http://www.gnome.gr.jp/~nakai/i18n/.

Colm.

>Delivered-To: gnome-private-members gnome org
>Delivered-To: gnome-hackers gnome org
>From: Vlad Harchev <hvv hippo ru>
>X-Sender: hvv localhost localdomain
>To: val <frob df ru>
>Cc: Jeffrey Stedfast <fejj ximian com>, ettore ximian com, 
gnome-hackers gnome org, gnome-i18n gnome org, gnome-devel-list gnome org
>Subject: Re: report on [bad] status of i18n of gnome apps - somebody should 
explicitly care about it
>MIME-Version: 1.0
>X-BeenThere: gnome-hackers gnome org
>X-Loop: gnome-hackers gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: <gnome-hackers.gnome.org>
>X-BeenThere: gnome-private-members gnome org
>X-Loop: gnome-private-members gnome org
>
>On Mon, 26 Mar 2001, val wrote:
>
> Hi, 
>
>> JS> > * Properly setting charset name in header and for each attachment of
>> JS> >   text/plain type, properly encode body per settings
>> JS> 
>> JS> again, we do this too.
>> Hello
>> Evo 0.9.
>> LANG=ru_RU.KOI8-R.
>> charset-encoding in the mail-header == iso8859-5
>> 
>> (In Evo 0.8 it was "iso8859-1", so we have a big progress -- iso8859-5 is one 
of the "russian"
>> encoding =)
>> 
>> Try to explain why.
>
> As for this - that's not fatal since mail body is in iso-8859-5 too. All
>properly MUAs would be able to read that message.. I repeat - that's not
>fatal. (though I don't know whether Netscape Communicator knows iso-8859-5).
> But of course means for selecting charset the mails sent in should be
>provided to the user. That's mostly for compatibility with broken MUAs and SMS
>gateways.
>
> As for this particular problem  - I guess just moving iso8859-5 after koi8-r
>description in /camel/camel-charset-map-private.h will make koi8-r the
>default encoding for russian.
> 
>> Best wishes
>> Valek frob df ru
>> 
>
> Best regards,
>  -Vlad
>
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers