The multilingual joy of Drupal 8

OCT 2015
Pieter Jonckiere

Based on the DrupalCon session "Drupal 8 multilingual site building hacks” by Gábor Hojtsy (Gábor Hojtsy)  and Vijayachandran Mani (vijaycs85), I took a deeper look into the multilingual capabilities of Drupal 8. The link to the event information and the full session can be found in the sources section underneath this blog post.


In Drupal 7 we needed a lot of contrib to build a decent multilingual website. And then other contribs wouldn’t integrate with those, leaving us with a headache on how to translate stuff like titles, field collections, or even worse, disable English. Luckily, a lot has changed since, and playing around with the new capabilities while doing core work has made me eager to start using them as soon as possible on new projects.


  • most (almost all) parts of content, config and interface have a language parameter, so there is no need to hack them in using contrib/custom code
  • translation comes out-of-the-box, no need for contrib to enable it
  • translation is more flexible than what D7 contrib could do
  • English is not treated special, any language can be the base language
  • the title field is not treated special, translation out-of-the-box
  • some things still missing though (e.g. plural forms for languages with more than one plural form per word)

The four modules in core

Most information you’ll find searching for this subject will say we have locale, i18n and entity translation in core now. While that is true, it goes way beyond that. We also have admin language, language fallback, l10n_update, i18n_variable and many more. They are spread over four core modules, thus giving the developer a choice in granularity and enabling them to easily support different use cases.

1. Language module

The main support comes from the language module. It takes care of the language system basics and it keeps track of language information on all data. That data in turn is used by three other modules which all handle different aspects of translation. Because all this information is readily available in core, it’s flexible enough to handle changing language needs over the course of a project, like adding an extra language. You can even define your own, if you would have a use case for that. Furthermore, the language module provides several features like the “add language” functionality, the language switcher, language selection and detection, and keeping track of the user preference regarding language.

2. Configuration translation module

A first specific aspect of translation is the possibility to translate all configuration items. Examples of configuration items are account variables, user preferences, menus or views. Translating those is what the configuration translation module does. Since this is baked into core, there’s no longer need for a dozen contrib glue modules like i18n_variable. 
Let’s take a closer look to a fairly easy example of a custom dateformat.

First we create our own custom format and specify the format string.

Create a date format screenshot

Then, on the overview, we can add a translation and on the next screen we can choose the language where the format should be different.

Date format overview screenshot

Dateformat translation form screenshotAfter that, we can simply fill in the translated date format.

Dateformat translation details screenshot
And what makes it even better, is that the new configuration management system empowers us to export this configuration. The tarball we can download contains all default configuration items along with the translation overrides using the interface. Afterwards we can import that back, which enables us to easily push config between environments.

The config item for the dateformat looks like this (for the sake of the example, I took a screenshot from the single export page).  

Dateformat single export screenshot

On the database, the entries in the config table look like the screenshot below. The upper line is the default configuration and the lower line has the language override.

Dateformat override on database screenshot

The extracted tarball with all configurations is shown in the screenshot below. In the left column we find all default configuration files. This folder also contains another folder with the overrides, with a separate folder for each language. The line selected in the right column is the Dutch override for the dateformat we defined above.

Configuration single export configuration

3. Content translation module

Another aspect of translation is the possibility to translate blocks, nodes, terms, comments and other entities. This is what the content translation module does. You can configure it to make all fields  translatable, somewhat like node translation in D7. But you can also choose not to translate several fields, more like entity translation in D7. This offers developers the tools to handle a lot of use cases. A nice example of this flexibility, is translating an image field with an alt and title attribute. You don’t want the editors to translate the images, yet you want them to translate the alt and title tags. This is demonstrated in the screenshots below.

The content type definition has the language settings to translate the content of this type, and show a language selector on the edit pages (note: this is off by default so I added it explicitly).

Content type translation screenshot

In the content language and translation, we can define that an image file is not translated while the alt and title tag are.

Image translation screenshot

It’s hard to show the result for an editor in screenshots, but I tried anyway. It’s probably better if you just tried this multilingual glory for yourself.

Translated image EN screenshotTranslated image NL screenshot

The configuration and content translation modules combined, make it possible to handle the very common use case where not everything is translated one-on-one.

4. Interface translation module

The final aspect of translating things is handled by the interface translation module. It comes with a fully revamped translate interface. It works way better than what we had in D7, and has some new features like support for singular/plural forms.

Translation singular/plural screenshot

Conclusion: Drupal 8 multilingual is an enormous improvement

Improving the l10n and i18n options were a core initiative for the Drupal 8 release, and it’s apparent that we can now reap the fruits of the hard labor that over 1200 contributors have done. It’s impossible to go over everything in a single blog post, but I’m convinced that these changes will be an enormous improvement for sitebuilders and for DX. And companies all over the world will save a lot of time and money because of this. 



Drupal expertise