Re: [Evolution-hackers] i18 things

[Alex Jiang <alex jiang sun com>]

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

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  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
>