Question

My web site (on Linux servers) needs to support multiple languages.
What is the best practice to have/store multiple languages versions of the same site?
Some I can think of:

1. store in DB
2. different view file for each language
3. gettex
4. hard coded words in PHP files (like in phpBB)

Answer 1

With web sites, you really have several categories of content to consider for localization:

1. The article-type content elements that you would in many cases create, edit and publish in a CMS.
2. The smaller content blocks that are common to every page (or a sub-group of pages), such as tagline, blurb, text around a contact form, but also imported content such as a news ticker or ads and affiliate links. Some of these may only appear for one language (for example, if you don’t offer some services in some regions, or don’t have, say, language-appropriate imported content for a particular language: it can be better to remove an element rather than offering English to people who may not speak it).
3. The purely functional elements, like “Click here to comment”, “More…”, high-level navigation, etc., which are sometimes part of your template. Some of these may be inside images.

For 1. the main decision is using a CMS or not. If yes, you absolutely need to choose one that supports multiple languages. I’m not up-to-date with recent developments in PHP CMS’s, but several of the Django CMS apps (Django-CMS-2, FeinCMS) support multi-language content. Don’t forget that date stamps, for example, need to be localized, too (or you can get around this by choosing ISO dates, though that may not always be possible). If you don’t use a CMS, and everything is in your HTML files, then gettext is the way to go, and keep the .mo files (and your offline .po files) in folders by language.

For 2. if you have a CMS with good multi-lingual support, get as much as possible inside the CMS. The reason is that these bits do change, and you want to edit your template as little as possible. If you write code yourself, think of ways of exporting all in-CMS strings per language, to hand them to translators. Otherwise, again, gettext. The main issue is that these elements may require hard-coding language-selection code (if $language = X display content1 ...)

For 3., if it’s in your template, use gettext. For images, the per-language folders will come in handy, and for heaven’s sake make choose images the generation of which can be automated, or you (or your graphic artist) will go mad with editing 100s of custom images with strings in languages you don’t understand.

For both 2. and 3., abstracting from the language selection may help selecting the appropriate blocks or content directory (where localized images or .mo files are kept).

What you definitely want to avoid is keeping a pile of HTML files with extensive text content in them that would be a nightmare to maintain.

EDIT: Everything about gettext, .po and .mo files is in the GNU gettext manual (more than you ever wanted to know) or a slightly dated but friendlier tutorial. For PHP, there’s are the PHP gettext functions, and also the Zend Locale documentation