Re: [Evolution-hackers] i18 things

[Jeffrey Stedfast <fejj ximian com>]

On Mon, 2003-03-31 at 03:23, 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 don't like this patch.

1) US-ASCII does not ever need to be passed in to iconv(), and so
therefor e_iconv_charset_name() is perfectly fine returning NULL.

2) (e_iconv_init): The second parameter of setlocale() from NULL to "".

does passing NULL cause it to crash on Solaris? or what is the reasoning
for this change? If it is to prevent a crash or something, I'm fine with
it.

3) I don't see why you want to always set the locale charset. if the
default locale charset is just going to be US-ASCII (which is what it
HAS to be), what difference does it make? Just leave it as NULL.

4) I also don't think we should do a default locale_lang. First, we
don't even use it yet - but that is irrelevant. The reason I left it
NULL is that it will be useful in the composer in that we will clearly
see that the user does not have a locale language setup - and therefor
we should skip setting a lang on the message (or prompt the user or
something, which we should maybe do anyway).

5) No need to have e_iconv_charset_guess() so that e_iconv_init() can
parse it and construct a iconv-friendly name for it because it should
ALREADY be in whatever form the system's iconv() will want. Besides,
e_iconv_open() will always pass both to/from charsets into
e_iconv_charset_name() and so even if we use the locale_charset value,
it will still be transformed into the iconv-friendly charset name.

> 
> 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)

I don't understand your proposal here?

> 
> 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.

No. This is The Wrong Way (tm) to fix it. the mbox.ev-summary files
store everything in UTF-8 so there only ever has to be ONE.

The only solution here is to ban people from using broken crap mailers
that don't set the charset(s) correctly. :-)

it should be possible to change the code to render the message header
block in the "preview pane" according to the user's picked charset (if
it doesn't already) by grabbing the raw headers from the mesage object I
suppose? kinda yuck, but oh well.

changing the message-list is not doable.

> 
> 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 don't really like this idea...

> 
> 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.

I'll let the gtkhtml guys make comments about this.

Jeff

> 
> Thanks a lot.
> 
> Alex Jiang
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com