← Retour au wikiMis à jour le

Difficulté technique
de traduction des jeux

Cinq repères pour comprendre le travail nécessaire, au-delà du nom du moteur.

Le moteur donne une piste, les fichiers font la différence

Ces niveaux sont des repères indicatifs pour retrouver les textes, intégrer la traduction et obtenir un affichage correct. Ils ne mesurent ni la qualité littéraire de la traduction ni le temps nécessaire pour relire les dialogues.

Un même moteur peut relever de plusieurs niveaux selon le jeu, sa version, les fichiers disponibles et les outils compatibles. Chaque fiche précise donc le cas concerné, ce qui facilite le travail et ce qui le complique.

Exemple : un jeu Unity avec des tables de langue bien organisées peut être plus accessible qu’un jeu Ren’Py dont les menus sont entièrement dessinés dans des images. Le nom du moteur ne suffit pas à fixer la difficulté.

Tableau illustré avec des barres de difficulté pour Ren’Py, RPGM, HTML, Wolf RPG, Godot, Unity, Unreal Engine et Autres. Niveaux indicatifs selon le jeu et les outils.

1. Retrouver les textes

Localiser les dialogues, menus et messages. Distinguer ce qui s’affiche à l’écran des identifiants ou commandes techniques.

2. Intégrer la traduction

Charger une langue, modifier des ressources ou utiliser un lecteur compatible, en conservant les liens avec le jeu.

3. Vérifier le rendu

Contrôler les accents, les polices, les retours à la ligne, les images et les textes construits pendant la partie.

Les cinq repères

Les exemples ci-dessous décrivent des configurations de jeu, pas un classement définitif des moteurs.

Niveau 1 — Simple

Cas favorables : textes structurés et méthode d’intégration connue.

Ren’Py

Avec le système de traduction intégré

Ce qui facilite
Les fichiers de traduction du dossier game/tl/ relient les dialogues et les menus à leurs sources.
Ce qui complique
Les interfaces personnalisées, les textes dans les images et les changements d’identifiants lors des mises à jour.

Généralement accessible avec le système natif ; cela ne rend pas chaque jeu automatiquement simple.

RPG Maker MV / MZ

Avec les données standard du moteur

Ce qui facilite
Les dialogues d’événements et les données sont organisés dans des fichiers JSON.
Ce qui complique
Les plugins ajoutant leurs propres textes, les codes de contrôle et les fenêtres trop étroites pour le français.

Ce repère vise MV et MZ. XP, VX et VX Ace utilisent d’autres formats et doivent être étudiés séparément.

Niveau 2 — Intermédiaire

Formats ou scénarios connus, avec des adaptations et des contrôles à prévoir.

WOLF RPG Editor

Avec des outils compatibles avec le jeu

Ce qui facilite
La structure des cartes, des événements communs et des bases de données permet de cibler les textes.
Ce qui complique
L’encodage, les polices, les accents et la taille des fenêtres de dialogue ou de choix.

L’extraction peut bien fonctionner alors que le rendu en français demande encore du travail.

TyranoBuilder / TyranoScript

Avec des scénarios accessibles

Ce qui facilite
Les fichiers .ks permettent de retrouver dialogues, choix et commandes de mise en scène.
Ce qui complique
Les variables, les balises, les menus personnalisés et les textes intégrés aux images.

Les commandes doivent rester intactes. Un fichier .ks n’indique pas forcément Tyrano : KAG emploie aussi cette extension.

Visual Novel Maker

Avec les données et le système de langue accessibles

Ce qui facilite
La gestion des langues et l’organisation des scènes peuvent fournir des correspondances claires.
Ce qui complique
Les scripts, les extensions et les interfaces personnalisées, qui peuvent ajouter des textes ailleurs.

Le contenu réellement exporté doit être examiné : un projet source et un jeu distribué ne se présentent pas toujours de la même manière.

QSP

Avec accès aux textes et au script

Ce qui facilite
Les scènes textuelles et les outils de conversion du projet permettent d’identifier les passages à traduire.
Ce qui complique
Les phrases construites par le script, les variables et les chaînes qui servent aussi à la logique du jeu.

Un jeu très textuel n’est pas forcément un simple document : il faut préserver le code qui relie ses scènes.

Niveau 3 — Difficile

Ressources regroupées, scripts ou affichage nécessitant un travail plus technique.

KiriKiri / KAG

Quand les scénarios sont dans des archives

Ce qui facilite
Des scénarios KAG accessibles rendent les dialogues plus faciles à suivre.
Ce qui complique
Les variantes d’archives XP3, les encodages, les scripts TJS et les interfaces faites sur mesure.

Avec des scénarios déjà accessibles, certains jeux demandent moins de travail que ce niveau ne le laisse penser.

GameMaker / GameMaker Studio

Quand les textes sont intégrés au jeu exporté

Ce qui facilite
Des fichiers de langue externes ou une structure bien comprise par un outil adapté.
Ce qui complique
Les données regroupées dans data.win, les phrases assemblées par le code et les réglages d’affichage.

Trouver le texte ne règle pas forcément les retours à la ligne, les heures ou les limites des fenêtres.

Godot

Quand les textes sont dispersés dans les ressources

Ce qui facilite
Des tables de traduction identifiées et un mécanisme de chargement de langue déjà prévu.
Ce qui complique
Les scènes, scripts et ressources binaires répartis dans un PCK, ainsi que les différences entre exports.

Un jeu avec des fichiers de langue bien organisés peut relever d’un niveau inférieur.

Cocos Creator

Quand les textes sont répartis dans les ressources compilées

Ce qui facilite
Des tables de langue identifiées et un lecteur compatible avec la version de Creator et son format d’export.
Ce qui complique
Les ressources JSON compactées ou encodées, les textes dans les scripts et les images, ainsi que les cadres trop étroits pour le français.

Des fichiers de langue accessibles peuvent rendre le travail plus simple. Les accents, les retours à la ligne et les bulles restent à vérifier en jeu. Electron peut héberger le jeu sans changer son moteur Cocos Creator.

Flash

Quand les textes et les ressources sont intégrés au SWF

Ce qui facilite
L’accès au projet source ou à des textes externes chargés par le jeu.
Ce qui complique
Les textes gérés par ActionScript, les polices intégrées, les animations et les éléments graphiques.

Même après modification des mots, il faut vérifier les caractères disponibles et leur affichage.

Niveau 4 — Très difficile

Les cas complexes : textes dispersés et intégration demandant une adaptation importante.

Unity

Cas complexe, pas une difficulté systématique

Ce qui facilite
Des tables de localisation reconnues, des TextAssets structurés ou un lecteur de traduction compatible.
Ce qui complique
Les multiples sources de texte : assets, bundles, composants, code et interfaces. Le backend Mono ou IL2CPP peut aussi changer la méthode.

Des fichiers de langue séparés peuvent simplifier fortement le travail. Ce niveau décrit les jeux nécessitant plusieurs méthodes ou une adaptation importante.

Unreal Engine

Cas complexe, pas une difficulté systématique

Ce qui facilite
Des ressources de localisation .locres identifiées et un chargement de langue ou de patch maîtrisé.
Ce qui complique
Les ressources préparées pour l’exécution, les formats PAK ou IoStore, les textes hors des tables et les particularités du jeu.

La présence de fichiers de langue utilisables peut ramener le travail à un niveau plus accessible.

Variable

La technologie ou l’étiquette ne suffit pas : il faut examiner les fichiers et les outils disponibles.

HTML5 / jeux web

Technologies web, pas un moteur unique

Ce qui facilite
Des fichiers de langue séparés ou des textes clairement identifiés dans les pages et les données.
Ce qui complique
Le code généré ou compacté, les phrases dynamiques et les interfaces dessinées dans des images ou un canevas.

Peut être très accessible ou demander une adaptation conséquente, selon la façon dont le jeu a été conçu.

Java

Langage et environnement, pas un moteur unique

Ce qui facilite
Des ressources de langue externes ou un projet source permettant de modifier puis reconstruire le jeu.
Ce qui complique
Les textes intégrés aux classes compilées et les phrases produites par le code.

La présence d’un JAR ne suffit pas à conclure : il faut regarder les ressources qu’il contient.

ADRIFT

Selon le projet et sa version

Ce qui facilite
Un projet exploitable avec un éditeur compatible et des descriptions clairement identifiées.
Ce qui complique
La logique des actions, les règles de reconnaissance des commandes et la compatibilité entre versions.

Les fichiers d’aventure TAF et les paquets BLORB ne se traitent pas comme de simples documents texte.

TADS

Selon l’accès au projet source

Ce qui facilite
Le code source et les ressources du jeu permettent de suivre la logique des descriptions et des messages.
Ce qui complique
Un jeu fourni uniquement sous forme compilée, ainsi que la grammaire et le vocabulaire des commandes.

Traduire les descriptions ne suffit pas toujours : l’interpréteur doit aussi comprendre ce que le joueur saisit.

RAGS

Selon l’accès aux données et la compatibilité des outils

Ce qui facilite
Des outils adaptés capables d’exposer les textes et la structure du jeu.
Ce qui complique
Les actions, les conditions et la vérification du fonctionnement après modification ou conversion.

La présence de beaucoup de texte ne garantit pas une modification simple du fichier de jeu.

Others, Electron et NW.js

Une catégorie ou un environnement d’exécution

Ce qui facilite
Identifier d’abord le vrai moteur et les fichiers qui portent les dialogues et les menus.
Ce qui complique
Déduire la méthode à partir de la seule étiquette « Others » ou d’une archive, sans examiner son contenu.

Others est une catégorie de rangement. Electron et NW.js exécutent des applications qui peuvent utiliser des moteurs très différents.

Sur quoi reposent ces repères ?

Les descriptions s’appuient sur l’organisation des ressources et les systèmes de traduction des moteurs. Les niveaux sont une appréciation pratique des cas décrits, et non une notation officielle des éditeurs.