Drupal developers have always made huge efforts to support foreign language and multilingual sites, but the effort needed on the implementer side was not insignificant either. There is a rich set of contributed modules with Localization update, Localization client, Internationalization, Variable, Entity translation, Title, and their sister and glue modules to use to round out a multilingual site. The main problem is that the core solutions are not always extensible to what contributed modules need, so the added modules make the maze of options available even more confusing and, in many cases, overlapping.
Dries Buytaert announced the Drupal 8 Multilingual Initiative on May 9th, 2011 to improve this situation significantly. The goal of the initiative was – and remains – to bring in proven best practices from contributed modules and make them available in a future compatible way, so numerous add-on solutions would not be needed for most common use cases.
As of this writing, almost three years later, we can say that the initiative is one of the most successful in Drupal 8, with close to 1,000 contributors (based on people commenting on issues) and around the same number of issues managed. This resulted in a solid set of solutions in core consolidated in only four built-in modules:
- Language: to offer wide-spread language assignment and selection
- Interface translation: to translate the software and modules/themes (used to be Locale)
- Content translation: translate content with fields
- Configuration translation: to add flexible language support for configuration
The separation of these modules allows you flexibility in configuring language support on your site. For example, you can use Language module only to assign language information to assets (such as downloadable documentation files) even without the site needing to be translated to non-English languages. You can also swap out the Configuration translation module, for example, to use a different translation user interface without affecting other system components.
Bold Commitment to Foreign Language Support
Drupal 8 comes with a great-looking redesigned installer that makes language selection step one, offering a list of almost a hundred languages to pick from. In fact, your language is preselected based on your browser preferences, so you may only need to click the continue button to advance the process. The installer then downloads the translations from localize.drupal.org and the installation process continues in your own language.
This feature is also integrated with translation updates, so when you install additional modules and themes, their translations are automatically downloaded. Additionally, when component updates are rolled out, their translations are pulled with them. The translation download file storage is centralized in one directory which may be version controlled, allowing for seamless integration in your quality assurance and deployment process.
Drupal also understands that in some cases you may not agree with the community-provided translations. So Drupal 8 has built-in support for customizing translations and protecting them from being overwritten by remote updates. This also allows you to export and reuse translation customizations on further customer sites.
Flexibility in Handling English
Given that Drupal is built by an international community of developers, our common language of choice is English. Thus, English always had a special role in the system. You could never have removed English even if you only wanted, say, a purely French site. However, in Drupal 8, you can now remove English. In fact, foreign installs will not even add English by default. You can also modify interface strings in English without needing to resort to adding a cumbersome extra “Custom English” language: just enable English as a translatable language by editing its configuration.
More Power in Language Selection
Drupal 8 comes with a lot more power for language selection configuration. The site language fallback is not tied to the site default language anymore; you can configure the two settings independently. There is now an option to let administrators pick language preferences specifically for administration pages. This was an often-requested feature to let site editors handle fixes in content written in languages they don’t understand. Now the interface can be in an entirely different language for administrators. Finally, Drupal 8 also understands that external systems may provide slightly – or even entirely – different language codes for certain languages. There is an extensible mapping table built-in.
Knows What You Did Last Summer
Drupal 7 tracks the language of some of the content (for example, nodes) but not menu items or taxonomy terms. Language tracking is not available for site settings (user e-mails or views) either. This causes lots of headaches unless you carefully plan this fact into your entire site building process. Drupal 7 needs to assume that the language of items which don’t have explicit language settings is the site default language. This is what makes changing the site default language a huge no-no in Drupal 7.
In Drupal 8, everything has language information on its own! The system knows the language of each of your Views separately; the settings of e-mail text sent to users have their own language; and each user role, input format, etc. tracks its own language. This is very important because Drupal sites always use a mix of configuration shipped with the software (always originally in English) and custom-created configuration which may even be created in various languages originally on a multilingual site. By knowing the language of each piece individually, Drupal can offer translations from different sources seamlessly.
Content language support is even more flexible. You can configure language selector widget visibility and default values for different types of content individually. You may opt to have an English-only forum and tie forum posts to English, never showing a language selector on them. Your articles and blog posts may be posted in any language though, so you can enable language selection on them and default to the current page’s language.
The following modules or module suites are obsolete in whole or in part thanks to new features in Drupal 8 core:
|Drupal 7 contributed project
|Drupal 8 core feature
|For each administrator, now per-user preferred administration language selection is available.
|The language fallback is configurable now in negotiation settings independent of site default language.
|Language selection that downloads translations on the fly is now built-in in the installer.
|Updates for community-sourced translations are now built-in in the Interface translation module.
|Field based content translation that applies to all entity types is now the only content translation solution.
|The title field (on nodes, at least) is being made more and more flexible along with other base fields. It can store translations in other languages now.
|variable (several modules)
|The new configuration system now defines the structures and types of data managed.
|i18n (several modules)
|Numerous submodules are obsoleted by Configuration translation, especially i18n_string. Another great example is i18n_block which is now replaced with language assignment and translation support in core.
|i18nviews, webform_localization, etc. (in part)
|No need for special glue modules to translate configuration anymore; the data structure information about configuration is used to manage translations.
|stringoverrides (in part)
|Performance improvements in string translation, English being optionally translatable, and highly improved translation user interface.
|transliteration (in part)
|Not entirely obsolete, but the base API is in core and applied to machine name transliteration. Not integrated with path aliases or files (yet).
Building Pages With Language in Mind
Now that Drupal knows all about the language of your content and configuration, it can much more easily build pages that respond to language conditions. Blocks now have language visibility, so you can show/hide them for different languages separately. Key pages are served by Views, such as the front page and the content and user administration pages. You can now customize these easily with language conditions and apply your translation rendering preferences as needed.
Translate All Your Content
Unlike the content translation feature in Drupal 7 that only applies to nodes (and makes separate copies of them that many modules don’t cope with), Drupal 8 has a feature under the same name with entirely different functionality. It works with field translation (worked out in the Drupal 7 Entity translation module), and supports all types of content (taxonomy terms, comments, files, and user fields included). This approach is also compatible with contributed module-provided content entities like rules, commerce products, etc. The old translation method itself is not available anymore, but is still possible to mimic by configuring all fields to be translatable, in which case only the identifier of the entity will be the same across translations.
Translate All Your Configuration
At this point you may be wondering if Drupal covers all bases now.
It does... and more!
In Drupal 7, you needed to set up a suite of Internationalization and Variable modules and a host of glue modules to make your views, webforms, etc. translatable. Drupal 8 comes with a built-in solution: The Configuration translation module in core offers a simple built-in user interface for translating any configuration including your site name, e-mail text sent to users, input formats, field configuration and even all details of your views! The translation interface is integrated as tabs on each configuration screen and there is an overview of all translatable configurations available too, for those without wide site configuration access.
The module also has an understanding of the different source languages possible. Even if you don’t have English configured on your site, the views, input formats, fields, etc. that came with Drupal were shipped in English. So you can translate them from there, while you can create further site configuration in your own language and translate to more languages from there. The use of the configuration data works transparently in the correct language when needed.
What is Left for Contributed Modules?
While Drupal 8 core is more multilingual than any previous release, development remains focused on making the data storage, entry, and translation processes support multiple languages. This is a huge effort in and of itself, as I hope you now understand from this article, and there are still significant pieces of functionality to be made available for flawless multilingual sites.
Integration with third party translation services as well as translation workflows is key to any significant multilingual site. The Lingotek and Translation Management Tools (tmgmt) modules, which are leaders in this space will need to fulfill this role in the Drupal 8 contributed module space. The focus of the core features was a wide understanding of language in the data structures as well as a future compatible architecture that would work with your added modules and themes.
Finally, it is not entirely certain, as of this writing, whether taxonomy term, menu item, and comment base fields will be made translatable in core. Our ultimate goal is to have all base fields support multiple languages, but they need custom code to do so (unlike configurable fields, which have built-in support for language). If core ultimately does not ship with multilingual base fields for these entities, there will be at least a contributed module to fill in the gap.
The Drupal 8 Multilingual Initiative (D8MI for short) has a very welcoming team, and there is always something to do for people with all kinds of backgrounds. The best way to learn the new system is to help with a few issues here and there. We have our own website to help you get oriented at http://wdog.it/4/1/d8m. The site aggregates news posts, event announcements, demo videos, multiple issue boards (with distinctive focus on the current most important issues), and visual overviews of issues in specific areas. Check out who to talk to, and when are our next meeting times. We also coordinate sprints at almost all major Drupal events around the globe, in different capacities, so it is easy to meet us in person.
Sample Content Language Configuration
This sample configuration is for an imaginary website with some multilingual needs. It is made possible by all the changes in Drupal 8 core. Every little part is independently configurable on one all-encompassing screen, so it is easy to adapt to your needs. This combination of features is provided by Language and Content translation modules.
(including files attached)
(we write original articles in various languages)
|Site’s default language
(an English-only forum is easier to moderate with tight resources)
(all content in the forum is forced to English)
(image fields only have title and alt text translatable, image itself shared among translations)
(there may be products marketed only in specific markets/languages)
|Site’s default language
(there may be reviews in different languages but we don’t translate them)
(no need to confuse the user, just use the page’s language)
|Current page language
|Product review nodes