Traduire un jeu de mots : pourquoi chaque langue a besoin de son propre dictionnaire

Je l'ai mentionné en passant dans un article précédent : « traduire un jeu de lettres, c'est reconstruire son dictionnaire ». La phrase mérite mieux qu'une parenthèse. AbcDonjon est disponible en cinq langues — français, anglais, espagnol, italien, portugais — et pour chacune d'entre elles, il n'existe pas un seul fichier de traduction, mais un dictionnaire de jeu entièrement distinct.

Traduire l'interface ne traduit pas le jeu

Un menu, un bouton « Rejouer », un score : ça se traduit comme n'importe quelle application, avec un fichier de chaînes par langue. Le problème d'AbcDonjon est ailleurs. C'est un roguelite de mots croisés : le joueur avance dans un donjon en résolvant des grilles, et chaque case du jeu est une paire réponse-indice. Traduire l'interface d'un tel jeu et le laisser en français dans son contenu reviendrait à sous-titrer un jeu sans traduire ses dialogues. Le contenu à traduire, ici, ce n'est pas l'habillage — c'est le jeu lui-même.

Un dictionnaire entier par langue

Le lexique français d'AbcDonjon compte 739 entrées. Les lexiques anglais, espagnol, italien et portugais en comptent chacun autour de 450 — construits comme des vocabulaires natifs, pas comme des traductions mot à mot du français. Chaque entrée porte une réponse, un indice, une difficulté de 1 à 5, et un thème parmi onze : eau, feu, nature, terre, ombre, lumière, métal, science, mort, bêtes, neutre.

Ces thèmes ne sont pas de la décoration éditoriale. Dans le moteur du jeu, ils déterminent le type de dégâts qu'un mot inflige au combat — un mot du thème « feu » n'agit pas comme un mot du thème « eau » face à un ennemi donné. Ce qui veut dire que chaque lexique, dans chaque langue, doit répartir ses mots sur les onze mêmes thèmes pour que le système de combat reste équilibré. Le vocabulaire change de langue ; la mécanique qu'il alimente, non.

Les règles d'écriture changent avec la langue

Chaque lexique est produit par un script dédié qui écrit le vocabulaire et le valide avant de générer le fichier JSON consommé par le jeu. La validation impose des règles communes : chaque réponse est repliée en majuscules sans accent (FORÊT devient FORET), doit faire au moins deux lettres, ne peut apparaître qu'une seule fois dans tout le lexique, et chaque indice ne doit correspondre qu'à une seule réponse — sinon la définition devient ambiguë pour le joueur.

Une exception notable : l'espagnol conserve le Ñ comme lettre à part entière plutôt que de le replier vers un N, parce que ce n'est pas un accent mais une lettre distincte de l'alphabet. L'italien et le portugais, eux, replient tous leurs diacritiques (à, è, ì, ò, ù pour l'un ; á, ã, õ, ç, ê pour l'autre) sans exception. Le code de repliement des accents doit donc connaître les particularités orthographiques de chaque langue, pas seulement lire un fichier de vocabulaire.

Le filet de sécurité

Le chargement du lexique suit un ordre de repli : le jeu essaie d'abord le lexique natif de la langue de l'utilisateur, retombe sur le lexique français si le fichier localisé manque ou est vide, et retombe en dernier recours sur un petit lexique codé en dur dans l'application. Cette dernière étape garantit que le jeu démarre toujours, même si un fichier d'assets venait à manquer ou à être corrompu.

Chaque lexique a aussi son propre fichier de tests, qui vérifie automatiquement qu'il contient un nombre de mots suffisant pour rester jouable, que toutes les réponses sont des tokens propres, que les difficultés restent entre 1 et 5, et qu'il n'y a ni réponse dupliquée ni indice ambigu. Ce sont ces tests, pas une relecture manuelle, qui protègent contre l'erreur la plus bête possible : livrer une langue avec un dictionnaire cassé.

Le contraste avec Cendrelune

Cendrelune est localisé dans deux fois plus de langues qu'AbcDonjon — dix, contre cinq — et ça m'a pris beaucoup moins de travail. La raison est simple : c'est un idle game, pas un jeu de mots. Sa mécanique ne dépend d'aucun contenu textuel : localiser Cendrelune, c'est traduire des fichiers de chaînes d'interface, pas reconstruire un système de jeu. Le même auteur, les deux mêmes mains, un coût de localisation qui varie du simple au bien plus que double selon que le texte est de l'habillage ou la matière du jeu.

C'est la leçon que je retiens de cet exercice, au-delà d'AbcDonjon : le coût réel d'une langue supplémentaire ne se lit pas dans le nombre de chaînes à traduire, mais dans la question de savoir si le texte est la mécanique ou son décor. Pour un développeur solo, c'est une question à se poser avant de promettre une langue de plus, pas après.