Drupal – Choosing a Content Management System for Localization

Offering localized content is a key requirement for content management systems in (CMS). In the first post in this series I explored different localization features and not I’m looking at different CMSs. Last time I looked at WordPress and this time it’s Drupal.

Drupal has multilingual support baked in, but it is far from perfect. As a result, the community has developed additional plugins to patch the various holes left in Drupal’s core. Strangely, Drupal has two standardized ways of delivering localized content due to the fact that they are transitioning from the old to the new. The first, content translation, uses the multi-node model, while the newer entity translation method uses the single-node model. It is important to note that the two are not mutually exclusive; it is up to the developer to choose which type to use on a per-content basis, which only further adds to the level of complexity within the Drupal system.

For this post I will delve into the two different types of translation that are currently supported, their related plugins, and when they should be used.

Content Translation

Content translation was the solution put forth by the Drupal team in Drupal 6 to solve the localization problem within the system. As mentioned before, content translation uses the multi-node approach. Essentially, Drupal 6 achieved this by providing a means to label the language of each node and mapping each translation to a translation set.

Since then two plugins have been rolled out by the community to enhance the Drupal core multilingual capabilities, Internationalization and Translation Management. The Internationalization module, or i18n for short, extends Drupal core by providing taxonomy translation, multilingual variables and blocks, and language selection. The Translation Management module goes one step further and provides a comprehensive workflow management system to round out the content translation system. In addition, there are numerous other plugins that were built to extend i18n. They can be found here.

All of these modules combined together have made Drupal’s content translation extremely powerful, and in many ways performs very similar to the WPML package I examined in the last post. The following advantages and disadvantages are based on the criteria set forth by the first post in this series.

Advantages

– Allows for different menus for each language

– The i18n module allows for a translator role

– Taxonomies can be translated

– Each language has its own workflow

– Content can be flagged if it needs to be translated or updated

– Supports machine and human translation

– The translation management module integrates with ICanLocalize

– Localized themes can be achieved using Drupal’s multisite capabilities or the ThemeKey module

Disadvantages

– UND content cannot be easily synchronized between nodes

– Related content like votes and event attendance are not synchronized

– Creates too many nodes

– XLIFF support is in beta

– Creating hierarchical menus is difficult because there are multiple nodes per page

As you can see, content translation suffers from the typical drawbacks of a multi-node approach. That is not to say there are not workarounds. The Synchronize Translation module, for example, updates all of the nodes within a translation set whenever a UND field has been updated, preventing the need to manually update any of the fields. There still lacks a way to synchronize likes, signups, and other related content within a translation set.

The content translation module should be used for content that does not have a lot of UND fields or needs to be part of a hierarchy, like blogs and news articles. This module is also great for building asymmetrical sites, where one page may exists in English or German but not in other languages and vice versa.

Entity Translation

The entity translation module has been the Drupal team’s attempt to address the shortcomings of content translation. By using the multi-node model, the Drupal team was able to provide a solution for product pages and other portions of a site that rely heavily on UND content.

The creation of entity translation is incredibly new however, and it will not be in Drupal’s core until the release of Drupal 8. This means support for this module is slim and it does not have the same management tools as the content translation module. It also means some fields within Drupal’s nodes have yet to be made translatable, like menu settings.

Advantages

– Taxonomies can be translated

– UND content is synchronized

– Related content is also synchronized

– Perfect for product pages and events

– Comments can be filtered to show only the appropriate language

– Support for hierarchical menus

– Localized themes can be achieved using Drupal’s multisite capabilities or the ThemeKey module

Disadvantages

– Separate workflows and permissions are not supported

– Third party integration and XLIFF is not supported

– Weak support with other plugins

– All languages are published at once

– Search is currently not supported by any of the current search plugins

Entity translation has some significant disadvantages, mainly due to the fact that it has such weak support at the moment. But there is good news; the Drupal team is making a conscious effort to make this module the standard with some notable changes through the Drupal 8 multilingual initiative. But until then, users still need to choose between content and entity translation.

Users should use the entity translation module when dealing with product pages and other portions of a site that require large amounts of UND content. One of the key problems with entity translation is that there is no workflow, which means all languages are published at once, so the entity translation module should only be used on pages that are symmetric across different localities.

Conclusion

Both content translation and entity translation compliment each other, and because they can both be used on the same site on a per content-type basis, developers can architect their systems without having to sacrifice one set of features for another. It should be mentioned that implementing both models within a system is not for the faint of heart and there are several hurdles to pulling it off successfully, but for the developer who wants everything there is perhaps no better solutions.

Below is a chart outlining the key characteristics of the two types of modules. While it may appear that the content translation module is a stronger contender, there are significant use cases for entity translation.

Have any questions, comments or concerns? Feel free to leave a comment down below. If not, come back next time and I will discuss the pros and cons of using Hippo as a multilingual site.

• CMS
• Content Management System
• Drupal
• Localization