[i18n] Re: [imp] multibyte charset bugs and iconv support hack in imp (3.1)

[Jan Schneider]

Zitat von Viljo Viitanen <vviitane+mail.imp@mappi.helsinki.fi>:

> Me, last night:
> 
> > Multiple character set support with less than 15 lines added :) But I
> > haven't checked what might have broken with these modifications.
> 
> Replying/forwarding, of course.
> 
> The same iconv magic needs to be added in (3.1, again) imp/compose.php,
> before line 74 (return $data;):
> 
> ini_set('display_errors',0);
>
$conv=iconv(strtoupper($mime->charset),strtoupper($GLOBALS['registry']->getCharset()).'//TRANSLIT',$data);
> ini_set('display_errors',1);
> if ($conv != FALSE) {
>   $data=$conv;
> }

Though this (along with the other places you mentioned) might be a working
hack fixing the charset problem in a few lines - as you said yourself -, I'd
rather see another solution, see below.
 
> It would have been a good idea to make those lines a function, but this
> is
> just a hack, not a proper implementation. Also, there seems to be a bug
> in
> the header decoding routine (it fails sometimes), but I haven't dug into
> that yet.
> 
> Also, in distant future, it might be a good idea to start to store all
> user
> data in utf-8, and convert to whatever charset we're using on the fly.

Yes, that's definitely what I want to see i18n support in Horde heading to.
My idea (for IMP) is that we encode all data (ui and mail texts) to utf-8
and send it as-is to the browser if the browser supports this charset. It
might become difficult if the browser doesn't, there are several options:
1) We just try to convert everything from utf-8 back to the
ui's/translation's charset. Mails in other charsets won't be displayed
correctly (as now) but we probably will lose the feature to show the message
in it's original charset like we do it now.
2) We don't convert anything and keep everything as it is right now.
3) We drop support for not utf8-capable browsers completly.
4) We try to mix and match, keeping the translation's charset as long as
possible for _all_ browsers and only try to convert to either utf-8 or the
translation's charset if we need to and fall back to the old behaviour (show
link for the message) if we fail to convert. This would definitely the
solution with the biggest backward compatibility but a pain to implement and
a mess to keep it maintained.

All these solutions would need the iconv extension to be compiled into php.
So we also have to decide if we want to see this as another prerequisite
(more work for the admins) or put even more checks and switches into the
code (more work for us).
 
> (and now that I think about it, maybe I should have brought this up on
> the
> horde list, not imp.)

That's why I sent this reply to the i18n list, it's the appropriate list do
discuss this topic.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft