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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
