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

[bugs at bugs.horde.org]

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

*** shadow/1052	Wed Feb 12 11:55:55 2003
--- shadow/1052.tmp.20630	Wed Feb 12 11:59:33 2003
***************
*** 5,11 ****
  OS/Version: All
  Status: NEW   
  Resolution: LATER
! Severity: normal
  Priority: P2
  Component: IMP
  Area: BUILD
--- 5,11 ----
  OS/Version: All
  Status: NEW   
  Resolution: LATER
! Severity: enhancement
  Priority: P2
  Component: IMP
  Area: BUILD
***************
*** 435,437 ****
--- 435,464 ----
  I borrowed this idea from mutt (http://www.mutt.org).
  
  
+ 
+ ------- Additional Comments From jan at horde.org  02/12/03 11:59 -------
+ > |assumed_charset| is used not only for rendering the body
+ > of emails without 'charset' parameter in C-T header
+ > but also used for rendering the message headers which
+ > are NOT compliant to RFC 2047. RFC 2047 specifies that 
+ 
+ My mail server replaces all 8bit characters not properly encoded with "X" so
+ that has never been a problem for me. :-) But I see your point.
+ 
+ > > How do you build the list of possible charsets? Do you have such
+ > > a list somewhere? Do you use the available charsets fro nls.php > (lang.php in
+ > > your Horde version)?
+ > 
+ > Yes, I forgot to include my modified version of lang.php (now
+ > nls.php) to which I added an assoisative array. It's
+ > now available at http://jshin.net/i18n/lang.php
+ 
+ This gives me a blank screen. The PHP code probably gets interpreted.
+ 
+ > As for iconv and mbstring, my patch also relies on iconv. I didn't
+ > use mbstring, though. it appeard to me that  php's multibyte string handling
+ > (the last time I took a look) was a bit flaky.
+ 
+ Right. It's been getting better since then but still isn't perfect. Thus we use
+ both iconv and mbstring to have a fallback if one fails. Additionally we need
+ mbstring for multibyte safe string operations.