Re: [Evolution-hackers] i18 things
- From: Jeffrey Stedfast <fejj ximian com>
- To: Alex Jiang <alex jiang sun com>
- Cc: Not Zed <notzed ximian com>, evolution-hackers lists ximian com, Ettore Perazzoli <ettore ximian com>, Suresh Chandrasekharan <Suresh Chandrasekharan eng sun com>
- Subject: Re: [Evolution-hackers] i18 things
- Date: 01 Apr 2003 01:09:45 -0500
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.
> 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.
> >>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
> >>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.
> >>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 - evolution-hackers lists ximian com
> evolution-hackers maillist - evolution-hackers lists ximian com
Evolution Hacker - Ximian, Inc.
fejj ximian com - www.ximian.com
] [Thread Prev