fromJune 2014
Feature:

Drupal In Babel

Drupal 8 Improvements for Foreign Language and Multilingual Site Building
0

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.

Rich language selection in the installer

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.

Obsolete Modules

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
admin_language For each administrator, now per-user preferred administration language selection is available.
fallback_language_negotation The language fallback is configurable now in negotiation settings independent of site default language.
l10n_install Language selection that downloads translations on the fly is now built-in in the installer.
l10n_update Updates for community-sourced translations are now built-in in the Interface translation module.
entity_translation Field based content translation that applies to all entity types is now the only content translation solution.
title 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.

Configuration translation is now a tab away from the settings page

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.

Get Involved

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.

Fields translatable Selector shown Default language Content
All
(including files attached)
Yes
(we write original articles in various languages)
Site’s default language Article nodes
None
(an English-only forum is easier to moderate with tight resources)
No
(all content in the forum is forced to English)
English Forum nodes
Most
(image fields only have title and alt text translatable, image itself shared among translations)
Yes
(there may be products marketed only in specific markets/languages)
Site’s default language Commerce products
None
(there may be reviews in different languages but we don’t translate them)
No
(no need to confuse the user, just use the page’s language)
Current page language Product review nodes

Image: ©iStockphoto.com/DrAfter123

Advertisement

From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.