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

[Vlad Harchev <hvv hippo ru>]

On 25 Mar 2001, Not Zed wrote:

 Hi, 

 Note: I'm talking about Evo-0.9 snapshot dated march 24 here.
 
> 
> > >  Thank you for your intents. Yes, utf8 can be considered a requisite for i18n,
> > > but it's not all that is needed. Here is a list of what is needed:
> > > 
> > > * charset in which messages are sent and transfer encoding in which mails are
> > >   sent has to be configurable by user (sending everything in utf8 is not
> > >   sufficient since there are email to pager gateways that are stupid, and
> > >   pagers don't like utf8), and utf8 is not always good idea due to size of
> > >   resultant representation (it's better to try to send messages in single-byte
> > >   charset).
> > 
> > Camel does this, it chooses the best charset for each mime part.
> 
> 
> I've seen reports of it using the "wrong" charset, or one that is not in
> common use in a given environment.  Camel's list of charsets is
> configurable, and based on what is available with libunicode's iconv()
> conversion function (it of course will not include its own charset
> converters) but nobody has told us what it should be doing, apart from a
> patch we've had from Russian people to fix it up for them.  Yes maybe it
> is not doing the correct thing right now, BUT the architecture is there
> for it, we just need a little guidance here ...

 OK, as Dmitry pointed out, user should have GUI controls for setting default
charset of the mails that are sent (Outlook allows to set this) - automatic
selection of charset is not sufficient due to traditions and the fact that not
all MUAs are properly configured to handle all charsets Evo can send mail in.

 Also as Dmitry said, it would be nice to be able to force some particular
charset while interpreting some mail (sites like hotmail.com and usa.net just
stick charset name of iso-8859-1 ..). OE has this ability.

 Ability to set charset of the particular mail while composing it would also
be nice (e.g. when sending mail to pager ot SMS gateway that understands
particular charset only or can't recode to others). OE doesn't have this
ability though..

 JFYI why this is important: russian can be encoded in 7 different and totally
incompatible encodings- that's why I'm very picular..

 Also ability to control content-transfer-encoding  (quoted-printable or
base64) would be very handy since there still may be some hosts that drop 8th
bit of the mail that passes by them. Evo always sends 8bit data..
 
> 
> > > 
> > > * Properly setting charset name in header and for each attachment of
> > >   text/plain type, properly encode body per settings
> > 
> > again, we do this too.
> 
> 
> definetly.

 Yes, I checked - it seems to work correctly.
 
> > > 
> > > * recoding the bodies/attachments and subjects of messages received to the
> > >  internal representation of MUA (utf8 in case of Evo).
> > 
> > yup, do this.
> 
> 
> Definetly.

 That works for only very few charsets camel knows about. For example, cp1251
used by most russian OutLooks (named "windows-1251" in headers) is not
known by libcamel. OK, I'll fix this myself (add cp866 and windows-1251 to
libunicode and rebuild camel-charset-map-private.h or how it's called).

 Currently for russian, when composing mail under locale with koi8-r charset,
it's sent in iso-8859-5 charset (that's probably OK), but when replying to
message sent in koi8-r the reply goes in utf8 for some unknown reason (may be
just because tries to send in iso-8859-5 that doesn't have all symbols koi8-r
has - and switches to utf8).

> > > 
> > > * properly dealing with charsets of any other data Evo deals with (calendar
> > >   and contacts)
> > 
> > can't speak for the calendar and addressbook, but I think they do.

 I didn't test them.

> > > 
> > > * when uploading mails to pilots etc message bodies and subjects have to be
> > >   recoded in the form Pilots expects (I didn't check this).
> > 
> > we don't yet sync mail with palms, but if/when we will (probably won't
> > happen until after 1.0?)
> 
> 
> I know the calendar stuff does, so of course pilot syncing would do
> this.  I'm simply boggled why it would even come up.

 I didn't test this..
 
> > > 
> > > * printing messages correctly 
> > 
> > I can't say for certain that we do this, but I believe that we do.
> 
> 
> I'm not sure how much postscript's limitations are a problem here
> either.

 In fact, printing of russian works almost fine - string widths are measured
incorrectly and sometimes it produces funny results - since
gnome_print_get_width_string is broken (ask Lauris if you don't believe - it
assumes that input string is in iso8859-1, not in utf8) and shouldn't be used!

On a side note, it for some reason uses the same colors as ones used for
display when printing - that's very disappointing (my gtk theme is SatinBlack
(dark one), so I get texts of my mails printed in white on white paper :( ).
 
> I have noticed one thing, and that is that html mail is always sent
> utf-8.  Now i dont know if this is an issue or utf-8 should always be
> supported by browsers, etc.

 Netscape *browser* doesn't handle utf8 htmls at all (don't know about its
mail client). So this should be dealt with too (another point in allowing user
to specify charset of mails that are sent).

 But I didn't  test html mail sending at all - all my notes apply only to
non-html mails.

 Also the major limitation the Evo has - is inability to handle 8bit texts in
subjects in "raw" form. A lot of MUAs send subjects in raw form - but evo
displays underscores for chars > 127 in subject AFAIR, so please fix
this - that's the most fatal flaw so far that makes it unusable even if it's
used only for reading mails (i.e. if not caring about encodings the messages
are sent with Evo are in)!

>  Michael
> 

 Best regards,
  -Vlad


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