Internet usage has exploded throughout the world over the last decade. More than one third of the world's population now has internet access. In 2012 2.27 billion people were using the internet, which is double the number in 2011. The ability to serve fully translated content to users is more important than ever. Translated content can help you to better market your brand in new regions, and can help establish your website as an authority on its subject matter. This is because it's seen by more users and is accessible to a larger audience. Mediacurrent, using the power of the i18n suite of modules, has successfully implemented fully translated solutions for a number of clients including www.manh.com, www.redheart.com, and www.pega.com. I18n is shorthand for Internationalization(I [18 characters] N).
Drupal, when paired with the i18n contributed modules, provides a powerful and feature rich system for building completely translated websites. In this post we are going to look at the tools necessary to build a multilingual website in Drupal, review what each module does, and walk through configuring modules on your site. Along the way, we will provide examples from our own real-world experiences building fully-translated, enterprise level websites with Drupal.
Drupal 7 core comes with translation capability in the form of Locale and Content Translation modules. The Locale module provides basic language handling functionality, and the ability to translate the user interface into another language besides English. We use Locale to define what languages we will be translating the site to, and how Drupal will detect that certain content needs to be displayed in a different language. Language detection is a key feature of i18n enabled websites, and is an important architectural choice when planning your translated site. We discuss detection in more detail below. Content Translation supports translating content into different languages, which allows administrators to translate entire nodes. Translation of a node using the Content Translation module creates a new node in the chosen language that is mapped to the source.
All translated Drupal sites require the same steps for basic setup. First, you need to enable Locale and Content Translation modules under /admin/modules. Next we need to configure Drupal to understand when to give this translated content. This is managed on the admin/config/regional/language page under the Detection and Selection tab. By default, Drupal provides five detection methods. Each detection method provides a different way for Drupal to determine which language it should serve.
The first and most common method is URL detection. URL detection determines the language by examining the url, looking for a path prefix, or finding the actual site domain to indicate selection. Here are basic examples of what this website would look like (if it was real!) with each method:
-
Path Prefix: www. mytranslatedsite. com/fr/somecontent could be the French translation of www. mytranslatedsite. com/somecontent.
-
Domain: www. mytranslatedsite. fr/somecontent could be the French version of www.mytranslatedsite.com/somecontent.
URL detection is simple to set up, and works well with most advanced caching strategies like Varnish, and nginx. A simple way to determine which URL detection method you should use is to examine the translated content you will be serving. Is your content the same across all translated sites? Then, you should use Path Prefix. Does your content differ significantly across translations? Then, you should consider using Domain detection and different domains. The different domain per language serves as an indicator that the content is mostly different across domains.
Session detection occurs when the language is provided by a session/request parameter.
Ex: www.mytranslatedsite.com/somecontent?language=fr would indicate this is the french version of this page. There is some concern in the Drupal community about using session detection and whether or not it should be moved to its own module, with the main issue being that using session detection means that one URL could potentially serve up different content. This can lead to issues with Drupal and SEO.
The final three methods are User Detection, Browser Detection, and Default. User detection determines language based on what is chosen by the site visitor. Browser detection displays language by checking the browser language settings. Default serves the sites default language (and is always enabled). User and Browser detection both have issues with using caching. User detection requires the user to be authenticated (which nullifies the most common Drupal caching strategies), and browser detection does not work with caching at all as the page generated for the first visitor to hit the cache will be served to subsequent visitors, regardless of browser settings.
Now we understand the basics of i18n configuration and language selection. In my next post we will take a deep dive into language configuration, and walk through translating a piece of content step by step.
