Rendre un site web multilingue signifie traduire deux moitiés distinctes : l'interface que le site affiche lui-même, et le contenu stocké dans votre CMS. La plupart des outils gèrent l'une et facturent l'autre, ce qui explique pourquoi la localisation arrive si souvent comme une option payante ou un exercice de duplication manuelle. Voici ce que chaque moitié implique réellement, ce qu'il faut délibérément laisser dans une seule langue, et comment éviter l'état à moitié terminé qui fait qu'un site traduit paraît cassé.
Pourquoi le multilingue est-il souvent une option payante ?
Parce que les deux moitiés sont des problèmes réellement différents. Traduire l'interface implique le routage, un sélecteur de langue, et une copie de chaque libellé, bouton et message d'erreur. Traduire le contenu implique que chaque ligne de chaque collection ait besoin d'une version par langue, ce qui change la structure de votre base de données et pas seulement ses valeurs. Les outils construits autour d'un document de type page builder ont tendance à résoudre le premier problème et à greffer le second plus tard, généralement sous forme de plugin avec son propre abonnement.
Ce dont la moitié « site » a besoin
Trois choses, et toutes les trois doivent être cohérentes entre elles.
- Ses propres routes. Chaque langue a besoin de vraies URLs distinctes, afin qu'une page en français puisse être liée, partagée et indexée de manière autonome. Une langue qui n'existe que comme un basculement côté client est invisible pour les moteurs de recherche.
- Un texte d'interface traduit. Navigation, boutons, libellés de formulaires, messages de validation, états vides. C'est la partie que l'on sous-estime le plus, car elle est disséminée dans tout le site plutôt que regroupée dans un seul fichier de contenu.
- Un sélecteur qui survit à la navigation. Changer de langue doit vous garder sur la page que vous lisiez, pas vous renvoyer à la page d'accueil.
Ce dont la moitié « contenu » a besoin
Chaque champ traduisible a besoin d'une valeur par langue, et l'éditeur doit afficher cela comme un seul champ avec des onglets de langue plutôt qu'un empilement de colonnes dupliquées. La différence semble cosmétique, elle ne l'est pas : une collection avec huit champs traduisibles sur quatre langues, ce sont trente-deux colonnes brutes, que personne ne peut modifier de manière fiable.
Il faut aussi un repli. Quand une traduction manque, le site doit discrètement afficher la langue par défaut plutôt qu'un titre vide. C'est précisément ce comportement qui permet de traduire progressivement au lieu de retarder un lancement jusqu'à ce que chaque ligne soit terminée.
Que ne faut-il pas traduire ?
Plus de choses qu'on ne le pense, et se tromper ici crée du travail pour toujours. Laissez ceci dans une seule langue :
- Les noms propres. Le nom d'une personne, le nom de votre entreprise, un nom de produit, une ville. Ils s'écrivent de la même façon partout, et leur donner un champ par langue finit toujours par produire une orthographe légèrement différente dans l'un d'eux.
- Les prix, les dates et les identifiants. Formatez-les selon la locale au moment de l'affichage plutôt que de stocker une copie séparée.
- Les images et les fichiers. Sauf si l'image elle-même contient du texte, un seul fichier sert toutes les langues.
Le test consiste à se demander si le texte diffère réellement d'une langue à l'autre. Les titres, descriptions et corps de texte, oui. Un nom de famille, non.
Les variantes régionales sont-elles des langues différentes ?
Traitez-les comme différentes, oui. L'anglais britannique et l'anglais américain sont des publics distincts avec une orthographe, des expressions et souvent une tarification différentes ; chacun mérite donc sa propre traduction plutôt que d'hériter de l'autre. N'importe quel code de langue standard doit fonctionner, y compris les codes régionaux comme pt-BR ou en-GB, et un outil qui n'offre qu'une liste déroulante fixe de langues majeures finira par vous bloquer.
Comment Modulify gère-t-il cela ?
Comme une seule demande plutôt que deux projets. Demander une langue met en place ensemble le routage, le texte d'interface, les champs CMS par langue et la traduction des lignes existantes, afin que vous ne vous retrouviez pas avec un site qui change de langue mais affiche du contenu en anglais en dessous. Les valeurs non traduites reviennent automatiquement à la langue par défaut, les langues peuvent être supprimées, et la langue par défaut peut être changée plus tard sans perdre le texte d'aucune des deux langues. Il n'y a pas de limite au nombre de langues qu'un projet peut avoir, ni de coût séparé pour la localisation.
Qu'en est-il du SEO ?
De vraies routes par langue constituent l'essentiel de la réponse, car chaque version peut alors être explorée, indexée et liée indépendamment. Au-delà de cela, conservez la même structure de page d'une langue à l'autre pour qu'une page traduite se positionne sur ses propres mérites plutôt que de ressembler à une copie superficielle, et résistez à la tentation de tout traduire automatiquement d'un coup. Cent pages mal traduites performent moins bien que dix bonnes pages, et elles sont bien plus difficiles à corriger ensuite.
Que vérifier avant de s'engager
Quatre questions à poser, quel que soit l'outil évalué :
- Chaque langue a-t-elle sa propre URL, ou s'agit-il d'un simple basculement côté client ?
- Le CMS affiche-t-il un seul champ avec des onglets de langue, ou un champ par langue ?
- Que se passe-t-il quand une traduction manque : repli ou champ vide ?
- La localisation est-elle incluse, ou s'agit-il d'un plan ou d'un plugin séparé ?
Ces quatre réponses en disent plus que n'importe quelle liste de fonctionnalités. Pour une vue d'ensemble sur la façon dont un site est construit de cette manière, commencez par le guide complet du prompt au site en ligne, et consultez pourquoi un CMS relationnel compte pour la moitié structurelle de la même histoire.
