Drupal gets better and better with each release and its multilingual support is no exception. Drupal core provides for basic language support and content translation while contributed modules such as the Internationalization module package pour on the awesome sauce. Also, with Gábor Hojtsy heading up the Drupal 8 Multilingual Initiative (hojtsy.hu/d8mi), we know that Drupal 8 is going to be even more amazing.
Before we go multilingual, let's make sure we are all in sync in regards to terminology. You should already be comfortable with the standard Drupal terms before continuing. If words like node or entity or taxonomy aren't clear to you, check out the Drupal glossary at drupal.org/glossary. But, there are also lots of fancy words thrown around in the world of internationalization (see, I just used one!). So what exactly do they all mean?
Note
The word definitions shown next are based on their use in computing and software and, in some cases, are particular to Drupal.
A locale is usually defined as a collection of user information that includes language and location, but the core Locale module only deals with languages.
A numeronym is an abbreviated word where numbers are used to replace letters. Numeronyms are shown in parentheses for some of the terms.
Internationalization (i18n) is the procedure of creating software so that it can handle multiple languages and geographical locations.
Localization (L10n) is the action of updating software so that it can be used for a particular language or region. The numeronym for localization usually starts with an uppercase letter because a lowercase "L" looks like an uppercase letter "I" in some fonts, but module names always use lowercase letters, for example,
l10n_client.Translation is the process of converting text from a source language to another language such that the meaning of the text is preserved as much as possible.
A translation set is a collection of objects that includes a source object and all translated versions of the source object. For example, an English source node along with its German and French translated nodes, comprise a translation set.
The term interface (or user interface or UI) will be used to refer to all the textual information coming from code which may be shown to the user on the website.
The word content will generally be used to represent information that is captured in entities (nodes, comments, users, taxonomy terms, and custom entities).
The term config (or configuration) will typically be used to refer to the ad hoc conglomeration of everything that is not considered "interface" or "content."
The abbreviation und comes from the ISO-639 specification and is short for undetermined. You may come across this abbreviation in your database, in code, and in data arrays.
Now that we have our terms clear, let's take a step back and look at the big picture. We will be configuring a lot of different things in the coming chapters. At a high level, these can roughly be separated into the three distinct areas of interface, content, and configuration as defined previously.
The book chapters are roughly divided into these parts with Chapter 2, Setting up the Basics: Languages, UI Translation, and System Settings, focusing heavily on the user interface, Chapter 3, Working with Content, on content, Chapter 4, Configuring Blocks, Menus, Taxonomy, and Views, on standard configuration and Chapter 5, Panels, SEO, and More!, on advanced configuration.
 |
When you create a Drupal site, you end up with a user interface that has lots of textual information presented to you. Looking at the login block alone, there are the Username and Password field labels, the Log in button text, and a couple of links for creating an account and requesting a password. When we want to use Drupal in another language, all these little bits of text need to be translated into that language and the system needs to know what to do with them.
 |
Drupal requires modules and themes to use the t() function for text that will be displayed in the UI. (The 't' is short for 'translate'.) If I write a module and have the text This is the best module EVER! in it and want that text string to be translated into other languages, then I can use the text as follows:
print t('This is the best module EVER!');
This lets Drupal know that I want my string to be available for translation. Drupal won't automatically translate the text for you unless it already has that exact string stored away in some other Drupal code and someone has provided the translation.
Fortunately, a lot of Drupal core's UI is already translated into many languages so that part of the battle is won if you want to use one of those languages. You can use the Localized Drupal Distribution install profile (drupal.org/project/l10n_install) to make it easier. The trickier part is when contributed modules or your own code have strings in them that aren't yet translated like in the previous example, or you find missing or broken translations in the core interface. This interface translation process will be covered in Chapter 2, Setting up the Basics: Languages, UI Translation, and System Settings.
When talking about content in Drupal 7, we are mainly thinking about entities (nodes, comments, users, and taxonomy terms). Sure, there are other bits of content floating around the site in views headers, custom block bodies, and panel panes, but we will lump those different non-entity bits in our all-encompassing 'configuration' bucket.
In Drupal 7, entities can have fields (similar to CCK in previous Drupal versions). This has made content translation for nodes more flexible as well as more confusing. In previous versions, if we wanted to translate nodes, we ended up with a separate node for each translation. We can still do this in Drupal 7, but now we can also translate fields with the help of the Entity Translation module where we are only working with one node. In the field translation model, we can translate any of the fields into our various languages. The following figure illustrates the differences between these two methods:
 |
One of the biggest issues with translating nodes in Drupal 7 is that we have to choose between the node translation model and the field translation model for each content type. This is one of the major hot buttons for the Drupal 8 Multilingual Initiative and will definitely be addressed in Drupal 8. To better understand the trade-offs involved, we will work with both of these models in Chapter 3, Working with Content.
Although core content translation is only available for nodes, field translation via the Entity Translation module can be used for other core entities (comments, users, and taxonomy terms) and some custom entities. For example, if you have a user Bio field or a comment Internal notes field, you could choose to translate those fields.
One oddball to mention is taxonomy. You can use field translation for taxonomy term fields and you can also translate vocabularies and terms with the Taxonomy Translation module. The former falls under the "content" area whereas the latter is in the "config" bucket, so it's a bit confusing. These methods will be explored in Chapter 3, Working with Content, and Chapter 4, Configuring Blocks, Menus, Taxonomy, and Views.
Although interface and content translation are both pretty well-defined and understood, the world of configuration is varied and sometimes complex. There is no configuration API (though that will likely change in Drupal 8), so how we deal with the multitude of config pieces is not very uniform.
Currently, Drupal core doesn't provide much multilingual support beyond the basic foundation, so we end up using a lot of contributed modules. The Internationalization module provides most of the help with 14 submodules. This module has been around since Drupal 4 and is still a lifesaver for Drupal 7. There's talk that much of the Internationalization module package functionality will end up in Drupal 8 core.
Chapter 2, Setting up the Basics: Languages, UI Translation, and System Settings, will mainly focus on the UI, but we will also spend time on the configuration for system functionality such as variables, dates, and the contact form. In Chapter 4, Configuring Blocks, Menus, Taxonomy, and Views, and Chapter 5, Panels, SEO, and More!, we will work through the multilingual configuration of blocks, menus, taxonomy, and views and then move on to some more advanced topics including panels and SEO.