[bugs] [Bug 1052] New - multilingual support in IMP is broken/misdesigned

[bugs@bugs.horde.org]

http://bugs.horde.org/show_bug.cgi?id=1052

*** shadow/1052	Wed Sep 11 06:24:29 2002
--- shadow/1052.tmp.26143	Wed Sep 11 06:24:29 2002
***************
*** 0 ****
--- 1,123 ----
+ Bug#: 1052
+ Product: Horde
+ Version: other
+ Platform: PHP Code
+ OS/Version: All
+ Status: NEW   
+ Resolution: 
+ Severity: normal
+ Priority: P2
+ Component: IMP
+ Area: BUILD
+ AssignedTo: chuck@horde.org                            
+ ReportedBy: jshin@jtan.com               
+ URL: 
+ Summary: multilingual support in IMP is  broken/misdesigned
+ 
+ Recently my school began to use IMP as its web mail program. I expected
+ it to do better than the one used before. I was very much disappointed
+ that IMP has all the problems Hotmail/Yahoo mail/Lycos mail and
+ many other web mail programs have when it comes to multilinugal 
+ support. 
+ 
+ IMP development  should NOT be targeted at emulating all those problems of
+ Hotmail and other commerical web mail services. Instead, it
+ MUST strive to be a web version of Mozilla-mail and MS Outlook Express
+ in terms of multilingual support. Both Mozilla-mail and MS Outlook
+ Express have excellent array of features to faciliate exchange
+ of emails in many different languages. For instance, a French user
+ can send Japanese emails, Korean emails, Russian emails, Chinese
+ emails as well as French emails  in a **standard-compliant** way.
+ With IMP, it's not possible. 
+ 
+ The foremost problem of IMP is that it makes a classical mistake
+ of tying the interface language (lang. used in user interface)
+ to the encoding/MIME charset of both incoming and outgoing
+ emails. UI language and encoding/MIME charset of incoming
+ and outgoing messages MUST be clearly decoupled. UI language
+ could be used to suggest to users what default MIME charset
+ be used when composing outgoing messages. However, UI-language-derived
+ default MIME charset should only be used when users don't
+ specify their choice. 
+ Users should be allowed to set their own default MIME charset
+ for composing outgoing messages as are the case of Mozilla-mail
+ and MS Outlook Express. 
+ 
+ 
+ IMP should let users  choose any encoding/MIME
+ charset of outgoing messages regardless of the UI language.
+ Let me take an example. A French user who sets her UI
+ lanugage to French MUST be able to set the encoding/MIME
+ charset of her outgoing messages to whatever she wants
+ it to be (ISO-8859-1, ISO-8859-15, UTF-8, ISO-2022-JP,
+ EUC-KR, GB2312, Big5, and so forth).  She should NOT be 
+ kept from selecting other encodings/MIME charset
+ for her outgoing messages. Currently, there's no way
+ to compose an email in an encoding different from
+ the encoding corresponding to the UI language without
+ breaking the various MIME standard. 
+  
+ 
+ Now as for incoming messages, she can receive messages
+ in various languages and encodings/MIME charset. When
+ individual messages are displayed, html emitted by IMP
+ should have meta tag setting the MIME charset of html
+ document generated by IMP to  to the MIME charset
+ of messages. Still better is that HTTP header include
+ the following HTTP header field (assuming the message
+ is encoded in GB2312)
+ 
+ Content-Type: text/html; charset=gb2312
+ 
+ However, this does not solve the problem of listing
+ a mailbox with messages in many different encodings.
+ Suppose the aforementioned French user has
+ Chinese and Japanese correspondents. Her inbox
+ can have Chinese messages in GB2312 and Japanese
+ messages in ISO-2022-JP as well as French messages
+ in ISO-8859-1. At the moment, she has to change
+ the encoding of her browser to Chinese(Simplified)
+ to view subjects/senders' name of Simplified Chinese
+ emails. With the encoding of her browser set to
+ Chinese(SC:GB2312), however, subjects/senders'
+ name of French emails and Japanese emails 
+ are broken. 
+ 
+ To solve this kind of problem, IMP should go all the
+ way to UTF-8 which can represent Chinese/Japanese/French
+ and many other languages in a single encoding. Below is
+ what Otto Stolz wrote to Unicode mailing list in July 2001
+ (http://www.unicode.org/mail-arch/unicode-ml/y2001-m07/0268.html)
+ 
+ OS> So none of these WWW interfaces is able to handle mail from, or to,
+ OS> non-Western partners; not even Sorbian, a minority language in our
+ OS> own country, nor the languages of our neighbours, Polish and Czech,
+ OS> can be handeled. For a university, this lack of functionality is
+ OS> plainly intolerable.
+ OS> 
+ OS> There is a simple solution for this problem:
+ OS> - encode all forms and other texts of the interface software in Unicode,
+ OS>   once and for all;
+ OS> - convert incoming mail to unicode;
+ OS> - talk to the browser in UTF-8;
+ OS> - accept input from the HTML forms in UTF-8;
+ OS> - send mail as is (in UTF-8), or convert outgoing mail to suitable 8-bit
+ OS>   (or even 7-bit) encodings, the user should have an option to suggest
+ OS>   the encoding for a particular message or addressee.
+ OS> But none of the WWW interface packages I have tried works this way.
+ 
+ 
+ This is exactly the way Mozilla-mail and MS Outlook Express work.
+ That's why they're so excellent I18Nized mail clients. Hotmail/Yahoo mail/
+ Lycos mail/IMP don't work this way and that's why their I18N support
+ is so poor. 
+ 
+ I realize that this report is kinda many bugs in one. Perhaps, this
+ can be regarded as a meta bug on I18N of IMP. 
+ My words may have been harsh in some places, but I really wish
+ IMP will become a truly I18Nized web mail client I've been
+ looking for since 1996. (it's really strange that so many
+ web mail services are broken almost the same way in terms of I18N). 
+ 
+ 
+