Hi. This post is a response to: http://lists.otrs.org/pipermail/dev/2007-February/001488.html At Wed Feb 21 14:01:25 2007 +0800, Tietew wrote:

There is a big problem to use OTRS in Japanese that; many web-based MUAs, such as Hotmail and Yahoo, and some popular MUAs, such as Microsoft Exchange and Lotus Notes, does not support UTF-8!

Therefore, customers which use these MUAs cannot read mails sent from OTRS. They can read mails encoded in ISO-2022-JP only. My OTRS must send mails as ISO-2022-JP.

This is not necessarily problematic only on Japanese language but also on the others: If outbound mails are encoded using UTF instead of legacy charset, probablly some (even ``many'' on some languages) customers cannot read them. --- Why spammers (:-|) usually send mails using legacy charset, not using UTF at all?

I cannot use ISO-2022-JP as OTRS UI. Because: 1. ISO-2022-JP is insecure for web applications. ISO-2022 series is stateful encoding and contains \x1B escape sequence. It's very hard to handle stateful encoding correctly for web applications. 2. I want to share one OTRS installation and its queues in multilingual project team. Non-Japanese team can or must use UTF-8. And, OTRS must be able to send ISO-2022-JP mail even if user uses English UI.

In other word, I do not want Japanized (locally patched) OTRS.

-----

My suggestion is to create "mail character encoding" to queue settings (defaults to UTF-8, or empty meaning system default charset). for example,

info-en queue uses 'UTF-8' or '' info-ja queue uses 'ISO-2022-JP'

A mail composd mail in info-en queue is encoded as UTF-8. A mail composd mail in info-ja queue is encoded as ISO-2022-JP.

This solution seems to make them happy that all users in all languages.

I posted a patch to Bugzilla, based on the idea as described above: http://bugs.otrs.org/show_bug.cgi?id=2793 Some notes: - In general, internally used legacy charset (e.g. euc-jp for Japanese) can be differ from that actually encodes email message (e.g. iso-2022-jp ditto) so that we avoid from suffering with insecure charsets while determine repertoire of legacy codesets. Although, auto-conversion features are wrapped into external CPAN modules. - New language file ja.pm for Japanese is imcomplete and not proofread (there may be inappropriate terminology etc.). So I won't post this message to i18n list for now. Is this solution desirable? -- IKEDA Soji, Conversion Co., Ltd.