8.3. UnicodeUnicode

Before RT 3.0, RT was language-agnostic. The user interface was in English,^[*] and RT didn't do anything special with the text entered by users. As long as you only used the web interface, it worked OK. Users in Japan could enter text in Japanese. Users in Spain could enter text in Spanish. When RT tried to send mail, the recipient wouldn't be able to read it, since RT didn't know enough about the content of the message to correctly label it.

^[*] End users painstakingly translated the entire application into three or four different languages.

RT 3.0 changed all that. The interface has been fully internationalized,^[] and weve standardized on Unicode and the 8-bit UTF-8 encoding. This means that you can use English, Spanish, Russian, Japanese, Korean, and Chinese in the same message, and RT will store and display them just fine.

^[] Well, almost fully, it doesnt deal quite right with right-to-left languages like Hebrew and Arabic yet.

When a user connects to RT's web interface, RT tells his browser that it should speak to RT in UTF-8. Because the web came into being after the advent of Unicode, most every web browser knows how to speak UTF-8.

Sadly, the situation isn't so rosy in the world of email. Every language has its own encoding, sometimes even two or three of them. For email, RT has to do all of the hard work. When it receives an email message, it has a look at the message headers to see if the sender told us what encoding they were using. If the sender didn't tell RT, it uses the Perl module Encode::Guess to look at the message's content and guess what the most likely encoding is. Once RT knows what encoding an incoming message is in, it converts the message to UTF-8. When sending messages back out, RT looks at a site's list of preferred encodings, picks the most apropriate one, and re-encodes the message.