Comment traduire un jeu vidéo avec l'IA

La localisation de jeu commence par un fichier que votre moteur a déjà écrit pour vous, et l’objectif est d’envoyer ce fichier vers un outil capable de le lire tel quel. Unity vous donne du XLIFF ou du CSV. Unreal vous donne du PO. Godot propose les deux. Aucun d’entre eux n’a besoin d’être remodelé au préalable.

Ce guide est la version complète : ce que implique réellement la localisation de jeu, pourquoi elle est rentable, quel fichier chaque moteur vous fournit, ce que vous pouvez ou ne pouvez pas demander selon le format de ce fichier, comment la plateforme gère une tâche aujourd’hui, et comment confier tout ce cycle à un agent IA pour qu’une passe en dix langues soit une seule décision plutôt que quarante clics.

Ce que implique réellement la localisation de jeu

La localisation se compose de quatre tâches distinctes que les gens résument en un seul mot, et savoir laquelle vous occupez permet d’éviter la plupart des problèmes.

1. L’internationalisation, qui concerne le code, pas la langue. Votre jeu doit être capable d’afficher une autre langue : aucun texte intégré dans une texture, aucune phrase assemblée par concaténation de chaînes, une police avec les glyphes nécessaires et des mises en page qui supportent l’allongement d’un libellé. Chaque moteur dispose d’un système pour cela, et c’est là que les chaînes de caractères finissent par résider.

2. L’extraction, que le moteur effectue. Unity regroupe vos textes dans des String Table Collections. Le Localization Dashboard d’Unreal les rassemble dans une cible et les exporte. Godot lit un tableur ou un catalogue gettext. Le résultat de cette étape est le fichier que vous allez traduire.

3. La traduction, c’est l’objet de cet article. Un fichier en entrée, un fichier en sortie, dans le même format.

4. La réimportation et les tests. Le fichier retourne à sa source, le jeu est recompilé, et quelqu’un lit le menu principal en allemand pour vérifier que rien ne dépasse.

La seule étape qui doit sortir de votre moteur est la troisième. Tout outil qui vous demande de restructurer le fichier avant de pouvoir le traduire ajoute une cinquième tâche dont personne n’a besoin.

Pourquoi localiser ?

C’est un argument de marché, pas une question de finition. Un jeu publié en anglais est découvrable et jouable par ceux qui lisent l’anglais, et le reste du monde demeure le reste du monde.

L’enquête “Can’t Read, Won’t Buy” de CSA Research, menée auprès de 8 709 consommateurs dans 29 pays, a révélé que 40% des consommateurs n’achèteront pas sur des sites Web dans une autre langue, et que 76% préfèrent acheter des produits dont les informations sont dans leur propre langue. Cette recherche porte sur les achats en ligne en général plutôt que spécifiquement sur les jeux, ce qui est précisément pour cela qu’il est utile de la citer ici : cette préférence n’est pas une particularité du gaming, c’est ainsi que les gens achètent n’importe quoi.

Trois autres effets importants pour un jeu en particulier, sans chiffre associé, car nous n’en avons pas de publiable :

• Visibilité sur les stores. Une page de store dans une seule langue est recherchable dans une seule langue. Les titres, descriptions et tags représentent trois écrans de texte face à quarante heures de contenu.
• Avis et remboursements. Un joueur qui ne peut pas lire un tutoriel écrira un avis sur le tutoriel.
• Portée par unité de travail. Vos systèmes, vos arts et votre audio sont déjà terminés. Le texte est l’élément le moins coûteux à dupliquer dans votre projet.

Si votre jeu contient quelques centaines de chaînes, cela représente un week-end de travail minutieux dans tous les cas. Au-delà de quelques milliers, la différence entre un workflow et une simple habitude peut impacter tout le projet.

Positionnement par rapport à un système de gestion de traduction

Les grands studios gèrent leur localisation via un TMS : memoQ, Phrase, Crowdin, Lokalise et leurs pairs. Ce sont des plateformes de coordination. Elles gèrent les chaînes, la mémoire de traduction, les accès réviseurs, les états du workflow et les intégrations. Pour une équipe de vingt personnes avec des prestataires externes, cette coordination est le produit même.

Si vous êtes entre une et quinze personnes, ce n’est généralement pas votre problème. Vous n’avez pas besoin de gestion de licences, d’états ou de prestataires. Vous avez besoin que les chaînes exportées de ce build soient bien traduites, avec votre vocabulaire inventé intact, avant l’échéance. C’est une tâche, pas une plateforme.

Pour être honnête : un TMS est l’endroit où une grande équipe organise des gens, et AI Glot est l’endroit où un fichier est traduit. De nombreuses équipes conservent l’export de leur moteur comme unique source de vérité, le traduisent ici, puis commitent le résultat, sans aucun troisième système intermédiaire.

Ce que votre moteur exporte et ce que nous lisons

AI Glot lit douze formats: CSV, Excel, JSON et ARB, YAML, XLIFF, PO, Android XML, iOS .strings, Java .properties, .NET RESX, SRT pour les sous-titres, et les archives ZIP contenant l’un de ces formats. Les deux formats réellement utilisés par les moteurs de jeu, le PO pour Unreal et le XLIFF et CSV pour Unity, sont natifs. C’est tout l’intérêt de cette section: il n’y a pas d’étape d’exportation, puis de conversion, puis de traduction, puis de reconversion.

Unity

Le package Localization exporte les String Table Collections de trois manières, et toutes fonctionnent ici.

Le XLIFF, dans ses versions 1.2 et 2.0, est celui conçu pour cela. La documentation d’Unity décrit l’exportation des String Table Collections vers un ou plusieurs fichiers XLIFF, leur modification dans un outil externe, puis leur réimportation avec les traductions mises à jour, ce qui correspond précisément au cycle complet. Envoyez-le au traducteur XLIFF et il reviendra avec les mêmes unités dans le même ordre.

Le CSV est l’autre option d’export, et il est plus lisible si vous voulez le vérifier à l’œil nu. Le CSV de Unity contient une colonne Key avec la clé que vous avez assignée, une colonne Id avec l’ID assigné par Unity, et une colonne par locale dans la String Table. La variante “CSV avec commentaires” ajoute une colonne de commentaire par locale, qui sert de contexte pour le traducteur et ne doit pas être traduite elle-même. Cette distinction se règle en une phrase dans votre instruction, et c’est précisément l’objet de la page du traducteur CSV. Il existe un guide complet des deux exports Unity, avec l’instruction exacte à écrire pour chacun.

Google Sheets est la troisième option: le package synchronise une String Table Collection avec une feuille de calcul. Exportez cette feuille en CSV ou XLSX pour revenir au premier cas.

Unreal Engine

Le Localization Dashboard d’Unreal utilise un pipeline PO. La propre documentation d’Epic, sur la page des outils de localisation, recommande l’utilisation d’un “outil de traduction externe (tel que Poedit, OneSky ou XLOC)” pour le travail de traduction réel plutôt que l’éditeur intégré. AI Glot est cet outil externe, à la différence qu’aucun humain n’a besoin d’être devant l’écran.

Une entrée PO comporte trois parties importantes. La ligne de contexte contient l’identité d’Unreal pour cette entrée, construite à partir de son namespace et de sa clé. La source est le texte anglais. Le slot de traduction reste vide jusqu’à ce que quelqu’un le remplisse. Envoyez le fichier au traducteur PO et seule cette troisième partie sera modifiée.

C’est pourquoi msgctxt et msgid sont traités comme de la structure et non comme du texte. Si vous modifiez l’un ou l’autre, Unreal ne pourra plus faire correspondre l’entrée ou considérera la traduction comme obsolète.

Godot et les builds mobiles

Godot supporte les deux méthodes. Sa documentation indique qu’il possède un importateur qui lit les fichiers CSV, et qu’il supporte également le chargement de traductions écrites au format gettext .po. Dans les deux cas, ce sont des fichiers que nous lisons déjà.

Si vous publiez sur mobile, les chaînes de caractères pour le store et la plateforme sont Android strings.xml et iOS .strings, et les deux disposent de leur propre outil gratuit: Android XML et iOS .strings. Les sous-titres de cinématiques et de trailers sont au format SRT, ce qui suit le même flux que pour la traduction de sous-titres YouTube.

Nous ne prétendons pas remplacer Unity, Unreal, Godot ou une plateforme de localisation. Nous traitons ce qu’ils exportent.

Une colonne par langue ou un fichier par langue

C’est l’élément le plus important à comprendre avant d’écrire une instruction, car cela détermine ce que vous pouvez demander.

Ainsi, “traduisez mon jeu en français, allemand, espagnol et japonais” représente une seule tâche si vous avez un CSV Unity avec quatre colonnes de locales, et quatre tâches si vous avez quatre fichiers PO Unreal. Demander à un format mono-langue de contenir deux langues échouera, et cela se produira lors de l’étape de planification plutôt que silencieusement, ce qui est le moment idéal pour détecter l’erreur.

Envoyer un dossier de fichiers de locales sous forme d’archive

Le dépôt d’un jeu ne contient pas un seul fichier de localisation. Il contient un répertoire par culture, chacun contenant le même nom de fichier. Toute l’arborescence est envoyée dans un seul fichier ZIP, et c’est là qu’intervient le traducteur ZIP.

Il est utile de connaître les limites avant de créer l’archive: jusqu’à 200 fichiers, 20 MB pour l’archive et 4 MB par fichier à l’intérieur. Les fichiers volumiques sont acceptés s’ils sont envoyés seuls, car les plafonds sont bien plus élevés: 60 MB pour un CSV, 50 MB pour un XLSX, 12 MB pour XLIFF, Android XML et RESX, 8 MB pour JSON, et 4 MB pour PO, YAML, .properties, .strings et SRT.

Chaque fichier de l’archive doit avoir le même format et la même structure. Le terme “même structure” a une signification spécifique selon le format:

• CSV: colonnes identiques, dans le même ordre.
• Android XML, iOS .strings, Java .properties, RESX: un ensemble de clés identique. Un ensemble de dossiers par culture passe naturellement ce test, car il est généré à partir d’une seule source.
• XLIFF: même version et même structure d’unités. Chaque fichier peut déclarer une paire de langues différente, c’est pourquoi l’exportation mixte de plusieurs cibles constitue toujours une seule archive.
• PO: n’importe quel fichier PO, puisque la structure d’un catalogue est son format.

Une archive qui échoue à la vérification de structure est refusée avec l’indication de l’incohérence, plutôt que d’être traitée partiellement.

Comment se déroule réellement une traduction désormais

Il n’y a plus d’écran de mappage de colonnes ni d’étape de configuration. Les modes fixes à choisir n’existent plus depuis août 2026.

1. Téléchargez le fichier exporté par votre outil.
2. Expliquez vos besoins en anglais simple. Une phrase, ou cinq.
3. Lisez le plan. Il affiche les langues, le périmètre compris, le nombre de mots et le coût.
4. Corrigez-le s’il est erroné. C’est gratuit et répétable.
5. Approuvez. C’est l’étape qui consomme des crédits.
6. Téléchargez un fichier, dans le format d’origine.

L’instruction est un texte libre que le moteur compile en code vérifié. C’est pourquoi des instructions de périmètre impossibles à exprimer pour un traducteur automatique fonctionnent ici: “only the entries whose translation is still empty”, “only the rows where the German column still holds the English text”, “translate the dialogue and the item names, leave the developer comments alone”.

Tout est gratuit jusqu’à l’étape cinq. Un plan qui aurait mal interprété votre fichier peut être corrigé gratuitement, il n’y a donc jamais lieu de deviner.

Texte devant respecter un espace limité

Un bouton qui tient en anglais peut déborder en allemand. Le texte traduit est généralement 15 à 30% plus long, et une interface conçue sur la largeur de l’anglais est une interface conçue pour le cas le plus court.

La mauvaise solution consiste à traduire d’abord et à couper ensuite, ce qui produit des abréviations que personne n’utiliserait. La bonne solution est d’énoncer la contrainte dès le départ, pour que la ligne soit rédigée pour s’adapter:

Keep every UI label under 28 characters, including spaces. If the natural
translation is longer, choose a shorter phrasing rather than abbreviating.

Cela doit figurer dans les instructions au niveau de la chaîne, transmises lors de l’approbation, car un plafond de caractères décrit un élément visible à l’intérieur d’une seule chaîne. Demandez-le une fois par fichier et il sera appliqué lors de la rédaction de chaque étiquette.

Deux choses ne sont pas remplacées. Testez les chaînes les plus longues dans votre build, car un plafond de caractères n’est pas une mesure de pixels pour votre police. Et restez réaliste sur le plafond: 28 caractères pour un bouton, pas 28 caractères pour une description de quête, sinon vous obtiendrez des descriptions de quêtes qui ressemblent à des télégrammes.

Les deux instructions que l’on confond

C’est la seule étape de tout le flux de travail qui peut échouer silencieusement, elle mérite donc trente secondes d’attention.

L’instruction du plan détermine ce qui est traduit. Elle est lue une seule fois, par rapport à la structure de l’ensemble du fichier, et c’est là que figurent la langue cible et le périmètre. “Translate every entry whose translation slot is still empty into German.”

Les instructions au niveau de la chaîne sont appliquées pendant la rédaction de chaque chaîne. À ce stade, le moteur analyse une seule chaîne, ces instructions ne peuvent donc décrire que ce qui est visible à l’intérieur: un plafond de caractères, un registre, un placeholder tel que {count} à conserver tel quel, ou un nom à ne pas traduire.

Si vous placez un plafond de caractères dans le plan, cela ne servira à rien. Si vous écrivez “skip the first column” ou “only translate the second half of the file” dans le champ des instructions de chaîne, cela ne fera rien non plus, car aucun fichier n’est visible à ce stade. Aucune erreur ne s’affiche. Vous obtenez simplement un résultat qui a ignoré vos consignes.

Noms, objets et sorts qui ne doivent pas diverger

Le “lore” est ce qui différencie la traduction de jeux de tout le reste. Un catalogue produit possède une centaine de termes qui doivent rester fixes. Un jeu en possède des milliers, ils sont inventés et reviennent sur des milliers de lignes et à chaque mise à jour que vous publiez pendant les trois prochaines années.

Intégrez-les une seule fois dans un espace de travail glossaire: noms de personnages, noms de lieux, noms d’objets et de sorts, la traduction officielle d’une phrase récurrente et les noms qui ne doivent absolument pas être traduits. Un glossaire est lié à une seule paire de langues et il est figé lors de la création du plan. Ainsi, un lot en cours d’exécution n’est jamais modifié et le fichier suivant bénéficie des termes actuels.

Il est utile de vérifier les limites de votre forfait par rapport à votre liste de termes: un glossaire de 50 termes avec le forfait Free, trois de 150 avec Starter, et des glossaires illimités de 500 termes chacun avec Pro.

Et vous n’avez pas à saisir cette liste vous-même. Le glossaire est accessible depuis le serveur MCP, avec des outils pour lister les glossaires, en lire un, et ajouter, modifier ou remplacer des termes. Ainsi, un agent qui a déjà votre projet ouvert peut s’occuper de la partie fastidieuse : lire vos String Tables ou vos fichiers de dialogue, extraire les noms propres et les mots inventés récurrents, vous les proposer sous forme de liste, et inscrire ceux que vous approuvez dans l’espace de travail avant tout lancement de traduction.

C’est plus précieux qu’il n’y paraît. Un glossaire que personne ne remplit ne protège rien, et en remplir un à la main pour un jeu avec un millier de termes inventés est précisément la tâche que l’on repousse indéfiniment. Demandez à votre agent d’en préparer le brouillon, puis modifiez sa liste au lieu d’en écrire une de zéro.

C’est aussi la raison technique pour laquelle un traducteur automatique généraliste peine avec un jeu. Son glossaire remplace un terme dès qu’il correspond, donc la phrase entourant la substitution n’est jamais réévaluée, et un nom inventé avec un genre se retrouve au milieu d’une phrase française sans aucun accord grammatical. Ici, le glossaire est intégré comme une intention sémantique pendant la rédaction, donc le terme s’inflechit naturellement dans la phrase. La même différence s’applique à l’utilisation d’un assistant de chat pour cette tâche: c’est efficace pour dix chaînes, mais il est incapable de respecter une règle unique de manière fiable à la 18 000e chaîne.

Laissez un agent gérer votre boucle de localisation de jeu

C’est l’étape que la plupart des studios n’ont pas encore adoptée. Il existe une API REST, un outil en ligne de commande et un serveur MCP, permettant à un agent de codage d’exécuter l’intégralité de la boucle sans qu’un humain ait besoin d’ouvrir un navigateur.

Installez-le et connectez-vous une seule fois:

npm install --global @ai-glot/cli
aiglot auth login

Cela ouvre un navigateur pour autoriser la machine. Sur un serveur de build sans navigateur, aiglot auth login --device active le flux de code d’appareil, et aiglot auth login --key <key> fonctionne en CI.

Le prompt à donner à votre agent

Copiez-collez ceci, en modifiant les chemins et la liste des langues. Ce texte est conçu pour être donné à un agent, pas pour être exécuté par vous-même.

My Unreal project is at ~/dev/starfall. The Localization Dashboard exported
PO files to Content/Localization/Game/<culture>/Game.po, and their msgstr
lines are still empty.

Translate the French, German, Spanish and Japanese files with the aiglot CLI.
Read `aiglot batches create --help` and `aiglot batches approve --help` first
so you use the real flags, and run `aiglot languages` to confirm each language
tag before you start.

A PO file holds one target language, so create ONE batch per culture, four in
total. The source language is English: say so explicitly in every instruction
rather than letting it be inferred.

The plan instruction should translate only the entries whose msgstr is still
empty, and leave msgctxt, msgid and every placeholder or rich-text tag exactly
as written.

At approval, pass this as the string-level instruction: "Keep UI labels under
28 characters. Keep placeholders exactly as written. Do not translate any name
that appears in the glossary."

Show me all four plans, the total word count and the cost BEFORE you approve
anything, then wait for me to confirm.

After I confirm, approve with the lite quality tier, poll until each batch
reaches a terminal status, and download each result next to the original as
Game.translated.po. Do not overwrite the source files. Tell me if any batch
failed.

Quatre éléments de ce prompt effectuent le travail réel, et ce sont les parties à copier dans le vôtre.

Il demande à l’agent de lire l’aide d’abord. Un agent qui devine les noms des drapeaux échouera dès le premier appel et inventera ensuite une raison plausible. Lire l’aide réelle, ou aiglot help --json pour l’ensemble de l’arborescence des commandes, élimine ce problème.

Il précise explicitement un lot par culture. Un agent qui supposerait qu’un seul travail peut avoir quatre cibles rédigerait une instruction qu’un fichier PO ne peut pas honorer, et vous passeriez un cycle de plan à essayer de comprendre pourquoi.

Il nomme la langue source. Sans cela, la source est déduite du contenu, et cette déduction est la moins fiable précisément là où elle coûte le plus cher: les libellés d’interface courts, les fichiers contenant déjà une ligne traduite isolée, et les textes saturés de noms inventés.

Il impose un arrêt avant la dépense. aiglot batches approve est la seule commande qui consomme des crédits. Tout ce qui précède est gratuit et répétable, donc demander de voir quatre plans d’abord ne coûte rien. C’est cette propriété qui rend une boucle d’agent sans surveillance raisonnable plutôt qu’effrayante: un agent qui vous comprend mal brûle des plans, pas de l’argent.

Ce que l’agent exécute réellement

for pair in fr:French de:German es:Spanish ja:Japanese; do
  code=${pair%%:*}
  lang=${pair#*:}
  po=~/dev/starfall/Content/Localization/Game/${code}/Game.po

  # 1. Create the batch. Free. Returns the file and its plan.
  id=$(aiglot batches create "$po" \
        --instruction "The source language is English. Translate into ${lang} only the entries whose msgstr is still empty. Leave msgctxt and msgid exactly as they are, and keep every placeholder and rich-text tag untouched." \
        --json | jq -r '.data.id')

  # 2. Read the plan, still free.
  aiglot batches get "$id" --json | jq '.data.plan'

  # 3. Approve. The only step that spends credits.
  aiglot batches approve "$id" --quality lite \
    --instructions "Keep UI labels under 28 characters. Keep placeholders exactly as written."

  # 4. Wait for a TERMINAL status, not for a specific one.
  until status=$(aiglot batches get "$id" --json | jq -r '.data.status'); \
    [ "$status" = "completed" ] || [ "$status" = "failed" ] || [ "$status" = "cancelled" ]; do
    sleep 5
  done

  [ "$status" = "completed" ] && \
    aiglot batches download "$id" --output "${po%.po}.translated.po"
done

Un détail ici vaut la peine d’être retenu, même si vous ne traduisez jamais de jeu. La boucle attend n’importe quel statut terminal plutôt que de surveiller uniquement completed. Un script qui attend seulement le statut espéré attendra indéfiniment en cas d’échec, car une comparaison avec une valeur qui n’arrive jamais n’est pas une erreur. C’est simplement toujours faux.

Si votre agent préfère les outils au shell, aiglot mcp fait le pont avec le serveur MCP. Le CLI est le meilleur point de départ: il fonctionne dans un script, en CI, et vous permet de lire exactement ce qui a été exécuté.

L’autre option: un agent qui prépare uniquement les fichiers

L’automatisation complète n’est pas la seule configuration utile, et pour un premier passage, ce n’est souvent pas la bonne.

Un agent est tout aussi précieux s’il s’occupe de la partie ennuyeuse avant de s’arrêter. Demandez-lui de parcourir le dépôt, de trouver chaque fichier de localisation, de signaler quelles cultures existent et quelles entrées ne sont pas encore traduites, puis d’assembler un seul fichier ZIP avec un fichier par culture. Vous téléchargez ensuite cette archive vous-même, lisez le plan, approuvez, et laissez l’agent replacer les résultats dans les bons chemins par la suite. Ce découpage laisse les deux décisions cruciales à l’humain, qui doit les prendre: pour quel ensemble de langues vous payez et si le plan est correct, tout en confiant à la machine la gestion des fichiers, qui est la partie véritablement fastidieuse et sujette aux erreurs. La page de solution de localisation de jeux détaille ce même processus via le navigateur si vous préférez le voir avant de le scripter.

La place restante de l’humain

Nous ne allons pas vous dire que la traduction par IA remplace un traducteur de jeux, car pour un jeu en particulier, ce n’est pas le cas.

Utilisez-le pour le gros du travail. Chaînes d’interface utilisateur, descriptions d’objets et d’équipements, info-bulles, noms de succès, notes de mise à jour, et tout le contenu secondaire comme les dialogues d’ambiance et les textes de saveur. C’est ce volume qui pousse les studios à repousser la localisation d’un an, et c’est tout à fait gérable en une seule passe.

Réservez la relecture humaine là où elle apporte une vraie valeur. Votre première heure de jeu, la personnalité de vos personnages principaux, tout ce qui est comique ou qui rime. Une première passe suivie d’un réviseur est une excellente façon d’exploiter un expert, plutôt que de lui faire perdre une semaine à fouiller dans des fichiers.

Engagez directement un spécialiste pour votre page de boutique et votre trailer, car ce sont les deux textes qui déterminent si quelqu’un verra le reste.

Si cette séparation fonctionne, c’est parce que le volume et l’importance ne sont pas corrélés, et une fois qu’on le comprend, la décision budgétaire devient évidente. Votre page de boutique représente quelques centaines de mots qui portent la majeure partie de votre risque réputationnel : payer un expert natif pour celle-ci coûte peu en termes absolus et en vaut manifestement la peine. Vos neuf mille chaînes d’UI et d’objets réparties sur huit langues représentent presque tout le volume de mots, mais aucun risque comparable, et aucun budget ne survit à un tarif au mot sur ce volume.

Traitez donc le gros du volume ici, puis fixez votre propre limite. Certains studios intègrent le résultat directement dans le build. D’autres ajoutent une révision professionnelle sur leurs deux plus gros marchés, ou uniquement sur les textes de quêtes, et laissent le reste tel quel. Les deux approches sont raisonnables, et aucune n’est une tentative de corriger un premier passage raté.

L’automatisation est là pour que le temps des experts soit consacré à la langue et non à la gestion des fichiers. C’est tout l’intérêt de la solution, et c’est un argument honnête.

Commencez avec le fichier que vous avez déjà

Exportez depuis votre moteur. Envoyez ce fichier. Lisez le plan. Rien n’est facturé tant que vous n’avez pas approuvé, donc le coût pour savoir si cela convient à votre projet se résume à un téléchargement et deux minutes de votre temps.

Si vous avez une String Table Unity, un dossier de fichiers PO Unreal, ou un tableur de dialogues qui attend depuis votre dernier jalon, c’est exactement ce qu’il nous faut. Inscrivez-vous à AI Glot et traduisez un premier fichier, puis confiez le reste à un agent.