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
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.