[rt-users] Remaining issues in RT 3.0.2's handling of international characters

[Remy Chibois]

Quoting Dirk Pape <pape-rt at inf.fu-berlin.de>:

My config:
RT: Version 3.0.2
OS: RedHat Linux 7.3
Apache: 1.3.27 with SSL
Modperl: 1
DBS. PostgreSQL 7.2.3
Perl: 5.8.0
LANG=en_US.iso885915 (tried LANG=C)
sbin/rt-testdepedencies happy with all installed perl-libs

For problem 2, the same symptoms are observed here. Is does not appear
to depend on the message itself (I have to RT instances and when a message fail
to be converted, I inject it in the other instance where it's correctly
converted, having all incoming messages saved in a mailbox before being
inject into RT). When I restart Apache, problem is cured for some time.

When I swtiched from 3.0.1 to 3.0.2, some localized strings where no longer
correctly displayed in the web interface, especially localized strings with
arguments. I try(ied) to elaborate a patch for this.

> Hello,
> 
> I start this thread to collect the observed issues still in RT 3.0.2
> when 
> handling international characters (like German Umlauts) in Emails or in
> the 
> Web-Interface.
> 
> This is the only group of issues that make me hesitating in making RT 3
> 
> productive on my site.
> 
> So I start with my config:
> 
> RT: Version 3.0.2
> OS: Debian Linux Woody
> Apache: 1.3.26 with SSL
> Modperl: 1
> DBS. mysql
> Perl: 5.8.0
> sbin/rt-testdepedencies happy with all installed perl-libs
> 
> my issues (please add your's and your comments):
> 
> 1. wrong ISO-8859-1 encoding of outgoing From-headers with umlauts in
> it, 
> eg. in '"RT/MI (Sebastian Lück)" <lueck at inf.fu-berlin.de>' the part
> '"RT/MI 
> (Sebastian Lück)" <lueck' is in a whole bracketed with ISO-8859-1?... 
> brackets, hence MUAs fail to sort by email adresses.
> 
> temp. WORKAROUND: do not use umlauts in Real Names stored in
> RT-User-Prefs
> 
> 2. from time to time incoming (non-utf8) Email will not be converted any
> 
> more to utf8. It will though be marked as being converted, but in real
> 
> contain ISO-character-encodings. I have to be vague here, because I
> cannot 
> reproduce any trigger of this behaviour. But if this happens, it seems
> to 
> stick for one apache process.
> 
> To be more specific I add some observations:
> 
> A. If this behaviour is triggered, some (but not all) later incoming 
> messages are not being converted correctly (as described before).
> 
> B. Because of the wrong encoding they display corrupt in the Web-view
> and 
> in email notifications to customers or admin are corrupt, too.
> 
> C. If I restart apache the problem is cured for a while (one or some
> days) 
> (This could be stated as a temp. WORKAROUND). The corrupt messages which
> 
> are stored in the DBS remain corrupt.
> 
> Because Jesse asked me to do, I forwarded all email messages coming to
> RT 
> in an external message box. The copies are never seen by RT. From this
> 
> follow the following observations:
> 
> D. The incoming messages are correct. It is RT, which corrupts them in
> 
> between accepting them and storing them into the DBS.
> 
> E. I tried to re-feed the messages (bounce them to the rt-address) into
> RT 
> in the same order they arrived before after restarting apache. I could
> 
> *not* trigger the problem reproducable with this, hence it should not
> spend 
> on one specific mail.
> 
> Tell me anything I can do further to trap the problem's cause and I will
> 
> try to do.
> 
> Dirk.
> 
> _______________________________________________
> rt-users mailing list
> rt-users at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-users
> 
> Have you read the FAQ? The RT FAQ Manager lives at
> http://fsck.com/rtfm
>