Drupal has had a translation system for years. For as long as anyone can remember, it's been possible to run a Drupal site in languages other than English, and translations of the user interface have been conveniently downloadable from drupal.org. The ability to have translations of the actual site content has always been a challenge though, and it wasn't until Drupal 6 that the concept of different language versions of content was introduced.

Drupal 7 has some nice improvements in the translation area, but what might be an even bigger change since the last couple of years is the birth and wide adoption of the translation server.

I will do a quick run down of the different aspects of Drupal's language features, and the current state of things in this area.

Using a different language

The Drupal handbook talks about how you can install Drupal in a different language using the built-in Locale module. (A "different language" in this context means something other than English, which is Drupal's standard language.) The standard way involves downloading files manually from the translation server and placing them in a specific directory. Another way is to get the Localized Drupal distribution instead of the standard Drupal distribution, which will get you automatically set up with a language of your choice, and with the very handy tools Localization Update and Localization Client. (Installing these modules manually is also fine.)

Localization Update keeps track of the translations you've got installed on your site and syncs them against Drupal's translation server. If a translation is changed on the server, Localization Update will tell you there is an update and allow you to update your translation automatically. If you've ever used the Available updates page for modules, you will find it very familiar.

Localization Client helps you alter the Drupal translation on your site, that is, to add and change interface strings. Drupal has a built-in interface for this (which was greatly improved in Drupal 7 by the way), but Localization Client module will provide you with an on-page JavaScript based translation interface that is often a lot quicker to use. (More on this below.)

If you already installed Drupal and want to switch to a different language without starting over, you're in luck. You can still add a new language to the site and import translations for that language (automatically, with Localization Update, or manually).

Contributing to Drupal translations

I already talked some about the translation server as a repository for Drupal translations. However, it is also a great collaboration tool for all the language teams working on translating Drupal into their native languages. It has a brilliant interface for approving or denying suggested translations, highlighting the differences between versions among other things.

If you're interested in contributing to the translation of your language (of course you are), all you have to do to get started is to become a member of that language team (assuming you already have a drupal.org account). After that, you're ready to start submitting suggestions for the translation. If things work as planned, an admin will come by to process your suggestions. Maybe you want to become an admin yourself? Ask the language maintainer!

Once you've singed up as a translation contributor, you'll find that there is another way you can use the Localization Client module (and this is really what the "client" part is all about). It has a setting that allows you to submit translation suggestions automatically whenever you save a translation on your site. (Read the setting page's instructions carefully, as it requires that you fetch an API key for your account.)

Switching between multiple languages

It's possible to have multiple languages enabled at the same time on a Drupal site. Drupal 7 has a good mechanism for handling language negotiation, that is, determining which language should be activated when. The most common ways are a path prefix (such as domain.com/en/page), a separate domain or subdomain (like domain.com vs. domain.se vs. se.domain.com), and things like cookies and user settings.

To allow users to quickly switch between languages, Drupal provides a language switching block that automatically lists the available languages.

Translating content

This is all very good, but what's the point of switching between languages if all that is changing is the standard Drupal interface (texts like "Log in" etc.) and not the actual content? Drupal has built-in support for translating nodes (content items) into the languages that are active on the site. It works by actually creating a separate node for each translation of a particular content item, while keeping track of the translation relationship between these nodes. You enable this functionality on a node type basis, so you're able to decide which types of content have this ability.

In Drupal 7, there is now another possible way of having multiple translations of a piece of content. The new Field API is language enabled, which means that every field on a content object in Drupal 7 can potentially be translated. This type of content translation isn't implemented in Drupal core however, but there is a contributed module called Content translation which does this. These things are still a little experimental, and we still don't know exactly what the best practices will turn out to be for content translation in Drupal 7.

Trickier stuff

So, interface texts and content can be translated. What more could you possibly ask for? Well, Drupal core unfortunately doesn't take you all the way. The standard front page article feed will contain content of all languages, regardless of which language you've chosen, for example. Fortunately, the Views module has a language filter, and we're all depending on Views anyway, aren't we?

Then there is the kind of text that is neither built-in interface text, nor actual content, but more like configuration settings involving natural language. Take your site's name or slogan for example. Or, which is even more problematic, your site's navigation menu. These kinds of things are not handled by Drupal core, but there is the Internationalization module, which tries to remedy the situation.

Taxonomy terms is another thing that is not possible to translate out of the box, but Internationalization solves this as well. Another similar type of data is path aliases, but these on the other hand actually are language enabled in Drupal core itself.

In conclusion, most of these things can be dealt with, but in the end it turns out that developing a multilingual website on Drupal is far more complicated than a single-language site.

Alternative approaches for multiple languages

So, if multiple languages is such a pain, what can we do? Smaller projects might be better off focusing on core features and refining the implementation rather than building a true multilingual site. Maybe a couple of static pages in a secondary language would be enough?

Another option that should be considered is to actually have two separate Drupal sites, running in parallel on the same platform with all the same modules and themes. This would probably be a reasonable approach if the different language versions should be more or less isolated. With things like exportables and Features that save you from a lot of the old manual configuration, this approach could actually turn out to be quite manageable.

Further reading

Gábor Hojtsy has written an extensive article series on the language system(s) in Drupal 7: The basics, Community interface translation, Localization and language APIs, and Node translation. Another good place to start is the localization page in the Drupal handbook.