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

[Vlad Harchev <hvv hippo ru>]

On Thu, 12 Apr 2001, Colm Smyth wrote:

  Hi, 

> > 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.

 Yes, I was talking about that in that thread that continued on
evolution-hackers.
 The summary of the thread is: user has to have ability to select default
encoding for outgoing mails, for each particular outgoing mail (useful for
sending via broken SMS gateway), ability to select content-transfer-encoding
of the subject field for sent mail (since most list managers don't suppot QP
as CTE for subjects, raw 8bit in subjects may be preffered, at least inside
intranet), and have ability to select charset using which some particular
message should be interpreted (overriding charset specified by message headers
- useful for mails sent via usa.net and other broken www mail interfaces that
mark all letters as iso8859-1).
 
> 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.

 Yes, such API is a requirement when dealing (most importantly - exporting)
with files from OSes where only single encoding can be used for a particular
locale (e.g. cp1251 for russian under Windows and MacCyrillic for Macs). While
extending gnumeric and AbiWord with ability to export files under locales
different from iso-8859-1, I had to add such tables that map locale to
encoding.

> 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".

 Yes, it would be nice to have this ability.  I think it's easy to achieve
this if application allows user to configure all aspects of i18n via GUI or at
least by editing configuration files directly. In that case all that is needed
for arbitrary configurability based on context is making configuration
settings storage mechanism searching for "system-wide fallbacks" in the
location specific to the locale - e.g. if it was possible to direct gconf to
look into the following files in the given order for program running under
e.g. "ru_RU.KOI8-R" locale:
	/etc/gconf/gconf.xml.defaults/schemas-ru/*
	/etc/gconf/gconf.xml.defaults/schemas-ru_RU/*
	/etc/gconf/gconf.xml.defaults/schemas-KOI8-R/*
	/etc/gconf/gconf.xml.defaults/schemas-ru_RU.KOI8-R/*
	/etc/gconf/gconf.xml.defaults/schemas/*
 If that was possible, the only thing needed is shipping correct
locale-dependant defaults and installing them in locale-dependant directories!  
App Defaults for X Resources are searched in a similar way at least by Xt
library. (Hint to gconf hackers - could you implement such lookup order
please?) I think it's a cleanest way of possible - just names of configuration
settings should be standardized so that all applications would be able to use
them.

> 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 think it's a must for any software considering itself sensible and usable.
Even Outlook allows to configure this!

> 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/.

 It would be nice if discussion would be followed by some real work. :) 
 I'm ready to be hired to do it! :)

> 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 regards,
  -Vlad