Re: [Evolution-hackers] i18 things

[Not Zed <notzed ximian com>]

On Mon, 2003-03-31 at 17:53, Alex Jiang wrote:
> Hi, 
> 
> I am now working on i18n issues of evolution.
> 
> There are several things I think we should do to improve the i18n
> performace of evolution.
> First, c the patch for bug 40519. which make sure whenever we call
> iconv, there is a 
> charset(locale_charset for default), so a uniform manner is applied. 

I would tend to agree with Jeff on this.  This patch doesn't make much
sense overall.

I would also add that camel relies on the charset sometimes being NULL. 
It means no charset set.  It doesn't mean us-ascii (although for valid
mail messages ... it does), so none of the camel changes should ever
occur.

> Secondly, display charset should be stored in gconf(for each
> folder(vfolder?)). Or, when 
> we change the display charset,  functions like 
> process_header()/header_decode_string() will 
> not be affected(and it's not easy to pass the chosen charset to them),
> which may lead 
> to bug 40521 . i.e. those multibyte subject/sender... which not
> following rfc2047, will not 
> be readable(But this happens very often)

There is no point for this.  Also, camel cannot use gconf.  We already
have access to the locale stuff from e-iconv.  And if we needed to do
processing for broken and invalid emails, this can be done higher up, as
part of the display code (which it is for most parts).

> Third, when we open evolution twice in different locale, the summary
> file will not be rebuilt.
>  So, improperly converted subject/title will remain unreadable. One
> possibly runnable way is 
> to make summary in a "mbox.ev-summary.gb2312","mbox.ev-summary.en"
> way. But the final 
> solution is that we be ablet ot change the summary file when we change
> the charset of a mail 
> (c the next item) or of a folder.

Again, this is only an issue with broken email programs sending out
broken emails.

This is not an acceptable suggestion.  At most, we could perhaps add a
flag as we do with message bodies, which says 'this string was broken,
it isn't in utf8', but thats very painful to maintain.

> Fouth, we should be able to madatorily change the charset of a single
> mail. so perhaps a UI 
> method will be introduces first(e.g. when we change the charset in the
> mail window, the mail's 
> charset will be changed, while we change in the folder view, folder
> charset will be affected). 
> Perhaps, to keep the wholesome of the summary file, a user-defined tag
> in the CamelMessageInfo 
> struture will be used to define the charset of a single mail.

No.

> I believe with these steps, the i18n problems now exist in evolution
> will be finally solved.  (By now, 
> I haven't touch gtkhtml, so for  bug 40520,  I don't know why). It
> really needs a lot of work, 
> so before I make any patches, I hope to receive your kind suggestions.
> 
> Thanks a lot.
> 
> Alex Jiang