Natural languages are critical components of the foundation of human culture; similarly, computer languages are essential technologies in any digital culture. These two realms intersect most notably 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.
Compared to building websites from scratch, the employment of content management systems (CMSs) such as Drupal has, to varying extents, reduced the significant costs in time and effort — partly in the development of website multilingual mechanisms and partly in implementing translated text for the intended languages. 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. 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 oftentimes 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. That last point is critical, because by having the internationalization baked into Drupal core, it avoids the problems of using contrib modules that may or may not be receiving adequate support over time, and it avoids the extra time and work of getting 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, which is one of the seven major Drupal 8 core initiatives. The multilingual work centered on two broad categories, configuration and content. In the realm of the former, 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 they 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.
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.
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.
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.
Next, add Spanish to your website.
As expected, the original language, English, is still the default one.
On the "Detection and selection" tab on that page (admin/config/regional/language/detection), you can specify the methods and their 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.
The URL method has by default the settings we 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.
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 for when creating and editing nodes of that type. For our example, let's enable only "Content", as that will be sufficient for demonstration purposes. When you make a content type translatable, you will see additional checkboxes which provide fine-grained control over the translatability of all the elements on the content editing page — in this example, basic pages.
Now you can create both an English and a Spanish version of a basic page to welcome visitors to the site.
Note the two language options on the "Language" drop-down list 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.
Then add the Spanish equivalents for the title and body field.
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.
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 home page.) This may seem a bit tedious, but actually it gives us one more level of granularity in determining which translations are displayed under what circumstances.
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, for instance, 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 upon the site's current language. This must be indicated on the content language configuration page noted earlier.
This functionality affects core blocks as well as custom ones. You can, for instance, modify the site branding block to only appear when the site's language is Spanish.
Views can filter lists of content based upon 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.
Finally, you can add a language selector block to allow site visitors to easily switch 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 picker" block.
Then enable both English and Spanish, and save your changes.
The resulting language picker 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.
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.