Avertissement

Cet article présente la stratégie strictement opposée à un autre article de notre blog. Nous confirmons l'utilisation de la stratégie de l'autre article dans le cas d'un site purement éditorial fonctionnellement simple, car elle introduit nettement moins de complexité que la solution décrite ici. Cependant, dans les autres cas d'utilisations, la solution présentée ici sera beaucoup plus flexible et puissante.

Comme toujours avec Drupal, le choix du module dépend du contexte du site, il n'y a pas de stratégie absolue.

Introduction

En Drupal, il existe 2 façons principales de gérer le multilinguisme : Content Translation (dans le cœur) et Entity Translation. Les deux ont des possibilités différentes. AmazeeLabs, société suisse, utilise uniquement Entity Translation, d'une part parce qu'il offre des possibilités que Content Translation ne permet pas, d'autre part parce que c'est la solution intégrée dans le cœur Drupal 8, et cela permet donc de penser comme il faudra le faire en Drupal 8.

On notera également que cette solution permet de n'avoir qu'un seul nœud pour toutes les langues, seule solution possible dans un contexte e-commerce.

La suite de l'article passe en revue des problématiques liées à Entity Translation sur Drupal 7.

Pré-requis

Pour installer Entity Translation (et obtenir une traduction pour les champs), le module Title est nécessaire, pour transformer le titre d'une entité en "title_field", qui devient traduisible.

Que faire si vous utilisiez Content Translation ?

Entity Translation comprend le sous-module Entity Translation Upgrade, qui permet une migration depuis Content Translation. Par contre, la procédure est à suivre scrupuleusement sous peine de perdre tout votre contenu (une sauvegarde est donc à effectuer absolument avant de tenter la mise à jour) :

1. activer Entity Translation Upgrade ;
2. rendre tous vos champs traduisibles ;
3. remplacer les titres par le champ du module Title ;
4. lancer la mise à jour ;
5. résultat : 1 nœud contient toutes les langues, les anciens nœuds des autres langues sont dépubliés.

Quels champs faut-il / peut-on traduire ?

Déjà, le comportement traduisible d'un champ est identique quelque soit l'entité où il apparait, à vous donc d'éventuellement dupliquer vos champs plutôt que de réutiliser le même champ si vous souhaitez un comportement multilingue différent.

A part ça, vous pouvez traduire la plupart des champs de votre Drupal, sauf les champs suivants :

Quelques champs à éviter

Ne jamais activer la traduction des champs Entity Reference ou Référence à un terme.
N'utilisez pas de champ Field Collection, préférez plutôt l'utilisation du module Inline Entity Form (aidé du patch sur #1545896).

Quelques champs particuliers

Pour les fichiers, il faut utiliser le module File Entity.
Pour la taxonomie, utiliser Entity Translation plutôt que i18n_taxonomy.

Et les autres données Drupal ?

Menus

Menu translation permet 3 options :

• des menus d'un langage spécifique ;
• des éléments de menu d'un langage spécifique ;
• la traduction des titres des entrées de menu (choisir "Language Neutral" dans les paramètres de l'élément de menu).

Webform

Ici, 2 options possibles également :

• un webform par langage ;
• sinon, Webform Localization existe.

Search API

L'intégration avec Entity Translation existe : Search API Entity Translation.

Et le reste ?

Blocks, Contact, Fields, Select, Panels, Strings, Mails, Variables, … : utiliser i18n.

Et si on veut changer les chaînes anglaises ?

Il est tout à fait possible de créer une nouvelle langue anglaise, et de désactiver l'anglais "par défaut" de Drupal.

Attention, danger !

Ne JAMAIS utiliser le module Multilingual Select (inclus dans la suite i18n). En effet, ce module réécrit l'ensemble des requêtes db_select() du site, pour fitlrer les contenus remontés par langue. Or, même en utilisant Entity Translation, les contenus possèdent une langue, qui n'a pas d'importance fonctionnelle. Il vaut mieux laisser Entity Translation utiliser la bonne version de chaque champ du contenu, et ne jamais utiliser Multilingual Select.

Quelques autres modules

Dans le cas de plusieurs langues proches (fr et fr-be, par exemple), vous pouvez utiliser Language Fallback (avec le patch de #2322883) qui vous permet de ne traduire que les termes spécifiques à une langue, les autres étant dans la "langue de repli" choisie.

Pour pouvoir suivre plus efficacement l'état des traductions d'un site avec beaucoup de langages différents, le module Translation Management Tool peut s'avérer utile.

Et Drupal 8, dans tout ça ?

Attention, il y a un piège : l'intégration d'Entity Translation s'appelle "Content Translation". Mais à part ça, Drupal 8 intègre NATIVEMENT un équivalent d'Entity Translation et i18n, entièrement dans le cœur. L'adage en vigueur dans la communauté est que "Pour le multilinguisme, Drupal 8 core est plus puissant et mieux intégré que Drupal 7 aidé de l'ensemble des modules de la communauté". Ça peut d'ailleurs aujourd'hui constituer une raison de démarrer un projet en Drupal 8.