Multi-lingual WordPress with Apache2 and Content Negotiation via index.html.var

That’s a mouthful, isn’t it. In short, I’m writing this little tutorial for those that need to maintain a WordPress site in more than one language. This particular setup is geared toward WordPress, but the techniques can be used for other html files and Content Management Systems. First, use Apache’s new index.html.var file. You will find a copy in your default webroot that comes with a default Apache installation. This index.html.var file will take the place of your index.html or index.html.xx file residing in your root directory. Without getting too technical the file is just a mapping of user language requests to appropriate localized content wherever it may be.  It’s way more flexible than MultiViews. To create a two language WordPress site, one for Spanish and one for English, I set up the two blogs on the same codebase (WordPress 2.0.4). The base URL for Spanish is /es/ and for English is /en/. I also wanted my users to be drawn from the same users table (no sense in having them register twice for the site). Place the following line your wp-config.php define ('CUSTOM_USER_TABLE', 'YOUR_TABLE_PREFIX_users'); Where YOUR_TABLE_PREFIX is wp_ or whatever is in the variable $table_prefix for your common users table. Also, in order that your users won’t have to log in twice in case they visit both the English and Spanish sites, we’ll have to modify the cookie paths. Basically, if you login in English then pass over to the Spanish, your login will stay valid (rather than prompting you to login again). We need to modify the wp-config.php in both directories to make sure where ever the user enters first, that login sticks. In your es directory put the following in your wp-config.php: define ('COOKIEPATH', '/en/'); In your en directory put the following in your wp-config.php: $public_cookiehash = md5(''); define('USER_COOKIE', 'wordpressuser_'. $public_cookiehash); define('PASS_COOKIE', 'wordpresspass_'. $public_cookiehash); define ('COOKIEPATH', '/es/'); The result: if you login to the English side and then get a hankering for Spanish, your login stays valid. If you are feeling a little latino at first and then later decide to peruse some English content, your login stays valid. ¿Entienden?

Apache and Content Negotiation

Place the index.html.var file I mentioned before in your base directory / with the following mappings for my localized blogs. URI: /en/ Content-language: en Content-type: text/html URI: /es/ Content-language: es Content-type: text/html Normally, in the default index.html.var, maps to Spanish content, and index.html.en maps to English content. I didn’t want that, since the base directory is meaningless and empty except for index.html.var. My actual localized content is in the respective directories /es/ and /en/. I didn’t want a splash screen asking the user to choose his/her language either. The computer should comply with the user’s browser preferences. If a Spanish speaking user has their language preference configured as Spanish, Apache should very well give it to them. You can think of index.html.var as Apache mod_rewrite specifically geared towards internationalization. Now any English-speaking request to will negotiate to and Spanish-speaking requests map to As usual, I write this because the process is so simple no one thought to spell it out quite so explicitly. To sum up: index.html.var has replaced the MultiViews directive in Apache, is more flexible, and will help you out way more than trying to write php, mod_rewrite, or javascript to replicate the same functionality.

You may also like...