About this book

Drupal is one of the most powerful and popular PHP Content Management Systems at the moment. By making your site multilingual, you are opening the door to a whole new user base, in as many countries as you like. Use the localization and internationalization features of Drupal 7 to automatically detect where your site users are visiting from and select the content appropriate to them. The world is your oyster!

Drupal 7 Multilingual Sites guides you through the wild world of localization and internationalization with practical and real-world exercises that you can apply to your own website. You will go from theory to practice and acquire the skills you need to make a user-friendly Drupal 7 site that supports multiple languages.

You will follow focused chapter exercises to add multiple-language support for your user interface, content, and various parts of your site’s configuration such as system variables, menus, and blocks.

The latter half of the book fills in the details with step-by-step exercises for localizing the interface, the content, and the configuration. Drupal 7 Multilingual Sites will give you the knowledge and the skills necessary to configure your site to support your language needs.

Publication date:
April 2012
Publisher
Packt
Pages
140
ISBN
9781849518185

 

Chapter 1. Multilingual Overview, Use Cases, and Modules

Drupal is a big system with lots of moving parts. What exactly does it mean to make a multilingual Drupal site? We certainly want to write content in languages other than English. We need blocks and menus to be smart enough so we can use them for different languages. What about Views? Sure, we want it smart too. What about Panels? Yes, of course! What about a seemingly random message string coming from a module we just installed? What about the Drupal UI itself? And so on and so forth.

As you can see, we have a lot of things that need configuring if we want a fully multilingual Drupal website. This book aims at showing you how to navigate through the myriad of modules, configuration settings, and sometimes not-so-intuitive methodologies to make it happen. The exercises in the book are hands-on and organized to give structure to your localization process.

But before we start our exercises and break into a sweat, we need to understand a few things. This chapter will give you an overview of what it means to build a multilingual site in Drupal 7. We will explore a number of issues and considerations when working with multiple languages, and check out some typical use cases. Then, we'll take a look at some terminology and the different parts of the multilingual Drupal puzzle, namely, interface, content, and configuration. The chapter concludes with a preview of the modules we'll use in the coming chapters.

Considerations and use cases

Just like there is no one way to build a regular website, there is no one way to build a multilingual website. Every site is different and has its own use cases and multilingual demands. Check out amnesty.org, drupalcampmontreal.com, wunderkraut.com, reyero.net, and thesoundpost.com as some unique examples of multilingual Drupal websites.

Different types of language support

You can use as much of Drupal's language support as you need. If you simply want a website that is only shown in German with no English text and no translations, then you can certainly do that. Or, if you want to support content in several languages but none of the content will be translated, you can do that too. For the book exercises, we will be building a fully multilingual site that includes translation. The next figure shows the different levels of language support you might need depending on your site's use cases:

Some things to think about

There are always plenty of things to worry about when designing a website. When you decide to make your site multilingual, the list just gets bigger. This section is not meant to be an exhaustive compilation of everything you need to be thinking about before diving in, but it should help to get you started. We will consider many of these items as we work through our hands-on exercises:

  • Should you use a domain, a sub-domain, or a directory per language?

  • Do you need translations of all content in all languages?

  • If there isn't a translation available, should it show the source content?

  • Will translations be done in-house or outsourced and by one person or a team?

  • Do you have special e-commerce needs while dealing with taxation or currencies?

  • Should the admin UI have a different default language from the end-user UI?

  • Do any of your languages need Right-to-Left (RTL) theming support?

  • Will the navigation be different for each language?

  • Has the Drupal UI been mostly translated for your chosen languages?

  • What translation methods make sense for the site content?

Example use cases

Although there are many ways you can create a multilingual site based on your language needs, the following are some examples to get you thinking more about Drupal's language support.

Simple blog site

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.

Consulting company site

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.

E-commerce site

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.

Note

This example shows functionality based on language and location (country). These are independent features. You might have an English-only site that needs location-based functionality or a multilingual site that does not.

Our demo site

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.

 

Considerations and use cases


Just like there is no one way to build a regular website, there is no one way to build a multilingual website. Every site is different and has its own use cases and multilingual demands. Check out amnesty.org, drupalcampmontreal.com, wunderkraut.com, reyero.net, and thesoundpost.com as some unique examples of multilingual Drupal websites.

Different types of language support

You can use as much of Drupal's language support as you need. If you simply want a website that is only shown in German with no English text and no translations, then you can certainly do that. Or, if you want to support content in several languages but none of the content will be translated, you can do that too. For the book exercises, we will be building a fully multilingual site that includes translation. The next figure shows the different levels of language support you might need depending on your site's use cases:

Some things to think about

There are always plenty of things to worry about when designing a website. When you decide to make your site multilingual, the list just gets bigger. This section is not meant to be an exhaustive compilation of everything you need to be thinking about before diving in, but it should help to get you started. We will consider many of these items as we work through our hands-on exercises:

  • Should you use a domain, a sub-domain, or a directory per language?

  • Do you need translations of all content in all languages?

  • If there isn't a translation available, should it show the source content?

  • Will translations be done in-house or outsourced and by one person or a team?

  • Do you have special e-commerce needs while dealing with taxation or currencies?

  • Should the admin UI have a different default language from the end-user UI?

  • Do any of your languages need Right-to-Left (RTL) theming support?

  • Will the navigation be different for each language?

  • Has the Drupal UI been mostly translated for your chosen languages?

  • What translation methods make sense for the site content?

Example use cases

Although there are many ways you can create a multilingual site based on your language needs, the following are some examples to get you thinking more about Drupal's language support.

Simple blog site

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.

Consulting company site

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.

E-commerce site

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.

Note

This example shows functionality based on language and location (country). These are independent features. You might have an English-only site that needs location-based functionality or a multilingual site that does not.

Our demo site

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.

 

Multilingual Drupal overview


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.

Speaking the same language... terminology

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.

Pieces of the multilingual puzzle

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.

Interface

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.

Content

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.

Configuration

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.

 

A look at the modules


In the Drupal community, the phrase "There's a module for that" is often used and for good reason. Currently the drupal.org site boasts of more than 13,000 modules that have been contributed by community members. Searching this multitude of modules for the ones you need isn't easy, but fortunately taxonomy comes to our rescue this time.

The categorization of modules at drupal.org/project/modules includes a Multilingual category among its options. If we choose that term along with restricting our modules to Drupal 7 versions, then we narrow down our list to only about 50 modules. This is certainly a more manageable number! We won't use all of these in the book, but check out the Appendix, Modules, Resources, and Getting Involved, for a list of multilingual modules we will use as well as additional useful modules. The module list includes project page URLs for all modules, so you will know where to find them.

 

Summary


This chapter has provided us with a broad overview of the language support in Drupal 7. Let's do a quick recap of what we covered.

First, we looked at the different ways to use Drupal's language support, and considered some potential questions to ask before creating a multilingual website. To further our knowledge, we considered a few realistic use cases for different web audiences. We then learned the special terminology associated with the world of Drupal localization.

With our vocabulary enhanced, we moved on to looking at the big pieces of the Drupal 7 multilingual puzzle, namely, interface, content, and configuration. The user interface strings that need translation come from core and contributed modules and themes. For translating content, we narrowed in on data coming from entities. And, for the last piece of the puzzle, we saw that the remaining multilingual configuration involves many elements including handling blocks, menus, taxonomy, and views. The chapter concluded with a preview of the Drupal 7 modules that we'll use very soon.

Now that we understand the big picture, it's time to get to work. In the next chapter, we'll keep ourselves occupied with language settings, interface translation, and general system configuration. If you are ready to go, let's move on and get busy.

About the Author

  • Kristen Pol

    Kristen Pol grew up the youngest sister to five brothers in a small town in rural Central California. After high school and a few community colleges, Kristen earned a BA degree in mathematics and physics at UC Santa Cruz in 1994 and an MSEE at Stanford University in 1995. After college, Kristen worked as a Systems Engineer at Hewlett Packard and then as a Java application architect at a web consulting company in downtown Santa Cruz, California, during the dot-com boom.

    Kristen started her own software business in 2001. Initially, she focused on Java applications, but, in 2004, Drupal changed her life. Starting with version 4, Kristen got hooked on Drupal development and now she focuses pretty much exclusively on Drupal and search engine optimization (SEO). Kristen works with a wide variety of clients throughout North America. She enjoys working on challenging websites that require custom programming. Some of her more notable Drupal projects include boomboomcards.com (social kindness game), naturebridge.org (non-profit bringing kids to nature), thesoundpost.com (Canadian classical instrument shop), and boomerangproject.com (school transition programs).

    Kristen is very active in the Drupal community. She has authored contributed modules including Featured Content and SEO Friend, regularly attends the Santa Cruz Drupal user group, improves drupal.org documentation, gives talks at Drupal camps and meetings, and helps out on the Drupal forums and issue queues. When she's not doing Drupal, Kristen enjoys photography, travel, hiking, and spending time with her husband and two sons in beautiful Santa Cruz. Feel free to contact Kristen at kristen.org/contact.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Perfect book for my needs. I wanted to get an overview on multilingual techniques in Drupal. I could read the whole content and apply it directly to a live site. Good job !
Book Title
Access this book, plus 7,500 other titles for FREE
Access now