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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
