§ Translator Contents

When you have sites in multiple languages you may notice, depending on your server configuration, that particular languages may not be displayed properly in browsers. And yet when you save the file and view it they display fine. Here's what happens and how you can fix it.

This is a particularly perplexing problem and may affect some users of Angsuman's Translator Plugin Pro, a professional plugin to transform your blog automatically to 13 (in version 4.0; in testing) other languages. However it is in no way caused by or unique to the plugin. You will see the problem in any multi-lingual site(s) or sites where the server isn't configured to properly handle the language.

Fortunately there is a simple solution.

The problem is caused when a default charset is specified in the web server configuration, which doesn't match the language of the file. A simple solution to this problem is to remove / comment out the default charset. If you are using Apache HTTP server then open conf/httpd.conf (most likely in /etc/httpd/conf/httpd.conf) and search for AddDefaultCharset. Make sure that the line is commented as follows:
#AddDefaultCharset UTF-8

Apache documentation also recommends it, albeit in a roundabout way:

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually. One such example is to add the charset parameter to resources containing generated content, such as legacy CGI scripts, that might be vulnerable to cross-site scripting attacks due to user-provided data being included in the output. Note, however, that a better solution is to just fix (or delete) those scripts, since setting a default charset does not protect users that have enabled the "auto-detect character encoding" feature on their browser.

Update: For WordPress blogs you have to unset the charset in options.