Drupal Multilingual Challenges and Considerations

Drupal supports two methods of doing translations for site content: Content Translation and Entity Translation.

The Content Translation module allows nodes to be translated by creating a set of nodes that are translations of each other. In other words, you have a source/base node and a node translation set made of separate nodes linked to the source node.

By contrast, the Entity Translation module allows particular fields to be translated, while only a single node or entity is created. With Entity Translation, the entity is language-independent. Only the associated fields are flagged with a language.

Content Translation is in Drupal 7 core. Entity Translation is the newer method and is in Drupal 8 core, but is also available for Drupal 7 as a contributed module. In Drupal 7, you can even use both methods side by side in a site. With heated interest in the newer Entity Translation, it is easy to jump to the conclusion that this is the better option. However, both methods are relevant and adequate options depending on the situation.

We ended up implementing Content Translation for this particular client. Our considerations of both methodologies are detailed below with the pros and cons of each.

Site Structure, Navigation, and Menu

Similar to most sites, our client did not plan to have a one-to-one menu structure for all translated versions of the site since not all content needed to be translated. Some translated content would be different, targeting different markets and audiences with different SEO considerations. With Entity Translation, this would be complex from the editorial point of view. Content Translation scores better here because node-based translation is independent and asymmetric menus are possible.

There are some drawbacks of using Content Translation. With a lot of nodes, some data, fields, and language-neutral properties needed to be synchronized. Fortunately, this can be easily achieved using the i18n_sync module, where it synchronizes taxonomy and fields across translations of the same content. Another drawback for Content Translation is the same files and images need to be uploaded multiple times for the different languages. We helped to eliminate this process by using a custom module to perform replication during translation (see Customization section below).

Using Content Translation also provided flexibility in terms of implementing the menu. If later on the client decided to split the menu tree out by languages, that could still be done. This is not as constricted as Entity Translation where the node only has one menu item relation, so translations must happen using the same menu.

Content Revision and Publication Workflow

The client was using workbench moderation extensively with multiple manager and content editor roles. Hence, content revision was critical in product releases, documentation versioning, content editing, proofreading, and approval processes. There is some initial work on Entity Translation to support such revisions, but we have not tested this.

Editorial roles and permissions

Each language had its own content editor team as an extension of the publication workflow. Moderation and publication permissions needed to be modified on a per-language basis. A node has comprehensive permission support which could achieve this. Rich node access checking can be used to limit roles and permissions on translated content and workflows per language team. The field level permission toolset does not have this capability. Hence, Entity Translation is far from close to what the node-based translation of Content Translation can do.

So for per language revisions, Content Translation wins.

Path Alias

In Entity Translation, to translate the title field you will need the Title module. It also helps with path alias if the url pattern depends on it. Otherwise, both methods should work the same when you translate the path or leave them to be similar.

Drupal Upgrade

Will upgrading to Drupal 8 or 9 be an issue? The short answer is no. Both Content Translation and Entity Translation will have an upgrade path. As of this writing, migration of Content Translation to Drupal 8 is already possible for the core fields. There is no movement yet for Entity Translation.

Search

Core search does not work with Entity Translation in Drupal 7. Using Search API, Entity Translation will require the Search API Entity Translation module and if you are using Solr, Entity Translation will require Search API Entity Translation Solr search module. These will require usage of Solr dynamic fields, so make sure your Solr hosting supports it.

Content Translation, which is node-based, has no issues with core search or Search API.

Other Text Content

There are other types of content you will need to consider when evaluating which translation methods to use. Examples include:

• Block content
• Views
• Javascript
• Variables
• Metatags
• Node properties

[See also Choosing the Best CMS for Your Website]

Replication With Translation

Paragraphs are used throughout all the content types and generally client content is heavy in text and graphics. In order to improve the editorial process and eliminate the redundant work of recreating every single piece of content during translation, our web designers make use of the Replicate module and introduced custom modules to handle adding translation and performing node with paragraphs replication.

Untranslated Content

When accessing untranslated content from another language or switching languages on untranslated content, the default behavior in Drupal will be to redirect to the English version.

Our client’s requirement was a sub-site configuration where untranslated content should not be linked or accessible unless they switch to the correct language. However, a user could reach untranslated content through menu items, content links, blocked links, or the language switcher. So we decided to hide all untranslated content with some exceptions.

Unpublished Translation

The client had a translation QA process, so the editor and proofreader needed the ability to edit, navigate and proofread unpublished translations. To achieve this, we used a combination of View Unpublish and Menu view unpublished.

• Multi-Language Link and Redirect (MultiLink)
• Alternate hreflang