Drupal 7 Multilingual Sites: A hands-on, practical guide for configuring your Drupal 7 website to handle all languages for your site users with this book and ebook

Jacob is a writer and has his own website where he blogs about his life and his work. He is fluent in English and Italian, and has a family in Italy where he often goes on vacations. He writes articles in English or Italian depending on the subject. He sometimes translates the blogs so that they are available in both languages, but not always. Jacob does freelance work in the United States. So his work-related content only needs to be in English. He is the sole user for his website but he allows comments to be left in both languages.

AJ Consulting is a small consulting company in Santa Cruz, California. Drawing from the large Hispanic community in the area, they have several bilingual employees who are fluent in Spanish and English. They specialize in catering to clients who need their services in either language. It is important that they maintain all site content in both languages, so their bilingual employees are in charge of translating content. All content must be approved by the owner prior to being published. The only users of the website are company employees. The general public is not allowed to leave comments anywhere on the site, but they can use the contact form in either English or Spanish.

Deutsch & Sons is an online store selling educational toys and books for young children. They sell their products internationally but mostly within the United States, Canada, and Mexico. To cater to their international market, they keep their product, store, and customer support content in English, French, and Spanish. They have different shipping and taxation handling based on the shipping country. Deutsch & Sons does not have any staff translators, so they rely on third-party translators who directly modify the site content.

To make things more realistic, our demo site has elements from the examples mentioned previously including blog articles, book content, comments, and user roles that allow more than one content contributor. You can use the demo website or your own site for the book exercises. The book is structured as a step-by-step tutorial. So, for maximum understanding, the best strategy is to work through the chapter exercises in order.

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.