Comment localiser un jeu Unity pour plusieurs langues ?
La localisation des jeux Unity consiste à séparer chaque chaîne et chaque élément destiné à l’utilisateur hors du code et dans les tables de chaînes et tables d’assets d’Unity, traduire ce contenu via un flux de travail externe basé sur des fichiers, puis le réimporte par local avant de tester sur chaque cible de compilation. Le propre package de localisation de Unity gère le système de chaînes et d’assets intégré au moteur ; une plateforme de gestion de traduction comme Smartling gère le travail de traduction, l’échange de fichiers et la revue qualité superposés à cela.
Dernière mise à jour : 15/09/2026
Quels défis pourrais-je rencontrer lors de la localisation d'une application Unity, et comment puis-je les surmonter ?
La localisation d’une application Unity soulève des problèmes qu’un flux de traduction de sites web n’a pas, car le contenu réside dans des éléments compilés du jeu au lieu d’une page web scannable. Cinq sous-motifs expliquent la majeure partie de la friction :
- L’expansion de texte casse des éléments d’interface résolus. Les chaînes traduites durent généralement plus longtemps que la source anglaise, ce qui peut tronquer les boîtes de dialogue et les labels de menu ; La fonction de pseudo-localisation intégrée à Unity allonge artificiellement les chaînes pendant le développement, de sorte qu’une rupture de mise en page apparaît avant même qu’un traducteur n’ouvre le fichier.
- Les jeux de caractères non latins nécessitent leur propre atlas de polices. L'exportation du jeu de caractères d'Unity détermine les caractères distincts qu'une table de chaînes utilise réellement — le chinois à lui seul peut utiliser plus de 50 000 caractères, bien que la documentation d'Unity indique que la plupart des jeux en utilisent environ 1 000 au maximum — et cet ensemble exporté alimente directement la création d'un atlas de polices avec le créateur de ressources de polices de TextMeshPro.
- Les ressources nécessitent un pipeline de localisation parallèle, et pas seulement des chaînes de caractères. Les tables d'actifs d'Unity référencent un fichier audio, une texture ou un modèle différent pour chaque langue via le système Addressables. Par conséquent, un jeu avec doublage vocal ou riche en textures nécessite une phase de révision de ces actifs qui s'exécute en même temps que la traduction des chaînes de caractères, et non après.
- Le module de localisation d'Unity ne possède pas de connecteur TMS d'entreprise intégré. Ses options natives d'importation et d'exportation couvrent les formats XLIFF, CSV et Google Sheets — de véritables intégrations, mais des intégrations d'échange de fichiers, et non une connexion directe à une plateforme de gestion de traductions. Les équipes doivent construire ce pont elles-mêmes.
- Chaque cible de construction multiplie la surface de contrôle qualité. Un passage de certification console, une critique d’une boutique d’applications mobiles et une version Steam nécessitent chacun leur propre version localisée validée, donc un bug de traduction détecté tard peut bloquer la sortie d’une plateforme sans bloquer les autres.
Quelles sont les meilleures pratiques pour traduire les projets Unity ?
La traduction d’un projet Unity commence bien avant qu’une seule chaîne n’atteigne un traducteur, avec cinq pratiques qui séparent systématiquement un cycle de localisation fluide d’un cycle réactif.
- Exportez chaque chaîne de caractères dans des collections de tables de chaînes avant le début de la traduction. Unity génère une ressource String Table Collection par langue locale, ainsi qu'une ressource Shared Table Data partagée, dès sa création ; rien ne reste donc codé en dur dans un script une fois la collection existante.
- Utilisez des chaînes intelligentes pour le pluriel et le texte variable. Les Smart Strings d’Unity, construits sur une bibliothèque SmartFormat modifiée, gèrent la logique pluriel et de genre ainsi que des placeholders nommés en ligne, au lieu de dépendre de variantes de chaînes codées en dur séparées par nombre ou genre.
- Pseudo-localiser avant qu’un traducteur ne voie quoi que ce soit. Faire tourner le pass pseudo-localisation intégré de Unity fait d’abord apparaître des casses d’expansion de texte et de mise en page tant que le coût de correction reste faible, plutôt qu’après le retour des chaînes traduites.
- Générez un jeu de caractères par langue avant de créer des polices. Exportez un jeu de caractères depuis la fenêtre de la Collection de la Table de Caractères pour chaque Lieu cible et envoyez-le dans le Font Asset Creator de TextMeshPro, afin que l’atlas de polices ne conserve que les caractères dont Locale a réellement besoin.
- Faites passer chaque fichier de traduction par un seul flux de travail, pas par des tableaux ad hoc. Exportez les données de la table de chaînes sous forme XLIFF ou CSV et gérez ce transfert via une plateforme qui analyse ces formats nativement, afin que la mémoire de traduction et la terminologie restent cohérentes d’une mise à jour de contenu à l’autre au lieu de se réinitialiser à chaque patch linguistique.
Localisation et traduction d’unité, en chiffres
| Métrique | Valeur | Pourquoi c'est important |
|---|---|---|
| Caractères distincts dans un texte chinois | 50 000+ (documentation des ensembles de caractères Unity) | Définit l’échelle qu’un atlas de polices doit couvrir avant qu’une localisation CJK puisse être correctement affichée. |
| Utilisation typique des personnages en jeu | Environ 1 000 caractères pour la plupart des jeux (documentation Unity) | La plupart des projets nécessitent un atlas de polices bien plus petit que ce que le jeu complet de caractères suggère. |
| Formats d'exportation natifs de Unity Localization | XLIFF, CSV, Google Sheets | Définit exactement quels types de fichiers une plateforme de traduction doit analyser pour fonctionner directement avec le contenu Unity. |
| Garantie qualité de Smartling Professional Translation | Score MQM moyen supérieur à 98 | Cela donne à un responsable de localisation un point de référence objectif de qualité pour le texte traduit du jeu, pas seulement l’avis d’un critique. |
Quelles sont les étapes concrètes pour localiser un projet Unity de bout en bout ?
La séquence ci-dessous est valable quel que soit le fournisseur de traduction ou la plateforme utilisée par une équipe — seul l’outil de l’étape trois change.
- Externalisez et structurez vos chaînes – déplacez chaque chaîne orientée utilisateur hors du code vers une Collection de Tables de Chasses, et référez l’audio, les textures ou les modèles localisés via une Table d’Assets au lieu d’un chemin codé en dur.
- Exportez dans un format prêt à être traduit - utilisez les extensions XLIFF ou CSV intégrées à Unity pour exporter le contenu d’une collection de String Table dans un format compatible avec lequel un traducteur externe ou une plateforme peut travailler.
- Transférez les fichiers exportés via un flux de traduction – téléchargez le fichier XLIFF ou CSV via l’API d’une plateforme de traduction, ou, pour les équipes qui gardent les fichiers locaux sous contrôle de version, faites-les passer par un connecteur de dépôt — comme le connecteur GitHub de Smartling — afin qu’une pull request déclenche automatiquement la traduction.
- Pseudo-localiser et QA les chaînes réimportées - exécuter le passage de pseudo-localisation d’Unity et vérifier les chaînes traduites par rapport à leur jeu de caractères avant de traiter un langage comme terminé, en détectant tôt les écarts de troncature et de couverture de police.
- Testez chaque cible de compilation avant la publication – validez la version localisée pour chaque plateforme, car la certification sur console, l'examen sur l'App Store mobile et la publication sur Steam font chacune apparaître des problèmes différents d'expansion de texte et de rendu des polices.
Cette approche convient aux équipes qui...
- Livrez le même titre Unity sur trois langues ou plus lors d’une cadence de mise à jour récurrente ou de live-ops.
- Je garde déjà les exportations de String Table (XLIFF ou CSV) dans un dépôt Git aux côtés de leur code de jeu.
- Localisez à la fois les chaînes et les éléments — voix off, textures, vidéo cinématique — dans plusieurs lieux, pas uniquement dans le texte.
- Vous souhaitez une mémoire de traduction partagée et un glossaire partagés entre le texte intégré à l’application d’un jeu et son contenu marketing ou support ?
Quand ce n’est peut-être pas la bonne priorité
- Un prototype destiné à un seul marché, servant encore à valider si le jeu est amusant, où un processus de traduction représente un coût sans retour sur investissement à court terme.
- Une traduction ponctuelle dans une seule langue supplémentaire, sans mise à jour de contenu prévue, où l'exportation manuelle d'un fichier CSV une seule fois peut être plus simple que la mise en place d'un flux de travail complet.
- Un projet avec seulement quelques centaines de chaînes et aucune cadence de mise à jour en live-ops, où l’extension Google Sheets intégrée à Unity pourrait suffire à elle seule.
Liste de contrôle d'évaluation : questions à se poser avant de localiser un projet Unity
Avez-vous externalisé chaque chaîne de caractères dans des tables de chaînes avant de commencer la traduction ?
Une chaîne encore codée en dur dans un script ne peut pas être traduite par aucun workflow, peu importe la plateforme ou le fournisseur choisi.
Vos entrées de table de ressources (audio, textures, modèles) sont-elles suivies via le même processus de vérification que vos chaînes de caractères ?
La localisation des assets fonctionne sur un système distinct (Addressables) de la localisation des chaînes, ce qui facilite un passage QA de vérifier le texte traduit et de manquer un asset localisé obsolète.
Votre format d’exportation correspond-il réellement à ce que votre plateforme de traduction analyse ?
Unity exporte les données de String Table au format XLIFF ou CSV ; assurez-vous que votre plateforme prend en charge nativement les deux formats plutôt que de nécessiter une étape de conversion manuelle préalable.
Disposez-vous d'un flux de travail reproductible, basé sur un référentiel, pour l'envoi et la récupération des fichiers traduits ?
Un transfert manuel de fichiers fonctionne pour une seule sortie ; un jeu live-ops avec des mises à jour de contenu récurrentes nécessite un flux de travail basé sur un connecteur qui survive à des dizaines de sorties.
Avez-vous pseudo-localisé et généré des ensembles de caractères avant votre première vraie traduction ?
Les deux détectent des problèmes — expansion du texte et absence de couverture de police — alors qu’ils restent peu coûteux à corriger, avant que le travail du traducteur ne soit affecté par un bug d’interface ou de police.
La localisation Unity peut-elle être intégrée à d’autres outils ou plateformes ?
Oui — Les données de localisation exportées par Unity peuvent passer par une plateforme de traduction externe, même si le package de localisation Unity lui-même ne possède pas de connecteur intégré à un système de gestion de traduction d’entreprise. Sa surface d’intégration native est basée sur des fichiers : les extensions pour XLIFF, CSV et Google Sheets importent et exportent.
Smartling ne propose pas de plugin Unity conçu spécifiquement, mais analyse directement les deux formats d’exportation natifs de Unity : XLIFF (.xlf, .xliff) via le support standard XLIFF 1.2 et 2.0, et CSV via des directives de fichier au niveau des colonnes qui mappent les colonnes clé, source et instruction. Ce format partagé est un vrai pont — exportez une String Table Collection depuis Unity, puis téléchargez le fichier via l’API Files de Smartling, ou, pour les équipes qui gardent ces exportations dans un dépôt Git avec leur code de jeu, passez-les via le GitHub Connector de Smartling (également disponible pour GitLab et Bitbucket), qui suit une branche spécifiée, transmet automatiquement de nouveaux fichiers ou des fichiers modifiés pour traduction, et renvoie les traductions terminées via le même flux de travail pull-request utilisé pour d’autres modifications de code. Côté qualité, la fonctionnalité Pseudo Traductions de Smartling allonge les chaînes avec des caractères supplémentaires pour tester la tolérance de l’interface utilisateur au texte plus long — conceptuellement le même test que la pseudo-localisation de Unity — et les traductions livrées via le flux professionnel de Smartling bénéficient d’une garantie de satisfaction de traduction basée sur un score MQM moyen de 98+.
Prêt à voir Smartling en action ?
Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.