On Tue, 2003-04-01 at 00:54, Alex Jiang wrote: > Thank you, Not Zed > > Some words I've said in the mail to fejj. Here I'ld like to add > something more. > > OK, It's understandable that camel not use gconf. Then the question is > whether we should convert subject things to UTF-8 as early as when reading > them from mbox, or delay the conversion to when we display it. > > I prefer the latter, but appying such modification maybe lead a disaster > to evolution...
this isn't doable. the strings need to be converted to UTF-8 right away, otherwise searching wouldn't be possible. Jeff > > And for each mail, mandatory charset is kind of necessary. where to > store it while > not broken the format of the summary file is quiz. I don't know beside the > user-defined tag, where else I could find a place. Besides, the > madatory charset > tag is just optional and perhaps is useful for very few mails. > > Best Wishes. > > >>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 > > > > > > > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
