Faire fonctionner un site web dans plusieurs langues relève moins de la traduction que de la gestion : décider ce qui doit être traduit, garder chaque version synchronisée, servir la bonne langue au bon visiteur, et tout cela sans transformer l'édition de contenu en corvée. Drupal gère cela au niveau du cœur du système, ce qui explique pourquoi il est choisi par des gouvernements, des organisations internationales et des universités qui publient en dizaines de langues.
Ce guide explique comment fonctionne réellement la gestion multilingue dans Drupal : les quatre modules principaux, les trois types distincts de traduction, comment ajouter et gérer les langues, comment Drupal décide quelle langue servir, quel flux de traduction convient à quelle équipe, et les erreurs qui font le plus souvent dérailler un projet multilingue.
Pourquoi le multilingue fait partie du cœur de Drupal
La capacité multilingue n'est pas un module greffé sur Drupal — elle fait partie du cœur depuis Drupal 8, et les versions 9, 10 et 11 ont continué à s'appuyer dessus. C'est une distinction importante. Sur les plateformes où le multilingue arrive via une extension tierce, chaque mise à jour majeure comporte le risque que la couche de traduction se désynchronise de la plateforme. Dans Drupal, la couche linguistique est livrée et maintenue avec le cœur, et le système prend en charge plus de 100 langues dès l'installation.
En pratique, cela signifie qu'un site Drupal peut être conçu comme multilingue dès le premier jour plutôt que d'être adapté après coup. Lors de l'installation, on vous demande de choisir une langue de base, et si vous en choisissez une autre que l'anglais, Drupal active automatiquement les modules concernés et récupère les dernières traductions d'interface. Sur un site déjà existant, il suffit d'activer quelques modules plutôt que de migrer vers un autre outil.
Les quatre modules principaux du multilingue
Le système multilingue de Drupal repose sur quatre modules principaux. Seul le premier est strictement obligatoire, mais en pratique la plupart des sites activent les quatre. Vous les activez sous Extend (admin/modules), dans la section Multilingue.
- Language (Langue) : La fondation. Il définit quelles langues le site propose, fixe la langue par défaut, et contrôle comment Drupal décide quelle langue afficher. Rien d'autre dans la pile multilingue ne fonctionne sans lui.
- Content Translation (Traduction de contenu) : Permet aux éditeurs de traduire les entités de contenu — pages, articles, termes de taxonomie, blocs personnalisés, liens de menu, et plus encore — dans chaque langue. Chaque version linguistique est une entité distincte avec ses propres champs, sa propre URL et son propre statut de publication.
- Interface Translation (Traduction d'interface) : Traduit le texte intégré provenant de Drupal, des modules et des thèmes : boutons, libellés de formulaires, messages d'erreur et chaînes système. Comme le cœur de Drupal est déjà traduit dans plus de 100 langues, une grande partie est déjà remplie dès l'ajout d'une langue. (Dans les anciennes versions, ce module s'appelait Locale, d'où le fait que certains tutoriels obsolètes utilisent encore ce nom.)
- Configuration Translation (Traduction de configuration) : Traduit la configuration plutôt que le contenu — le nom du site, les libellés de champs, les vues, les menus, les titres de blocs et les vocabulaires. Sans ce module, l'ossature du site reste dans une seule langue même quand le contenu est entièrement traduit, ce qui casse discrètement l'expérience utilisateur.
Une façon utile de les distinguer : le contenu est ce que vos éditeurs rédigent, la configuration est la manière dont le site est construit, et l'interface est le texte fourni par Drupal et ses modules. Les trois doivent être traduits pour qu'un site paraisse véritablement localisé plutôt qu'à moitié traduit.
Trois types de traduction : contenu, interface et configuration
La source de confusion la plus fréquente dans un projet multilingue Drupal n'est pas un paramètre technique — c'est de ne pas savoir à quel système de traduction, parmi les trois, appartient un texte donné. Bien comprendre ce modèle mental évite des heures passées à chercher une option de traduction au mauvais endroit.
- La traduction de contenu couvre tout ce que les éditeurs créent : corps des nœuds, titres, images, termes de taxonomie, blocs personnalisés. Dans les versions modernes de Drupal, cela se fait au niveau du champ — vous choisissez quels champs d'un type de contenu sont traduisibles, de sorte qu'un champ partagé (par exemple un code produit) puisse rester identique dans toutes les langues pendant que la description, elle, est traduite.
- La traduction d'interface couvre le texte intégré au logiciel. Vous la traduisez rarement à la main ; elle arrive avec le téléchargement de la langue et se peaufine dans Configuration → Régional et langue → Traduction de l'interface utilisateur, uniquement lorsque vous souhaitez remplacer une chaîne spécifique.
- La traduction de configuration couvre le texte structurel stocké dans le système de configuration de Drupal. Vous la traduisez depuis l'onglet Traduire de la page de configuration concernée, ou en bloc via Configuration → Régional et langue → Traduction de la configuration.
Un détail opérationnel à connaître dès le départ : les traductions d'interface peuvent être exportées et importées sous forme de fichiers .po standards, mais les traductions de configuration ne peuvent pas être déplacées ainsi avec le cœur seul — cela nécessite un module contribué. Sur un projet où les traductions sont préparées en dehors de Drupal, cette différence façonne votre processus de transmission.
Ajouter et gérer les langues étape par étape
Une fois les quatre modules activés, mettre une nouvelle langue en ligne est simple. Le déroulement général est le même sur toutes les versions modernes de Drupal :
- Ajouter la langue : Allez dans Configuration → Région et langue → Langues (admin/config/regional/language) et cliquez sur Ajouter une langue. Choisissez la langue, cliquez sur Ajouter, et attendez pendant que Drupal télécharge ses traductions d'interface. Elle apparaît ensuite dans la liste des langues, prête à l'emploi.
- Décider ce qui est traduisible : Pour chaque type de contenu, activez la traduction et choisissez quels champs doivent être traduisibles ou partagés. Faites-le de façon réfléchie — l'activer maintenant pour les bons champs évite un travail pénible plus tard.
- Traduire le contenu : Ouvrez n'importe quelle entité traduisible et utilisez son onglet Traductions pour ajouter une version dans chaque langue. Chaque version possède sa propre URL et peut être publiée selon son propre calendrier.
- Traduire la configuration et l'interface : Localisez le nom du site, les menus et les vues via la Traduction de configuration, et remplacez toute chaîne système via la Traduction d'interface.
- Ajouter un sélecteur de langue : Placez le bloc sélecteur de langue pour que les visiteurs puissent naviguer entre les versions. Utilisez le nom de la langue plutôt qu'un drapeau — un drapeau représente un pays, pas une langue, et induit en erreur les utilisateurs dans le cas de langues partagées entre plusieurs pays.
Un conseil pratique répété par les équipes Drupal expérimentées : commencez avec votre langue principale plus une langue secondaire, faites fonctionner le flux de traduction de bout en bout, et n'ajoutez d'autres langues qu'ensuite. Valider le processus sur deux langues coûte bien moins cher que de découvrir un problème structurel sur six.
Négociation de langue : comment Drupal décide quelle langue servir
La négociation de langue est la fonctionnalité centrale qui détermine quelle langue un visiteur voit, et bien la configurer est essentiel à la gestion multilingue. Drupal peut détecter la langue voulue à partir de plusieurs signaux, appliqués dans un ordre que vous contrôlez : l'URL (un préfixe de chemin comme /fr ou un domaine), la préférence du compte utilisateur, les paramètres de langue du navigateur, la session, ou une langue par défaut fixe.
Pour la plupart des sites, la détection basée sur l'URL est la méthode principale la plus adaptée — elle donne à chaque version linguistique une adresse distincte, partageable et indexable, et garde un comportement prévisible. La négociation peut aussi être configurée séparément pour le contenu et pour l'interface d'administration, ce qui permet à de nombreuses équipes de garder le site public entièrement localisé tout en laissant le back-office d'administration dans une seule langue de travail pour leurs éditeurs. L'ordre de ces méthodes de détection compte : placez le signal le plus précis et le plus intentionnel (l'URL) au-dessus des signaux plus souples (la langue par défaut du navigateur) afin qu'un choix délibéré l'emporte toujours.
Choisir un flux de traduction
L'interface de traduction native de Drupal suffit pour un petit site, mais à mesure que le volume de contenu et la taille de l'équipe augmentent, c'est le flux de travail qui détermine réellement si un site multilingue reste à jour. Il existe trois approches principales, et la bonne dépend de l'échelle et de l'origine des traductions.
- Traduction manuelle, dans Drupal : Les éditeurs et traducteurs se connectent et traduisent directement via l'interface native. Idéal pour les petits sites — pensez à un site de 20 à 30 pages en deux langues — où le volume est faible et où tout le monde travaille dans Drupal.
- Export/import avec fichiers de traduction : Le contenu est exporté (généralement au format XLIFF), envoyé aux traducteurs, puis réimporté. Convient aux équipes qui travaillent avec des linguistes externes n'utilisant pas Drupal, et à un contenu qui se met à jour par lots prévisibles.
- TMGMT (Translation Management Tool) : Un module contribué qui transforme la traduction en un processus géré au sein de Drupal — création de tâches de traduction, attribution à une équipe interne ou à des prestataires externes, suivi du statut, et intégration avec des services et moteurs de traduction automatique. C'est le choix standard pour les sites moyens à grands et les volumes de contenu élevés.
Deux ajouts renforcent la robustesse de ces flux. Content Moderation permet de définir comment une traduction passe de brouillon à relecture puis à publication, afin qu'une version traduite automatiquement ou en cours ne soit jamais mise en ligne par accident. Et les Translation Views, ou les tableaux de bord de traduction, permettent de suivre la couverture — ce qui est traduit, ce qui est en cours, et ce qui manque — sur l'ensemble du site. Pour la plupart des projets moyens à grands, un hybride de TMGMT et de relecture humaine est le juste équilibre : l'automatisation pour la rapidité, une personne pour la qualité sur les pages qui comptent.
Erreurs courantes en multilingue et comment les éviter
La plupart des problèmes multilingues dans Drupal proviennent d'une poignée de décisions évitables plutôt que de limites de la plateforme :
- Décider trop tard de la traduisibilité des champs : Modifier quels champs sont traduisibles après que des traductions existent déjà peut entraîner une perte de données. Modélisez les champs traduisibles versus partagés avant de commencer la traduction à grande échelle.
- Traduire le contenu mais oublier la configuration : Un site avec des articles entièrement traduits mais un menu, un nom de site ou une vue non traduits donne une impression cassée. Traitez la traduction de configuration comme faisant partie intégrante du travail, et non comme un à-côté.
- Publier de la traduction automatique brute : La traduction automatique est un bon point de départ, mais pas une finalité ; un résultat non relu peut être mal rédigé et nuire à la confiance. Faites-le passer par une relecture humaine pour tout ce qui compte.
- Utiliser des drapeaux pour les langues : Un drapeau est un symbole de pays, pas de langue. Étiquetez le sélecteur avec les noms des langues pour éviter de dérouter les locuteurs d'une langue partagée entre plusieurs pays.
- Aucun repli pour les traductions manquantes : Décidez de ce qui se passe quand une page n'a pas de traduction — revenir à la langue par défaut ou la masquer — plutôt que de laisser les visiteurs sur une page vide ou cassée.
- Restructurer les widgets de traduction sans précaution : Avec du contenu structuré comme les Paragraphs, passer à une traduction asymétrique après que des traductions existent déjà peut entraîner une perte de données. Testez d'abord les changements structurels sur une copie.
Une bonne gestion multilingue relève surtout de la discipline : modéliser le contenu une seule fois, traduire les trois couches, et donner à chaque langue une URL prévisible et un flux de travail clair. Bien gérer le volet SEO de tout cela — hreflang, structure des URL et mots-clés par marché — est une discipline connexe mais distincte, que nous couvrons dans notre guide sur le SEO multilingue dans Drupal, et qui s'appuie directement sur la même couche linguistique de base décrite dans notre guide SEO Drupal.
Questions fréquentes sur la gestion multilingue dans Drupal
Ai-je besoin d'un module contribué, ou le cœur suffit-il ?
Pour la plupart des sites, les quatre modules principaux suffisent à ajouter des langues et à traduire le contenu, l'interface et la configuration. Vous vous tournez vers des modules contribués quand les besoins grandissent : TMGMT pour des flux de traduction gérés et une intégration avec des prestataires ou des moteurs de traduction automatique, une amélioration du sélecteur de langue pour un widget plus convivial, ou un module d'import/export de traduction de configuration lorsque les traductions sont préparées en dehors de Drupal. Commencez avec le cœur, et n'ajoutez des outils que là où un besoin réel apparaît.
Dois-je utiliser un seul site multilingue ou une configuration multisite ?
Pour la plupart des organisations, une seule installation Drupal avec des versions linguistiques (par exemple /en et /fr) est le meilleur choix : une base de code unique, des structures de contenu partagées et des mises à jour centralisées. Une configuration multisite a surtout du sens lorsque chaque marché a besoin d'une véritable séparation opérationnelle — équipes différentes, contenu différent, gouvernance différente. Le modèle mono-site garde la gestion plus simple et centralise l'autorité, c'est pourquoi il constitue la recommandation par défaut pour la plupart des projets multilingues.
Puis-je changer quels champs sont traduisibles après le lancement ?
C'est possible, mais cela comporte un risque une fois que des traductions existent déjà — modifier la traduisibilité d'un champ peut entraîner une perte de données. L'approche sûre consiste à décider des champs traduisibles versus partagés pendant la modélisation du contenu, avant la traduction à grande échelle. Si un changement s'avère inévitable plus tard, testez-le sur une copie de préproduction et faites une sauvegarde au préalable, afin de pouvoir vérifier qu'aucune traduction existante n'est affectée avant de l'appliquer en production.