Internationalization of a Drupal 7 based Website

A couple of years ago I was responsible for implementing the internationalization (i18n) of a company’s website which was built on the Drupal Content Management System (CMS), version 5 at this time. Now that I had this task again in a different project, I realized that i18n with Drupal is still after years pretty much a pain and that you need to read through many documents in order to get your stuff conveniently running. Helping me and others in future, I noted down what I needed to do for the current Drupal 7 release.

Enabling i18n

The standard Drupal 7 release claims to ship already i18n capabilities, but they will not be enough for many standard requirements.

First of all you need to enable the usage of multiple languages.

  1. Install the Variable module (API dependency).
  2. Install the Internationalization module.
  3. Optional, but probably always wanted: Install the Language icons module (adds flags to language switchers).
  4. Go to Administration -> Modules. Enable modules:
    • Multilingual content
    • Menu translation
    • Block languages (if you also want a language switcher as a block)
  5. Go to Administration -> Configuration -> Regional and language -> Languages, add languages and configure your desired website behaviors.
  6. Enable translations of your content.
    1. Go to Administration -> Structure -> Content types.
    2. Edit appropriate content type, select tab “Publishing options”, select for “Multilingual support”: “Enabled, with translation”.
    3. I also recommend to check option “Require language (Do not allow Language Neutral).” at tab “Multilingual setting”.

If you followed these steps, you should now see a new tab “Translate” at each node (of the i18n enabled content types). How to translate the nodes should be self-explanatory now. The good thing here is that you can enter different settings for each language (e.g. user comments are allowed only at the English version).

Optional cleanup

Some subjective optical improvements:

  • To remove the language switching links at every page, but let the user only switch with the help of the language block:
    Go to Administration -> Configuration -> Regional and language -> Multilingual settings -> Multilingual settings -> Node options and check “hide content translation links”.
  • To hide the “Language” label on every page:
    1. Enable module “Field UI”.
    2. Go to Administration -> Structure -> Content types and click on “Manage display”.
    3. Select “Hidden” for field “Language”.

Front page

If you use a custom front page (i.e. the website’s home/start), you will realize that the language switcher simply does not work here. That happens because the site configuration value for the front page path is stronger than the language parameter. This is the workaround of this issue, that I found on Julia’s blog:

  1. Go to Administration -> Modules. Enable modules:
    • Path
    • Variable translation
  2. Edit your front page, select tab “URL Path settings” and define a URL alias, e.g. “home”.
  3. Set exactly the same URL alias value (in this example “home”) at the translated version(s) of the front page.
  4. Go to Administration -> Configuration -> System -> Site information and specify the URL alias value for “Default front page”. Do this for all available languages (at the first box of the configuration page you can select the language. This also enables you to specify a language specific site name).

Internal links: Use URL alias

Note that the i18n will create a separate node for each language. Example: The “About Us” page has three nodes:

  • node/10 (English)
  • node/11 (German)
  • node/20 (French)

If you want to link to this page from another internal page, it can lead to unexpected content: If you have a hyperlink to node/10 (page’s English version) in a node with German content, the new page opens with a German menu, but English page content.
The solution here is to configure a URL alias for all your pages as shown for the front page and always link to the appropriate alias.

Other modules

Unfortunately, it appears that quite a lot of (not so popular) Drupal modules did not consider i18n at all. Often times they contain fixed output strings in the source code so that it requires some coding to support language switching, which leads to dependency management risks. Other modules, such as the FAQ module, use the variable translation pattern in the same way as we used it for the front page path value. Note that you need to enable each variable at Administration -> Configuration -> Regional and language -> Multilingual settings -> Multilingual settings.

User E-Mails

E-mail texts which will be sent automatically to the users can be translated at Administration -> Configuration -> People -> Account settings. Just make sure that the “Variable translation” module is enabled and you enabled translation of user e-mails at Administration -> Configuration -> Regional and language -> Multilingual settings -> Multilingual settings -> Variables -> User emails.

And that is already the basic setup for a Drupal based multi-language website. Now you only need to hope that all the modules will still work perfectly together in future.
I am not really an expert for CMS products, but I guess it is worth it to evaluate also other systems in case you are about to start a new website project which requires i18n.


Tags: , ,

One response to “Internationalization of a Drupal 7 based Website”

  1. Axib says :

    I recommend using this crowd localization platform for translating Drupal: It has a plugin, API and a useful translation memory.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: