Drupal 8 Core Multilingual Functionality

This article first appeared in Drupal Watchdog https://drupalwatchdog.com.

Natural languages are critical components of human culture, and issues arise when people fluent in various natural languages try to use websites that assume the visitor understands only one language, typically English. Support for multiple human languages is more important than ever, as the web becomes an ever increasing global platform for commerce and culture.

Content management systems (CMSs) such as Drupal have significantly reduced the cost in time and effort for rolling out a multilingual website. In the world of Drupal, support for non-English languages was essentially an afterthought in versions up to and including the penultimate version – and the same can be said for countless other CMSs, even their latest releases.

Drupal 7 offers limited support for languages other than English. The core code allows one to install the software in another language, but that requires performing multiple steps [1]. Presenting page content in other languages requires installing and configuring up to two dozen or so additional modules not included in the Drupal core installation. Yet that's only the beginning of the arduous process, because to achieve any given feature, you may have to choose from more than one possible module. But they don't all play well together, so you often would be compelled to use the Rules module, assuming that it is sufficient to build the necessary bridges for your project.

Now We're Talking

Fortunately, Drupal 8 dramatically improves support for internationalization. The multilingual capabilities that in Drupal 7 would require a lot of contrib modules, can now be done in Drupal 8 using only four, and all of them are in core. Baking the internationalization into Drupal core avoids the problems associated with using contrib modules that may not be receiving adequate support, and it avoids the extra effort necessary to get a large number of modules to work smoothly together. Lastly, it greatly increases the ease – and thus the odds – of developers and designers choosing to embrace more natural languages when building their new websites.

Much of this successful effort was encompassed by the Drupal 8 Multilingual Initiative [2], which is one of the seven major Drupal 8 core initiatives. The multilingual work centered on two broad categories; configuration and content. Drupal site builders can perform the installation process in one of 100 languages (as of this writing), from Afrikaans to Welsh. And that's just the beginning, because as site builders and maintainers work within a Drupal 8 site, they can have the field labels, help information, and other configuration text be displayed in any chosen language.

In the realm of site content, there are many levels of granularity and control: As before, the website itself has a default language. Now, a single node can have a default language. Further still, a language can be assigned to every element on the page – effectively, field-level content translation. There are countless other new features. For instance, downloads and updates of translated text can be automated. Ordinarily this would run the risk of local translations being silently overwritten by an update, but fortunately it can be prevented through tracking and protection of custom translations.

There is much more to Drupal's new multilingual capabilities that cannot be covered here, including: automated downloading of interface translation files, centralization of translation files, migration of translations from Drupal 7 to Drupal 8, and language support in Drupal search functionality. In fact, even though it is the default language for the Drupal installer, English can be removed completely from a website that has no need for it – provided of course that an alternate language has been fully configured to serve as its replacement as the default language.

Mighty Modules

All of the aforesaid functionality can be achieved using no more than the four core multilingual modules: Configuration Translation, Content Translation, Interface Translation, and Language (Figure 1).

As their names suggest, the Configuration Translation module provides a translation interface for configuration field labels, blocks, views, and other data, while the Interface Translation module translates the built-in user interface, and incorporates an update feature (Figures 2 and 3).

The settings and functionality for these two modules are beyond the space limitations of this article, and thus the reader is encouraged to explore them and see how they can further internationalize what text is seen by a site's builders and administrators.

The Content Translation module provides a translation interface for content fields for all entities, thereby handling the editing and presentation of translated versions of text in nodes and other content.

Last but certainly not least, the Language module underpins them all, because it allows users to configure the desired languages and apply them to the site's content types. It handles the assignment of language. Specifically, while Drupal 7 supported language assignment for nodes, aliases, and users, Drupal 8 extends that to taxonomy terms, views, and site information (such as the site's name and slogan). Also, it provides language selection capabilities. Additionally, it is intended to provide base content services beyond multilingual translation.

Making It Work

As with all computer programming, the most efficient way to learn how to work with Drupal 8's new multilingual features is by seeing an example. In this instance, we will create a basic page in both English and Spanish, and see how to control which one is presented to the user. (We will assume that the site's default language is English.)

After enabling the four modules mentioned earlier, go to the languages configuration page (admin/config/regional/language), which allows you to add any of the available languages (Figure 4). Next, add Spanish to your website (Figure 5).

As expected, the original language, English, is still the default (Figure 6).

On the Detection and selection tab on that page (admin/config/regional/language/detection), you can specify the methods and the order by which the language is determined. By default, the URL method is the first one employed by the site, and then the selected language (Figure 7).

The URL method has by default the settings you would expect, namely, that inclusion of /es/ in a page path specifies Spanish, and that the absence of any such ISO language code indicates the site's default language, English (Figure 8).

The content language configuration page (admin/config/regional/content-language) is where you must specify which entity types will have support for languages other than the site's default and where you can enable the language selector when creating and editing nodes of that type. For this example, enable only Content, as that will be sufficient for demonstration purposes. When you make a content type translatable, you will see additional checkboxes that provide fine-grained control over the translatability of all the elements on the content editing page – in this example, basic pages (Figure 9).

Now you can create both an English and a Spanish version of a basic page to welcome visitors to the site (Figure 10).

Note the two language options in the Language drop-down box. That specifies the original language of the page. Save the new page, edit it, go to its Translate tab, and click the Add button for Spanish (Figure 11). Then, add the Spanish equivalents for the title and body field (Figure 12.)

Even though both versions are for the same node, they are listed on the content administration page (admin/content) as two entries. Yet, under the Title column, both page title links point to the same URL (Figure 13).

If you have not done so already, publish the page, which must be done for both language translations, even though they share the same node ID. (The same is true for promoting the page to the site's homepage.) This might seem a bit tedious, but it gives you one more level of granularity in determining which translations are displayed under what circumstances.

Visibility Control

Assuming that the node ID for the example page just created is 1, then the English version will be shown when the visitor goes to the page's URL containing no ISO language code (e.g., http://example.com/node/1). The Spanish version would be viewable at http://example.com/es/node/1.

Blocks can be displayed or hidden based on the site's current language. This must be indicated on the content language configuration page noted earlier (Figure 14).

This functionality affects core as well as custom blocks. You can, for instance, modify the site branding block to only appear when the site's language is Spanish (Figure 15).

Views can filter lists of content based on several options: the language specified for the view row, the original language of the content, the site's default language, the language specified for the page, and one of the languages enabled in the Regional and language settings (Figure 16).

Finally, you can add a language selector block to allow site visitors to switch easily between languages. Go to the Blocks admin area (admin/structure/block), and for the desired region (in this example, Sidebar first of the default Bartik theme), click the Place block button. In the pop-up window, click the same-named button for the "Language switcher" block (Figure 17). Then, enable both English and Spanish, and save your changes (Figure 18).

The resulting language switcher block will list both languages, and clicking either link will change the language used by Drupal for determining which version of your page is displayed (Figure 19).

As mentioned earlier, there is so much more to the capabilities of Drupal 8 for supporting multiple natural languages in websites. But this brief introduction illustrates how internationalization is another Drupal 8 advantage that should encourage web development enthusiasts from all over the world to try it.