With a lot of nodes, some data, fields, and language-neutral properties needed to be synchronized. There are some drawbacks of using Content Translation. Content Translation scores better here because node-based translation is independent and asymmetric menus are possible. With Entity Translation, this would be complex from the editorial point of view. Some translated content would be different, targeting different markets and audiences with different SEO considerations. 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. Our considerations of both methodologies are detailed below with the pros and cons of each. We ended up implementing Content Translation for this particular client. However, both methods are relevant and adequate options depending on the situation. With heated interest in the newer Entity Translation, it is easy to jump to the conclusion that this is the better option. In Drupal 7, you can even use both methods side by side in a site. Entity Translation is the newer method and is in Drupal 8 core, but is also available for Drupal 7 as a contributed module. Only the associated fields are flagged with a language.Д¬ontent Translation is in Drupal 7 core. With Entity Translation, the entity is language-independent.

In other words, you have a source/base node and a node translation set made of separate nodes linked to the source node.Д«y contrast, the Entity Translation module allows particular fields to be translated, while only a single node or entity is created. The Content Translation module allows nodes to be translated by creating a set of nodes that are translations of each other. There were many considerations to take into account when coming up with a solution.Дrupal supports two methods of doing translations for site content: Content Translation and Entity Translation. Translated content needed to be able to be published at different times depending on the language. So only a subset of the original content would be translated.ДЄdditionally, the publication workflow and schedule for the different languages were not aligned. The sub-sites would need different menus, navigation, and subsets of the English products being offered. The main challenge with this situation was having the translated sites act as sub-sites of the main English website. This would allow for both combined and separate marketing efforts. They wanted a unified site, but with separate international editorial and marketing teams, they also needed flexibility in managing the translated sites. The company had an international presence, meaning they needed some of their offerings translated into four other languages. We worked with a client to build a complex, yet approachable Drupal 7 site.

A Case Study on Drupal 7 Multilingual Functionality

Drupal 8 language switcher