Traduire votre jeu est un moyen très intéressant pour toucher un public plus important et faire connaître votre jeu de plus de monde. Certains n’ont même pas (ou très peu) besoin de traduction, comme Machinarium, où il n’y a aucun mot, ou même des vieux jeux comme Mega Man, où l’action primait. Malheureusement, si vous faites de la fiction interactive ou du jeu narratif, la traduction (ou localisation, ce dernier terme regroupant également la nécessité de traduire les références culturelles) est un travail conséquent.

Avant de nous lancer, un avertissement : traduire, c’est du travail, et c’est même un travail ! Bien sûr, vous aurez peut-être la chance de trouver quelqu’un qui vous fera la traduction gratuitement, par passion, surtout si vous avez un petit projet de jeu indé gratuit. Mais ça représente un travail minutieux de plusieurs dizaines d’heures, et surtout une expertise : il est normal de rétribuer un traducteur, surtout si vous voulez que le travail fourni soit de qualité !

Dans l’article d’aujourd’hui, nous allons faire un petit tour des différentes techniques de localisation d’un jeu, et de la façon dont elles s’imbriquent avec nos outils.

Je remercie Mia, Nighten et Xtooph pour leur aide dans la préparation de l’article, V1nce pour les discussions sur Somewhere, et Paulloz pour les infos sur Enterre moi, mon amour !

Traduire un jeu vidéo, cas général

Comment ça se passe, en général, la traduction d’un jeu vidéo ? Je ne sais pas, mais ça a l’air d’être le bazar ; il y a autant de processus et d’outils que de jeux, ou presque… Dans tous les cas, on peut dégager plusieurs choses importante pour une classification grossière des processus.

Combien d’exécutables ?

Un exécutable c’est le fichier du jeu, sur lequel le joueur clique pour jouer. Ici, il y a essentiellement deux approches.

Un seul fichier exécutable

La première catégorie de jeux traduits, c’est ceux où tout est dans le même exécutable : on peut choisir sa langue une fois qu’on a ouvert le jeu, et les fichiers du jeu contiennent toutes les traductions. Le programme a du code qui permet de choisir et d’afficher la bonne langue ; en général, on peut même changer de langue en cours de jeu, et les sauvegardes restent compatibles.

Un exécutable par langue

Vous avez à l’opposé les jeux où il y a différents fichiers exécutables, et il faut télécharger celui qui correspond à votre langue. Dans ce cas, c’est un peu plus compliqué pour l’auteur (plus de fichiers, il faut bien propager les corrections de bugs à tous les fichiers), et le joueur ne peut pas changer de langue en plein milieu tout en conservant ses sauvegardes (sauf éventuellement si  les sauvegardes sont indépendantes de la langue et peuvent être ouvertes par tous les exécutables). Cependant, ça peut être utile si vous avez beaucoup de contenu traduit (texte, doublages, etc.) : avec plusieurs exécutables, le joueur ne télécharge que les données de sa langue, et n’a pas besoin de télécharger tous les doublages en toutes les langues par exemple. Cette approche est très bien prise en charge par des plateformes comme Steam, par exemple, qui vous permet de donner un exécutable par langue, et distribue le bon fichier au joueur en fonction de ses préférences de langue.

Alors bien sûr, la classification est un peu plus compliquée que ça… Vous pouvez faire un exécutable par langue, puis faire un exécutable qui ne contient qu’un menu de sélection de la langue, pour recoudre tous ces exécutables en un seul. Une autre approche est d’avoir, pour chaque langue, un fichier de code ou de scripting, qui décrit tout ce que doit faire le jeu (dont le texte à afficher, donc, mais aussi tout le reste) ; votre exécutable ne fait alors que choisir le bon fichier de script, puis l’exécute. Cette dernière approche est celle des développeurs d’Enterre moi, mon amour par exemple, qui ont en plus codé des fonctions spéciales pour que les sauvegardes marchent même après avoir changé de langue (et donc de fichier de script).

Comment tout remplacer ?

Un autre critère dont on va parler est le degré d’automatisation derrière la tâche de remplacer les chaînes de caractère par leur traduction.

À la main

La première approche, c’est de le faire soi-même : quelqu’un fait des copier-coller directement dans le code aux bons endroits pour rajouter les traductions. En fait, c’est mine de rien un processus bien plus répandu que ce que vous pouvez croire, et il y a pas mal de studios de pros qui fonctionnent avec des fichiers Excel pour leurs traductions et qui font ensuite la réinjection de la traduction dans le jeu à la main. L’inconvénient de cette méthode, à part les crampes aux doigts, c’est que si on va directement dans le code, on risque d’introduire des bugs par mégarde, en collant au mauvais endroit… et ça n’est pas toujours détectable !

Personnellement, je suis vacciné… Il m’est arrivé exactement ceci pour Gossip, en 2009 : un mauvais copier-coller, et une partie du code d’un personnage a disparu sans que je le voie. Manque de pot, le personnage était celui qui donnait des indices pour avancer… Donc tout le monde est resté bloqué. J’ai fini 2e de l’Introcomp à seulement 0,1 du premier. Grmf.

Avec un outil

Une autre approche est de travailler à partir d’un fichier qui donne les correspondances entre une chaîne de caractères et sa traduction, et d’avoir un outil qui se charge de tout remplacer automatiquement (ou mieux, un bout de code qui fait le remplacement au moment où la chaîne de caractères doit être affichée). C’est une bonne idée, car ça sépare le texte du code : si vous corrigez un bug dans le code, ça n’affecte pas la traduction et ça vous permet de propager les changements sans problèmes. Cependant, souvent, si vous changez une phrase dans l’original, le programme a tendance à supprimer les traductions (vu que ce n’est plus la même phrase…), ce qui peut être embêtant.

Mais encore faut-il avoir l’outil ; il est souvent fait maison, et avec un format de sortie bien souvent non standardisé. Pas que les formats n’existent pas, au contraire : il y a le format .po utilisé par de nombreux logiciels libres ; le JSON, un format d’échange de données (et donc notamment de tableaux) couramment utilisé en JavaScript ; le format XML, un peu plus vieux mais toujours utilisé… (Sans compter les nombreux formats maison que tous les développeurs aiment bien créer en même temps qu’ils créent leur outil de traduction…)

À noter que c’est la solution la plus rapide une fois que vous avez l’outil ; ainsi, un grand studio de jeu vidéo (ou un studio bien organisé) a sans doute son propre outil pour intégrer les traductions au jeu (même à partir d’un tableur Excel, qui peut toujours être reconverti en quelque chose de plus simple comme le XML ou le CSV). Il ne semble pas exister par contre d’outil public et générique qui permettrait de le faire pour des grandes classes de jeux vidéo ; ça reste bien souvent artisanal (copier-coller, ou faire son propre petit outil spécifique…), surtout chez les petits indés.

Et pour mon moteur de jeu préféré ?

Passons maintenant en revue les solutions existantes pour les outils de narration interactive.

Pour n’importe quel jeu et n’importe quel outil, il y a une approche qui marche toujours : c’est celle où il y a plusieurs exécutables, et où vous n’automatisez rien dans le remplacement des chaînes de caractère. Concrètement, vous voulez votre jeu en anglais : vous copiez-collez le dossier, vous ouvrez le nouveau dossier, et vous traduisez tout à la main… C’est toujours faisable, mais ça n’est vraiment pas la meilleure façon.

Inform 6 / Inform 7

Inform servant à créer des fictions interactives avec un analyseur syntaxique, qui analyse la commande du joueur tapée en langage naturel, traduire son jeu est un peu plus compliqué que simplement traduire le texte qui est affiché : il faut aussi que le parser reconnaisse la bonne langue ! Bien heureusement, il y a des dizaines de langues prises en charge : pour cela, il suffit d’utiliser la bonne bibliothèque lors de la compilation du jeu. Mais malheureusement, cela veut dire que le parser ne peut reconnaître qu’une seule langue (à moins qu’on s’appelle Natrium729 et qu’on lui change ses entrailles soigneusement, et même là il y a des limites). Donc, si vous voulez traduire votre jeu, il vous faut nécessairement un exécutable par jeu, dans l’état actuel des choses (mais si vous voulez coder un interpréteur spécial qui traduit les commandes du joueur en plus des chaînes de caractère du jeu…).

Vous avez alors le choix de la méthode pour l’automatisation du processus. La majorité du temps, c’est le bon vieux copier-coller / remplacer ; c’est ce qui a été utilisé pour la majorité des traductions de jeux Inform. Mais comme je l’ai dit plus haut, j’ai eu une mauvaise expérience avec cette méthode, et j’ai donc codé un outil qui permet d’automatiser le remplacement. Cet outil s’appelle scriptTrad et il y en a un pour Inform 6 et un autre pour Inform 7 : donnez-lui votre code source, et il le parcourt et extrait automatiquement les chaînes de caractère à traduire ; il construit un dictionnaire, sur lequel vous travaillez, puis il remplace également automatiquement les chaînes par leur traduction. Le format du dictionnaire est le format standard .po ; comme il y a plein d’outils qui prennent en charge ce format, c’est encore plus simple et sûr de manipuler votre texte. J’ai utilisé cet outil pour traduire Life on Mars? en anglais pour l’IFComp, et pour traduire Shade vers le français (avec MonsieurBouc), et franchement, c’est pas pour me vanter, mais ça marche pas mal.

Cet outil ne règle pas tout non plus ; il y a des ajustements plus ou moins gros (plus en Inform 7 qu’en Inform 6) à faire pour que tout marche bien (car chaque langue a ses besoins spécifiques, et il y a toujours une étape de tests et éventuellement d’enrichissement à prévoir — mais ça permet d’accélérer le processus de façon importante !

Twine

Pour ce qui est de Twine, plusieurs approches existent. On peut par exemple vouloir créer un fichier Twine (HTML) par langue ; il faudrait alors avoir plusieurs fichiers twee, ou plusieurs projets Twine, et passer de l’un à l’autre. Pour simplifier la tâche, j’ai créé une version de scriptTrad pour Twine 1, qui prend un fichier HTML (le fichier final) et crée, de la même façon que pour Inform, un dictionnaire au format .po, qu’il vous suffit de modifier pour avoir des versions traduites de votre jeu. Par contre, je vous avoue que le script a quelques soucis avec certains fichiers Twine, surtout les plus complexes avec beaucoup de JavaScript… Si quelqu’un est intéressé, j’essaierai de m’y repencher et de corriger les bugs !

Une autre approche est de mettre toutes les langues dans le même projet Twine, ce qui a en plus l’avantage de laisser le joueur changer de langue durant le jeu. C’est l’approche décrite par Mia dans le tutoriel que nous avons publié il y a quelques mois ; elle a utilisé cette technique pour de nombreux jeux et de nombreuses langues, même si la mise en place d’une traduction s’accompagne de nombreux copier-coller. C’est également l’approche empruntée par les développeurs de Somewhere dans les premières versions de leur jeu, même s’il se murmure qu’ils ont depuis emprunté une autre approche un peu plus efficace.

Ink

Tout comme pour Twine et Inform (voire même encore pire), il n’y a pas vraiment d’outil qui faciliterait la tâche pour la traduction d’un jeu en Ink ; c’est en tout cas une discussion récurrente parmi ceux qui programment en ink. On a mentionné toutefois plus haut la méthode des développeurs d’Enterre-moi, mon amour : un fichier ink par langue, un exécutable qui sélectionne le bon fichier ink. Par contre, pour créer chaque fichier ink, ça a été la bonne vieille méthode du copier-coller à partir d’un fichier Excel, malheureusement pour eux…

Ren’Py

Ren’Py est un moteur de développement de visual novels, et il se trouve qu’il a un outil très utile pour les traductions, développé avec l’aide d’un traducteur professionnel : Ren’Py se charge de parcourir le code source et d’extraire les chaînes de caractère à traduire, qu’il met dans un fichier ; à vous ensuite de traduire le fichier, et c’est bon ! C’est une approche très similaire à celle de scriptTrad (youpi, c’était donc une bonne idée), avec les mêmes contraintes (si vous changez une phrase dans le texte original, vous perdez les traductions vu que ce n’est plus considéré comme la même phrase), voire même un peu plus : à cause du format de jeu, il faut également faire attention au nombre de caractères pour que ça rentre dans la boîte de dialogues ! Une fois la traduction achevée, Ren’Py vous permet de créer un seul exécutable avec un écran de sélection de la langue ; vous pouvez également créer plusieurs exécutables, mais ça n’est que rarement fait.

RPG Maker

On termine ce tour d’horizon par l’outil RPG Maker, qui permet de créer des RPG facilement. Je n’ai pas (encore !) d’expérience avec cet outil, mais j’ai eu de l’aide pour cet article, alors voilà ce que j’en sais : il semblerait qu’il y ait un plugin pour la dernière version (RPG Maker MV) pour extraire, sous format JSON, les chaînes de caractère à traduire du jeu, et les remettre dans le jeu une fois traduites. Mais (des dires de Mia) ce plugin n’est pas très facile à utiliser, et c’est presque plus simple de tout remplacer à la main en copiant-collant… De plus, il semblerait qu’il faille avoir un exécutable par langue. Notons aussi que pour les versions précédentes, un autre outil existait avec une approche différente : il permettait de générer un patch, c’est-à-dire un programme modifiant l’exécutable original ; très utile si vous voulez traduire un jeu qui n’est pas le vôtre et dont vous n’avez pas le code source !

Lancez-vous !

J’espère que cet article vous aura permis d’y voir plus clair concernant les stratégies et les outils de traduction que vous pourrez utiliser pour vos jeux ! N’hésitez pas à me dire si j’en ai oublié ou si vous avez des retours d’expérience !