XUnity.AutoTranslator ne traduit pas

XUnity.AutoTranslator est gratuit, sous licence MIT, activement maintenu, et c'est le meilleur outil de traduction à l'exécution qu'Unity possède. Il fonctionne en accrochant le moment où un jeu remet une chaîne à un composant de texte, et en y glissant une traduction avant qu'elle ne soit dessinée. C'est cette conception qui lui permet de n'avoir besoin d'aucune connaissance des formats de fichiers du jeu — et c'est aussi pour cela que, lorsqu'il échoue, il échoue silencieusement. Rien ne plante. Le jeu tourne simplement en japonais.

Les cinq points ci-dessous expliquent la quasi-totalité des signalements du type "ça ne traduit pas". Parcourez-les dans l'ordre ; chacun a un correctif différent, et deviner entre eux coûte beaucoup de soirées.

D'abord : lisez le journal, pas l'écran

Le plugin est bavard sur ce qu'il fait, et le journal est le seul endroit où il le dit. Avec une installation BepInEx, regardez BepInEx/LogOutput.log. Le journal d'Unity lui-même se trouve à côté, dans <Game>_Data/output_log.txt sur les anciens builds, ou %APPDATA%/../LocalLow/<Company>/<Game>/Player.log sur les plus récents.

• Le journal mentionne-t-il seulement le chargement de XUnity.AutoTranslator ? Sinon, le problème vient du chargeur, pas du traducteur — vous êtes au cas d'échec numéro un.
• Liste-t-il un endpoint en cours d'initialisation, puis en nomme-t-il un qui est arrêté après des erreurs répétées ? C'est le cas d'échec numéro cinq.
• Des traductions sont-elles écrites dans BepInEx/Translation/<lang>/Text/_AutoGeneratedTranslations.txt ? Si ce fichier se remplit de traductions correctes qui n'apparaissent jamais à l'écran, le côté réseau va bien et le côté affichage non.
• Appuyez sur ALT+1 en jeu pour ouvrir la fenêtre d'agrégation des traductions. Si elle montre les lignes que vous regardez, le hook les voit. Si elle reste vide, le hook ne les voit jamais.

Cette dernière séparation — "traduit mais pas affiché" contre "jamais vu" — est le point de bifurcation. Tout ce qui suit en dépend.

1. Le jeu est un build IL2CPP

Unity livre les jeux avec deux runtimes très différents. Mono garde le C# du jeu sous forme d'assemblys .NET ordinaires dans <Game>_Data/Managed/, dont Assembly-CSharp.dll, avec les noms de types et de méthodes intacts. IL2CPP convertit ce C# en C++ à l'avance et le compile dans un GameAssembly.dll natif ; ce qui survit du système de types est empaqueté dans <Game>_Data/il2cpp_data/Metadata/global-metadata.dat.

Un hook à l'exécution doit trouver une méthode et la remplacer. Sur Mono, c'est un problème de réflexion classique. Sur IL2CPP, il n'y a aucune méthode managée sur laquelle réfléchir — le code est natif, et le seul chemin de retour vers les noms, les champs et les adresses de méthodes consiste à analyser global-metadata.dat et à reconstruire la disposition. C'est un chargeur complètement différent, pas un réglage.

• Comment le savoir en cinq secondes : un GameAssembly.dll à côté de l'exécutable du jeu, plus un dossier il2cpp_data, signifient IL2CPP. Un dossier Managed/ rempli de DLL signifie Mono.
• IL2CPP demande la variante IL2CPP de BepInEx, et la version de XUnity.AutoTranslator compilée pour elle. Le build Mono ne se chargera pas — il n'apparaîtra tout simplement pas dans le journal, ce qui ressemble exactement à "le plugin est cassé".
• L'architecture compte aussi. Un jeu 64 bits demande le chargeur 64 bits. Une paire mal assortie échoue de la même façon silencieuse.
• Certains jeux livrent un fichier de métadonnées illisible. Les packers et les couches anti-altération chiffrent ou restructurent global-metadata.dat, et tout outil qui dépend de sa lecture — le hook compris — s'arrête là.

2. Le plugin se charge, et le texte n'apparaît jamais

Le plugin est dans le journal, l'endpoint s'est initialisé, _AutoGeneratedTranslations.txt grossit — et l'écran ne change pas. Le hook traduit une chaîne que le jeu jette ensuite, ou le jeu définit son texte par un chemin que le hook n'intercepte pas.

TextGetterCompatibilityMode

Beaucoup de jeux relisent le texte qu'ils viennent de définir — pour le mesurer, pour y ajouter quelque chose, pour le comparer. Dès que le composant contient une chaîne traduite, cette relecture renvoie la traduction, la logique du jeu opère sur un texte qu'il n'a pas écrit, et le résultat va de la ligne qui revient à l'original à la mise en page qui s'effondre. TextGetterCompatibilityMode, dans AutoTranslatorConfig.ini, fait renvoyer au jeu sa chaîne d'origine pendant que le joueur voit toujours la version traduite. Il est désactivé par défaut parce qu'il coûte du travail à chaque lecture, et c'est le premier interrupteur à essayer quand le texte clignote, revient en arrière ou refuse de tenir.

L'autre moitié de cette catégorie, c'est le texte qui n'est jamais défini par une API accrochée : un jeu qui rend son texte avec son propre moteur, qui envoie les caractères directement dans un maillage, ou qui incruste les dialogues dans une image. Il n'y a aucun réglage pour cela — le point d'interception n'existe pas. Le texte incrusté dans l'illustration est un problème à part entière, qui demande la traduction d'images plutôt qu'un hook.

3. Une partie du texte seulement est traduite

Les menus sont traduits, pas les dialogues. Ou les dialogues sont traduits et chaque bouton reste en japonais. C'est presque toujours un framework d'interface non activé, parce que le plugin les accroche séparément et qu'ils ne sont pas tous actifs par défaut.

• Actifs par défaut : UGUI (l'interface intégrée d'Unity), NGUI, TextMeshPro et UIElements (EnableUGUI, EnableNGUI, EnableTextMeshPro, EnableUIElements). À eux tous, ils couvrent la plupart des jeux modernes, y compris les frameworks de romans visuels comme Utage, qui dessinent à travers eux plutôt que de disposer de leur propre interrupteur.
• Inactifs par défaut : IMGUI et le composant TextMesh historique. IMGUI est l'interface en mode immédiat d'Unity — elle se redessine à chaque image, donc l'accrocher revient à traduire à chaque image, et elle est désactivée pour des raisons de performance, pas parce qu'elle ne fonctionne pas.
• Les indicateurs se trouvent dans `AutoTranslatorConfig.ini` sous les noms EnableIMGUI, EnableTextMesh et consorts. Mettez à True celui qu'utilise votre jeu, puis relancez.
• Les jeux Unity anciens et les doujin japonais sont les cas IMGUI habituels. Un jeu dont les menus ressemblent à de simples boîtes grises au style par défaut est un indice fort.

Si tout activer ne change rien, le texte ne passe pas du tout par un composant de texte Unity — retour au cas d'échec numéro deux.

4. Les longues lignes sont ignorées, pas traduites

MaxCharactersPerTranslation vaut 200 par défaut. Tout ce qui est plus long est ignoré. Pas tronqué, pas retenté, pas journalisé d'une façon que vous remarqueriez en jouant — ignoré, donc la ligne s'affiche dans la langue d'origine et rien n'a l'air cassé.

C'est le cas d'échec que l'on cherche le plus longtemps, parce que l'indice est très faible : la majeure partie du jeu est traduite, puis un paragraphe ne l'est pas. Les romans visuels sont les victimes habituelles — un long bloc de narration ou un monologue sans retour à la ligne dépasse facilement 200 caractères, et c'est précisément le texte que vous vouliez le plus voir traduit.

Augmentez la valeur dans AutoTranslatorConfig.ini, puis relancez. Gardez en tête que vous augmentez aussi le coût de chaque requête : les endpoints gratuits ont leurs propres plafonds de longueur par requête et commenceront à rejeter celles qui les dépassent, si bien qu'une valeur très élevée échange un saut silencieux contre une erreur d'endpoint visible. Une valeur entre 500 et 1000 couvre la prose ordinaire d'un roman visuel.

5. L'endpoint a échoué ou vous a limité

Les endpoints par défaut de XUnity sont des services de traduction publics et gratuits, sollicités comme le ferait un navigateur. Ils ne sont pas contractuels, et ils changent. Quand une série de requêtes échoue d'affilée, le plugin coupe l'endpoint pour le reste de la session plutôt que de le marteler — une décision délibérée et saine, qui signifie aussi que tout ce qui suit reste silencieusement non traduit jusqu'au redémarrage du jeu.

• Cherchez la ligne de coupure dans le journal. Si elle y est, le correctif est un redémarrage plus un changement — pas davantage d'attente.
• Ralentissez la file. MaxTranslationsQueuedPerSecond et les réglages de délai existent parce que ce sont les rafales qui déclenchent les limitations. Avancer vite dans un roman visuel envoie des centaines de requêtes en quelques secondes.
• Changez d'endpoint. Si un service gratuit a un mauvais jour, un autre n'en a généralement pas.
• Utilisez un endpoint avec clé. Une vraie clé DeepL ou une clé d'API payante supprime toute cette catégorie de problème, au prix d'une clé d'API payante.
• Mettez le plugin à jour. Quand le protocole d'un endpoint gratuit change, le correctif arrive sous forme de version. Faire tourner un build vieux de deux ans contre un service qui a évolué est une cause fréquente de "ça marchait avant".

Bonus : le texte est traduit et s'affiche en carrés

Ce n'est pas du tout un échec de traduction. Le jeu a été livré avec un atlas de police contenant exactement les glyphes dont sa langue d'origine avait besoin, et votre langue cible en demande d'autres, donc chaque caractère manquant se dessine en carré ou en blanc. XUnity a OverrideFont et OverrideFontTextMeshPro exactement pour cela. Notez la signature : des carrés signifient un glyphe manquant ; de vrais caractères `?` signifient un problème d'encodage plus tôt dans la chaîne. Ce sont deux bugs différents et le réglage de police ne corrige que le premier.

L'ordre dans lequel dérouler

1. Confirmez Mono ou IL2CPP en cherchant GameAssembly.dll, et vérifiez que vous avez installé le chargeur correspondant.
2. Ouvrez BepInEx/LogOutput.log et vérifiez que le plugin s'est chargé et qu'un endpoint s'est initialisé.
3. Appuyez sur ALT+0 en jeu pour ouvrir la fenêtre du plugin lui-même — si rien n'apparaît, le plugin n'est pas chargé. ALT+1 ouvre le Translation Aggregator : vide signifie que le hook ne voit jamais le texte ; rempli, qu'il le voit.
4. Si le hook le voit mais que l'écran ne change pas, activez TextGetterCompatibilityMode.
5. Si une partie seulement du jeu est traduite, activez IMGUI et le TextMesh historique.
6. Si certaines longues lignes restent non traduites, augmentez MaxCharactersPerTranslation au-delà de sa valeur par défaut de 200.
7. Si tout s'est arrêté en cours de session, cherchez la ligne de coupure de l'endpoint, puis relancez avec une file plus lente ou un autre endpoint.

Quand un hook n'est pas le bon outil pour la tâche

Chacun des échecs ci-dessus remonte à la même racine : un hook à l'exécution ne peut traduire que le texte qu'il est présent pour intercepter. Si le jeu ne définit pas la chaîne par une API que le plugin connaît, si le texte a été dessiné avant le chargement du plugin, ou si le runtime n'expose pas la méthode à accrocher, il n'y a rien à configurer. L'outil fait correctement son travail et le texte est simplement hors de portée.

L'alternative structurelle est de travailler sur les fichiers plutôt que sur l'image affichée. Un outil au niveau des fichiers ouvre les propres ressources du jeu, en extrait les chaînes, les traduit et écrit une copie traduite du jeu — le texte est donc déjà dans la langue cible avant même que le moteur ne le charge. Pas de hook, pas de point d'interception, pas d'indicateur par framework, et la limite de caractères est celle que le format accepte. C'est ce que fait RuneTranslate, sur Unity et 16 autres moteurs et formats.

Les compromis sont réels et vont dans l'autre sens. Un outil au niveau des fichiers n'atteint que le texte qui est dans les fichiers — pour Unity, cela signifie les TextAssets, les champs de chaîne MonoBehaviour, les scripts StreamingAssets, les tables de localisation et les AssetBundles, y compris les bundles Addressable chiffrés en AES. Il demande une étape d'export avant de jouer, au lieu de traduire au fil de l'eau. Et il ne peut rien faire pour le texte que votre jeu compose à l'exécution à partir de fragments. Unity est un moteur au mieux exactement pour cette raison : ce qu'un jeu donné externalise varie énormément, et ouvrir le projet est ce qui vous dit sur quoi vous êtes tombé.

• Le texte compilé dans le code C# est la frontière dure. Sur les builds Mono, RuneTranslate lit les littéraux de chaînes dans l'assembly du jeu avec un sidecar embarqué, en s'appuyant sur ce que fait le site d'appel pour ne jamais traduire un nom de scène ou un paramètre d'animateur. Sur les builds IL2CPP, le code compilé reste hors périmètre.
• Le texte des ressources IL2CPP passe bien, en revanche. Les champs de chaîne des composants sont lus sur IL2CPP en reconstruisant les informations de types à partir des métadonnées du jeu — le même global-metadata.dat dont le hook a besoin, utilisé à une autre fin.
• Il lit la propre sortie de XUnity. Si vous avez déjà un _AutoGeneratedTranslations.txt rempli, RuneTranslate analyse ce fichier et peut en traduire les valeurs, clés intactes. Le travail déjà fait n'est pas jeté.
• Les polices sont gérées à l'export, en injectant dans le jeu un asset de police de repli pour qu'une langue cible que la police d'origine ne couvrait pas s'affiche quand même.

Neuf fournisseurs, dont trois ne demandent aucune clé API — Google, DeepL gratuit et les modèles Classic / nouvelle génération de DeepL — plus l'API DeepL, OpenAI, Anthropic, DeepSeek, toute API compatible OpenAI, et un modèle local via Ollama ou LM Studio. Le palier gratuit débloque tous les moteurs et tous les fournisseurs ; il bride le débit et ne garde qu'un projet à la fois. Windows 10/11, ou Linux et le Steam Deck sous Wine ou Proton. Une connexion Patreon gratuite est demandée au premier lancement. Le résultat est un build traduit jouable qui vous reste.

Aucune des deux approches n'a raison partout. Un jeu dont tout le script tient dans une table JSON embarquée relève du niveau des fichiers, et l'a toujours fait. Un jeu qui compose ses dialogues dans le code à l'exécution relève du hook, et le fera toujours. Savoir lequel vous tenez, c'est l'essentiel du travail.

Où aller ensuite

• Comment traduire un jeu Unity — la marche à suivre complète, y compris ce qu'Unity externalise et ce qu'il n'externalise pas.
• La page du moteur Unity — les formats pris en charge et les limites actuelles au même endroit.
• RuneTranslate vs XUnity.AutoTranslator — les deux approches côte à côte, avec les cas que chacune gagne.
• Choisir un fournisseur de traduction — quels moteurs gèrent bien la prose japonaise, et lesquels ne coûtent rien.
• Les bases du glossaire — garder les noms de personnages et la terminologie cohérents sur tout un script.
• Tous les moteurs pris en charge — si le jeu n'est finalement pas un jeu Unity.