Prima Pagina.
EN

12 juin 2026Le moteur

Servir 21 langues depuis un seul moteur : architecture et contraintes

Le moteur utilise une couche d’internationalisation basée sur des fichiers JSON de traduction par langue, couplée à un système de templates paramétriques. Chaque template reçoit les chaînes dans la langue cible et les données locales adaptées. La cohérence des traductions est vérifiée automatiquement : toute clé manquante dans un fichier de langue bloque le build.

Structure des fichiers de traduction et gestion des clés

Chaque langue dispose d’un fichier JSON dont les clés sont des identifiants en anglais (snake_case) et les valeurs sont les traductions. La langue de référence est le français : tout ajout de clé en français doit être propagé dans les 20 autres fichiers avant que le build puisse passer. Un script de vérification compare les clés des 21 fichiers et liste les clés manquantes.

Les traductions sont produites par des traducteurs natifs pour les langues principales (anglais, espagnol, allemand, portugais, italien, néerlandais) et par des traducteurs professionnels avec relecture native pour les 15 autres langues. Aucune traduction automatique non relue n’est utilisée dans les fichiers de production : c’est une règle absolue de la chaîne éditoriale.

Gestion des spécificités grammaticales par langue

Certaines constructions françaises ne se traduisent pas mécaniquement. Le pluriel en arabe a six formes grammaticales ; le polonais a trois formes de pluriel ; le russe distingue les génitifs singulier et pluriel. Le système de traduction supporte les formes plurielles via une syntaxe de pluralisation inspirée de ICU MessageFormat : {count, plural, one {# résultat} other {# résultats}}.

Les noms propres (communes françaises, régions, départements) ne sont pas traduits dans les fichiers de traduction : ils sont passés directement comme paramètres de template. Un paramètre non traduit est affiché tel quel. Cette règle évite les erreurs de traduction sur des noms géographiques qui n’ont pas d’équivalent dans la langue cible.

Routage et balises hreflang

Chaque page existe dans les 21 langues sous des URLs distinctes structurées par préfixe de langue (/fr/, /en/, /de/, etc.). Les balises hreflang sont générées programmatiquement pour chaque page avec les 21 variantes, incluant x-default pointant vers la version française. La génération incorrecte de hreflang (URL manquante, code langue invalide) est vérifiée par le pipeline QA.

Le routage côté serveur utilise le header Accept-Language pour la redirection initiale uniquement. Une fois la langue sélectionnée, le préfixe d’URL est utilisé comme source de vérité. Cette approche évite les conflits entre la préférence navigateur et le choix explicite de l’utilisateur stocké en cookie.

Questions fréquentes

Comment gérez-vous les langues avec écriture droite-à-gauche (RTL) ?

L’arabe et l’hébreu sont les deux langues RTL de notre corpus. Le template ajoute dir=’rtl’ et lang=’ar’ ou lang=’he’ sur l’élément html. Les feuilles de style utilisent les propriétés CSS logiques (margin-inline-start au lieu de margin-left) pour s’adapter automatiquement à la direction.

Une nouvelle langue peut-elle être ajoutée sans modifier le moteur central ?

Oui, à condition de fournir un fichier de traduction complet (toutes les clés) et de configurer le code langue dans le fichier de routage. Le moteur central n’est pas modifié. La mise en production d’une nouvelle langue passe par le même pipeline QA que les autres contenus.