We recently worked with a client to build a complex, yet approachable Drupal 7 site. The company had an international presence, meaning they needed some of their offerings translated into four other languages. They wanted a unified site, but with separate international editorial and marketing teams, they also needed flexibility in managing the translated sites. This would allow for both combined and separate marketing efforts. The main challenge with this situation was having the translated sites act as sub-sites of the main English website. The sub-sites would need different menus, navigation and subsets of the English products being offered. So only a subset of the original content would be translated. Additionally, the publication workflow and schedule for the different languages were not aligned. Translated content needed to be able to be published at different times depending on the language. There were many considerations to take into account when coming up with a solution.
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 which 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, proof reading 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 their 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.
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.
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.
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
- Node properties
Replication with translation
Paragraphs is 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, we make use of the Replicate module and introduced custom modules to handle adding translation and performing node with paragraphs replication.
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.
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.