10
Dec
2013

How to set up a "simple" multilingual Drupal 7 website using field (entity) translation

Drupal icon saying Hola and Hello Do you need to set up a "simple" multilingual site with Drupal 7, using the future-looking Field translation method? Learn how to create a small website where the public content switches between many languages, but editors only use one language.

Two types of translation on multilingual sites

There are two ways to set up translation on your multilingual Drupal 7 (D7) site. This tutorial assumes that you:

  • use the newer Field translation method, (via the Entity Translation module) and
  • do NOT use the old Node translation method (via the core "Content translation" module).

Why use Field translation?

  1. Your site will be able to more easily migrate to Drupal 8.
  2. Your editor's experience is consistent; they can translate content using a similar method throughout the site.
  3. When your site links to one of its pages using different addresses (especially different node IDs) for each translation of that page, it is confusing for your editors and your SEO.

Strange, but important, definitions

We've already learned that D7 defines field translation and content translation differently. This section will explain some other potentially-confusing, but really important, concepts in multilingual D7.

Every site must have a "default language" in which all its links and messages intially appear. Although this is not very difficult to understand, I want to emphasize how important it is that you carefully choose your default language when starting to build a site. You will later be required to use this language for the FIRST version you create of almost all content and changing the default language after you've added content will break your site.

Unlike the previous definition, the distinction between "User Interface" (UI) and "Content" was one of the most uniquely-defined concepts I encountered. Three parts of what D7 classifies as User Interface (rather than Content) can make translating them difficult: menus, blocks, and taxonomies. This post will only discuss menus and blocks (because I don't using taxonomy on my multilingual site).

Strings are those bits of text that come directly from Drupal or its contributed modules. An example might be the message you see after saving a page, or the word "Preview" on the button at the bottom of a page you're editing. D7 has an entirely separate "Translation Interface" (at admin/config/regional/translate/translate) where you can translate these standardized words and phrases. However, because my editors are only using the default language, this post mostly ignores string translation.

Module choices

There are a confusing number of multilingual-related modules in the Drupal world. Each module listed below is accompanied, when helpful, by notes explaining:

  • the module version (at the time of this writing)
  • which of its submodules should be enabled
  • the submodules you should NOT enable
  • what job the module does for your site

Modules NOT to use

For this site, I recommend that you do NOT install or enable these multilingual modules:

  • Content translation (version 7.24 in Core): uses an old way of translating that is removed in Drupal 8. It is possible to enable this at the same time as Entity Translation and use it for only some content types, but I don't recommend doing so.
  • Localization update (also known as "l10n_update") and Localization client (also known as "l10n_client"): both help improve translations of the standard text strings within Drupal (and other modules), but don't help you with translating your actual content.

Modules you MUST install

For this multilingual site, install and enable these modules and submodules:

  • Locale (Core, version 7.24): required for everything multilingual to work.
  • Entity Translation (version 7.x-1.0-beta3, as well as its submodule, Entity Translation Menu): provides an interface for editors to translate parts of your site and lets a single page (using the same node ID) have multiple translations.
  • Title (version 7.x-1.0-alpha7): lets you translate the default "Title" field on any piece of content, which is otherwise forbidden in D7.
  • Transliteration (version 7.x-3.1): transforms the names of your web address paths and uploaded files into universally displayable, unaccented characters.
  • Variable (version 7.x-2.3, none of its submodules): required for the Internationalization module to work.
  • Internationalization (version 7.x-1.10, also known as "i18n"): lets you translate the "User Interface" parts of your site and creates a "Language switcher" block so you can easily switch between languages. Only enable individual submodules if your site needs what they provide (see this guide to the i18n submodules). For this site, I recommend enabling these submodules:
    • Field translation: lets you translate a field's LABEL (not its content).
    • Block languages
    • Menu translation
    • Path translation
    • String translation
    • Translation sets

There are two optional modules you might also consider installing (if your site needs them):

Basic multilingual configuration

Warning: Do NOT create any content, menus, etc. until you have FINISHED your multilingual setup. Otherwise, your content may not have the right language information attached to it.

Language settings

The default language of my site is English, but I also added a second language so my pages can have translations (at admin/config/regional/language). For each language I set the "path prefix" so that the current language will show in the web address (for example: mysite.com/en/node/2 or mysite.com/fr/node/2).

Next, I found the "Language switcher block (Content)" under admin/structure/block and moved it to a region in my theme where I could see it easily.

We need our site's interface (menus, error messages, etc.) to remain in English when editors are logged in. To make this happen, I instructed my editors to choose "English" as the Language setting in their user account, and then I set a specific order as to how languages were detected on the site. So, for my site's Language Detection settings (at admin/config/regional/language/configure) I chose:

  • User interface language detection: User at the top, then URL below.
  • Content language detection: URL at the top, and Interface below.

If interested, you can read this more detailed explanation of Language Detection options.

Translation format settings

To let fields be translated using different text input formats, you need to choose which formats (such as "plain text") to make translatable (at admin/config/regional/i18n/strings).

Content types and fields

A page is the most common type of content, but every content type will need to be enabled for translation using the below steps. Repeat these translation-enabling steps whenever you create new content types or add new fields to existing types.

First, to configure entity translation for each content type (at admin/config/regional/entity_translation):

  • choose "enable entity translation",
  • set the default language to "English",
  • and check both "Hide language selector" and "Exclude Language neutral from the available languages".

Next, configure translation settings on the content type itself (at admin/structure/types/manage):

  1. On the main "Edit" tab under "Publishing options", choose "Enabled, with field translation" and "Hide content translation links".
  2. Under the "Manage fields" tab, replace the "Title" field.
  3. From that same tab, edit each remaining field and check the box next to "Users may translate all occurrences of this field" (except for fields that need no translation, such as email addresses).

Your next place on this journey is the Translation Interface itself (at admin/config/regional/translate/i18n_string), where you need to choose the checkboxes for fields, menus, and blocks, and then click on "Refresh strings".

"Refresh strings" tells the site which translatable fields exist, and also allows you to translate a field's label. Because most of my field labels are not visible to external users, I only translated the labels for my fields (at admin/config/regional/translate/translate) on ONE content type (a public biography and contact page for each staff person). Remember: whenever you add more fields, menus, or blocks, you need to 'refresh strings' again.

Menus

According to the all-purpose guide, there are two ways to manage menu links with entity translation:

  1. One multilingual menu (and its single block) that has every link for every language together.
  2. A menu (and its block) for each language, with:
    • editors putting links into different menus based on each translation's language, and
    • each block's language visibility used to display or hide that menu.

My theme requires the "main menu" in a hard-coded region, so I chose the first option: one big multilingual menu.

Regardless of which menu method you choose, you will need to:

  1. Edit each menu (at admin/structure/menu/manage/main-menu/edit) and, under "Multilingual options" for that menu, choose "Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized."
  2. Refresh strings again for menus and blocks (at admin/config/regional/translate/i18n_string).
  3. Train editors to create ALL menu links FROM the actual page, because there's no easy way to specify which translation to choose if adding links from the menu editing screen. Under "Menu settings" for each page, they should choose "Menu link enabled only for the THIS language".
  4. Train editors to change the order of links on the menu editing page (at admin/structure/menu/manage/main-menu).

Blocks

For this last part of the D7 "Interface", I recommend that you create separate blocks for each language because:

  • using the Translation Interface to translate strings is not user-friendly and
  • block translations don't let you use a text editor on translated body fields, so you would often have type html code (see i18n issue on Drupal.org).

For some blocks, the all purpose guide says it might even be "be easier to just create a new content type and display the translated data with a View."

However, separate blocks for each language will result in managing a large number of blocks. My solution is two-fold:

  • Train editors to name blocks in a standard way, so it is easy to find them later.
  • Consider using the Context module to better manage your many blocks (see slide 14).

If interested, you can read this more detailed explanation of the approaches to block translation.

For more information

I am indebted to the authors of these books and articles for teaching me about multilingual in D7: