Re: [Evolution] i18n buglets

[Not Zed <notzed ximian com>]

On 31 Mar 2001 20:41:47 +0200, Ladislav Lhotka wrote:
> On 01 Apr 2001 00:25:09 +0930, Not Zed wrote:
> > Hmm, this is actually rather hard to do with the way the code works.
> >
> > What its trying to do for example is try and find words that are
> > us-ascii so it can just put them in without encoding when it can (i.e.
> > to aid readability), and you've just hit an edge case :(  (which i'm
> > sure comes up in practice often with these character sets).
>
> I believe it's best - even for readability - to represent such a header
> field as a single enconded-word. Cases when this is not possible should

I disagree actually.  The encoded format is terribly unreadable.  We
dont want to merge the whole subject into a single encoded word just
because one word needs it.

> be quite rare, for example when a subject exceeds the maximum length of
> 75 chars. Perhaps a simple and efficient solution might be to configure

This happens quite a lot, especially when you start encoding stuff, but
the code needs to deal with it anyway  (i think right now it guesses and
it is approximately good enough).

> a charset for each account and then Evolution could discriminate only
> between us-ascii and this charset when the user is composing mail under
> this account.


We probably have to do that for various reasons anyway, although I am
not sure exactly how this is going to work, because of the abstraction
of the messaging library from the mail client code.

Any thoughts dan?  We could possibly grab the charset from the header
parameter and try and use that, but that probably isn't very good
either.  What about adding a default header encoding member to
camelmimemessage?  Are there headers outside of camelmimemessage's
headers that might need to know this info?  We could also use this when
creating a message perhaps to get around the broken 8 bit headers
problem, etc (and that still doesn't handle the problem of iconv not
knowing a given charset)?  Although I dont know how we can get access to
such info from the providers, have it settable per store, and the folder
code can set it on the message before it loads it/summarises it, etc?

Or is a single global definition enough?  Let me guess, people will want
to set it per message when they're mailing out, so no.

 !Z