Re: [Evolution-hackers] i18 things

[Jeffrey Stedfast <fejj ximian com>]

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  -  evolution-hackers lists ximian com
> >http://lists.ximian.com/mailman/listinfo/evolution-hackers
> >  
> >
> 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com