After having built one multilingual website in Drupal 7 (our company website), I've had some time to look over the new i18n module. Beyond the blog posts I've linked to below, there's not much documentation for the module yet. I've put together some observations about the changes in functionality I've noticed so far, and hope to build on this in the near future.
Multilingual Modules in Core
In Drupal 7, the core Locale Module allows languages to be installed and provides a way to flag nodes with any installed language. It also provides users with a language switcher to change the interface language and administrators with an interface to add translations of interface strings. Locale handles important multilingual details like the localization of date formats and using the right-to-left or left-to-right CSS files depending on the direction of the current language.
The core Content Translation Module maps translations of a node back to the source node. It provides a translation tab so administrators can manage these node translations. It also provides a translate flag which indicates translations that are out-of-date.
The internationalization module (i18n) extends this functionality. It consists of a set of submodules that allow other Drupal elements to be translated and provides additional options for handling multilingual content.
Overall Changes to i18n in Drupal 7
- More Submodules The i18n module has more submodules than ever before! There are 14 in total.
- Translation Sets API: This submodule provides an API, used by the Path Translation , Multilingual Taxonomy, and Menu Translation submodules to track items that are translations of each other. For example, Multilingual Taxonomy has a "Per Language Terms" translation mode, which marks some terms in a vocabulary as language-specific, and uses the Translation Sets API to associate them with each other.
- User Interface Improvements: In the new version of i18n, the user interface for many of the submodules has been improved. The improvements will help administrators and translators when configuring the site and updating translations.
Here's an overview of the i18n module for Drupal 7, organized by submodule:
In Drupal 6, in order to translate the site's title, slogan, frontpage path and other variables, you needed to list these variables in the settings.php file like this:
$conf['i18n_variables'] = array(
In Drupal 7, setting the array of variables as above won't have any effect. The i18n Multilingual Variables Module allows you to set which variables to internationalize via the UI at Configuration » Multilingual Settings » Variables. This makes it easier for site administrators to translate new variables on the fly.
This module has a dependency on the Variable Module. For variables to be translated, the module which provides the variables has to implement the variable_info hook. The Variable Module does this by default for variables in core, but contributed modules will need to implement this hook independently.
Like in Drupal 6, you have to switch Drupal's user interface to a different language to add translations of variables. To improve the usability of this feature, there is now a link next to each multilingual variable field to switch the interface to each available language. This is particularly useful since admin themes often don't accommodate a language switcher.
Just like in Drupal 6, the i18n Block Languages Module allows you to configure the visibility of blocks across different languages. The user interface has been cleaned up so that the setting appears along with the other block visibility settings at the bottom of the block edit page.
There is also more flexibility in the Drupal 7 version. You can configure a block to appear in a set of languages using the checkboxes provided. A separate checkbox allows you to choose whether the title and body of the block are translatable.
Menu translation is similar to that in Drupal 6, but with an improved UI. There are a couple of options for creating multilingual menus in Drupal 7. For each menu, you can choose between no multilingual settings, 'fixed language', and 'translate and localize'.
The 'fixed language' option allows you to choose a single language for the menu, and the menu will only appear in that language.
The 'translate and localize' option means that nodes in the menu automatically show up in the correct language. Menu items linking to views or other dynamic pages can be localized by setting a language for the menu item. The menu item is then added to a translation set, which associates the menu item with its translations. This takes advantage of the Translation Sets API mentioned above.
By editing the translation set, you can associate the menu item with its translations. You can view all the translation sets at Configuration » Regional and language » Translation sets.
The i18n Multilingual Select Module allows you to define how Drupal core filters content by language. This applies to cases in which multiple nodes are pulled out of the nodes table and displayed on the page. For example, on the default homepage (at /node), or the RSS feed pages provided by Drupal core. The module allows you to configure whether or not to filter these pages by the current language. If the Multilingual Taxonomy submodule is also enabled, this option will be available for taxonomy term pages as well.
In Drupal 7, the Multilingual Select Module is a separate module. It provides an extended UI that allows you to exclude the module's language selection handling for certain elements (i.e. views, since views has its own mechanism for language filtering) and for certain paths. You can configure these settings at Configuration » Regional and language » Multilingual settings » Selection.
The Synchronize Translations Module hasn't changed much from the Drupal 6 version. Since more data is now stored as fields, you can synchronize more data per node. By default in Drupal 7, translation is on the node level, and synchronizing translations of certain fields is desirable (such as images, taxonomy terms, author, price, etc.). This prevents having to update these fields separately for each translation of a node.
Field level translation: Another option in Drupal 7 is to make content translatable on the field level instead of the node level. This requires the Entity Translation Module and the Title Module. For more information about the difference between node-level translation and field-level translation, see Gábor Hojtsy's blog post about node translation or Randy Fay's post about field translation in Drupal 7.
Among other things, the String Translation Module implements the i18n_strings function, which in Drupal 6 was commonly known as the tt function. The i18n_strings function is an API function that lets other modules (such as the Multilingual Taxonomy and Menu Translation submodules) manage translations of user-entered strings. This is similar to how the t function manages translations of strings defined in PHP code.
In Drupal 7, the string translation module allows you to configure which input formats are translatable. Formats like PHP Filter and Full HTML are translated before they are processed, so allowing a translator to edit these can be a security risk. This is particularly problematic when importing the translation in bulk from a CSV file, since the translator's access to the import formats isn't verified by Drupal.
The i18n Multilingual Taxonomy Module works much the same in Drupal 7 as it did in Drupal 6. Each vocabulary has a translation mode. Choosing 'Localize terms' allows the term name and description to be translated through the translate interface page (Configuration » Regional and language » Translate interface). You can also choose to set a language per term or set a language per vocabulary. In most cases, localizing terms is the simplest and most useful approach since it means that terms are not duplicated. However, in Drupal 7, thanks to the Translation Sets API, if you choose to set a language per term, then terms in different languages can be associated with each other by inclusion in the same translation set.
The Drupal 7 Path Translation Module allows you to create translation sets for paths. Path translations are used for generic paths (for example, for views pages), not for node or taxonomy page paths. You can configure multilingual paths by going to Configuration » Regional and language » Translation sets » Paths.
The Multilingual Content Module allows you to configure extra multilingual settings for each content type. The UI lets you choose to lock the language for that content type, not allowing users to change the language after the node is created. You can also require a language, which removes the 'language neutral' option for nodes. Setting the current language as the default language for new nodes is also an option. All of this UI is available under Configuration » Regional and language » Multilingual settings » Node Options, as well as when editing each content type.
There's also a sitewide setting on the node options configuration page where you can configure settings for the node translation interface: 'Switch interface for translating ' or 'Hide content translation links'.
In Drupal 7, the Locale module handles translation of field titles. The i18n Field Translation Module allows other field-related text like help text, default values, and list options, to be translated through the translate interface page.
If you're looking for more information about building multilingual sites with Drupal 7, check out Gábor Hojtsy's series on Drupal's multilingual system, or Jose Reyero's overview of the internationalization module for Drupal 7.