Les défis techniques de la localisation et comment les résoudre
📱
Stranger of Sword City Revisited (SoSCR) et Saviors of Sapphire Wings (SoSW) sont deux JRPG d’exploration de donjons qui ont eu des versions antérieures pour la PlayStation Vita, en 2016 et 2019 respectivement.
Fin 2019, NIS America nous a contactés pour discuter du portage de ces deux jeux sur Nintendo Switch et PC. Cet article décrit les défis techniques de localisation rencontrés dans les deux jeux et la manière dont nous avons abordé leur résolution. Il ne couvre pas la traduction réelle du texte trouvé dans les deux jeux, qui a été gérée par NIS America.
La situation d’origine
La version Vita originale de SoSCR était déjà une version localisée en anglais, alors vous vous demandez peut-être quelle était la difficulté avec la création des versions localisées en anglais pour les nouvelles plateformes ?
Eh bien, la version japonaise et la version anglaise de ce jeu étaient deux références entièrement distinctes, ne contenant que le texte japonais ou anglais et aucune option dans le jeu pour basculer entre les deux langues. C’était quelque chose qui devait être mis en œuvre pour une version mondiale.
Quant à SoSW, le jeu original n’avait vu qu’une version japonaise sous le nom 蒼 き 翼 の シ ュ バ リ エ ( Aoki Tsubasa no Chevalier ), il n’y avait aucun texte ni aucune version en anglais.
Encodage de texte japonais
Quelque chose qui s’applique à la plupart des jeux japonais est que le texte et le code source ont tendance à être encodés en utilisant l’encodage Shift-JIS plutôt que l’encodage UTF-8 qui est beaucoup plus couramment utilisé dans les logiciels. Cela peut entraîner des erreurs de syntaxe lorsque le compilateur interprète le code source comme un autre encodage et rencontre des caractères inattendus. Notre solution à cela a été de créer un script qui convertit le code source en UTF-8.
Il y a cependant un hic à faire cela. Si le code source contient des chaînes codées en dur, celles-ci seront également converties, ce qui causera des ravages lorsque ces chaînes seront ensuite transmises aux systèmes qui attendent toujours le codage Shift-JIS. Heureusement pour nous, SoSCR et SoSW n’en avaient pas.
Le texte mal interprété apparaît comme des caractères apparemment aléatoires. Notez que les caractères latins restent les mêmes car les deux encodages se chevauchent pour ces caractères
Données textuelles des actifs
Dans les deux jeux, le texte affiché au joueur était réparti sur plusieurs fichiers et types de fichiers différents. La séparation étant déterminée par des outils de création de contenu qui déterminent quelle fonctionnalité ou quel écran finit par afficher le texte dans le jeu.
Donc, si jamais vous vous retrouvez à travailler sur le portage d’un jeu, ne supposez jamais que vous avez trouvé tout le texte une fois que vous êtes tombé sur le plus gros fichier contenant des données textuelles. Une bonne pratique consiste à rechercher dans tous les fichiers avec un éditeur de texte ou un script personnalisé pour vérifier les mots et expressions courants. Cela vous aidera à découvrir tous les fichiers contenant du texte dans le projet. Assurez-vous simplement de vérifier également les fichiers binaires!
Ne présumez jamais que vous avez trouvé tout le texte une fois que vous êtes tombé sur le plus gros fichier contenant des données textuelles
Pour ce projet, le texte a été divisé en :
- Texte qui n’est affiché que dans l’interface utilisateur.
- Texte prononcé par les personnages.
- Texte associé à des objets, généralement appelés “données de type” (objets, sorts, quêtes, etc.).
- Texte affiché dans un manuel du jeu.
La source de ces différents types de texte était des feuilles de calcul Excel. Ces feuilles de calcul Excel ont ensuite été utilisées comme entrée pour une série d’outils personnalisés, produisant différents fichiers tels que des en-têtes C++, des fichiers de texte brut ou des formats binaires personnalisés. Nous avons dû prendre en compte toutes ces différentes sources de données textuelles lorsque nous avons travaillé sur les systèmes de localisation pour le portage des jeux.
Le texte du didacticiel des deux jeux est contenu dans un fichier séparé
Solutions de localisation pour SoSCR
Pour SoSCR, une version anglaise et japonaise de ces textes existait déjà et la solution pour que le jeu prenne en charge les deux langues en même temps consistait à créer les ressources compilées pour les deux langues et à charger le fichier correct en fonction du paramètre de langue. Ainsi, par exemple, avant nous avions un seul fichier “dialog.dat” et après nous aurions deux fichiers nommés “dialog_en.dat” et “dialog_jp.dat”.
Ce n’était pas la seule solution au problème : il y avait aussi la possibilité d’entrelacer les deux langues dans le même fichier. Cette option finira par coûter moins d’espace sur le disque dur car il n’y a qu’un seul fichier, mais nécessite un outil qui génère le fichier à modifier et le code qui le charge. Nous avons trouvé que c’était la solution la moins idéale, car les JRPG comme SoSCR ont beaucoup de types de données de type différents ; la quantité de code à adapter représentait tout simplement un trop grand risque. Donc finalement nous sommes allés avec la première solution.
Un cas dans lequel cette approche de fichier divisé ne fonctionnait pas était avec le fichier de script personnalisé utilisé pour le dialogue. Ce fichier contenait le texte prononcé par les personnages ainsi que des commandes spécifiques au jeu telles que donner au groupe un élément clé ou commencer une nouvelle quête. C’est à cause de cela que le fichier ne pouvait pas être rechargé pendant le jeu. Essayer de le faire rendrait les références aux structures de données internes invalides et ferait planter le jeu. L’outil qui a créé ce fichier de script personnalisé vous permet de choisir si vous souhaitez utiliser le texte anglais ou japonais dans le fichier généré. Il utilise ensuite les ID de texte des fichiers source du script pour inclure la ligne de texte à insérer dans le fichier de sortie.
La solution que nous avons choisie ici était de découpler la substitution de langue que l’outil de script fait aux fichiers texte. Alors maintenant, le fichier de script personnalisé ne contient que les ID de texte et n’insère pas le texte final, à la place, le jeu effectue cette recherche dans le texte de la boîte de dialogue en anglais ou en japonais en fonction du paramètre de langue.
L’une des formes les plus courantes de données de type dans les RPG sont les éléments
Solutions de localisation pour SoSW
Dans le cas de SoSW, faire une version bilingue était plus compliqué. Il possède également un fichier de script personnalisé comme SoSCR, mais contrairement au premier jeu, l’outil qui génère le fichier de script personnalisé n’effectue pas la substitution de texte à l’aide d’ID de texte. Tout le texte parlé est présent directement dans les fichiers source du fichier de script personnalisé.
Des fichiers comme celui-ci ne peuvent évidemment pas être remis à une équipe de localisation car ils contiennent des lignes de code utilisées pour sélectionner le texte requis. Le problème auquel nous avons été confrontés était donc la nécessité d’extraire ces chaînes dans une feuille Excel afin que le flux de travail soit le même que celui de SoSCR.
Pour ce faire, nous avons créé un script Python qui a itéré sur le fichier de script personnalisé, rassemblant tout le texte et remplaçant en même temps ledit texte par un ID afin qu’il puisse être utilisé pour rechercher une chaîne anglaise ou japonaise lors de l’exécution.
Étant donné que le texte anglais prend généralement plus de place que le japonais, certains éléments de l’interface utilisateur ont dû être redimensionnés
Une autre source de texte qui causait des problèmes était le texte des données de type. Ceux-ci ont tendance à avoir des noms courts pour leur identification et comme le japonais nécessite moins de caractères pour ces mots, les membres des structures de données de type associées n’étaient pas assez longs pour tenir dans le texte anglais.
Au début, nous avons essayé d’augmenter la taille en octets de ces champs à la fois dans le jeu et dans l’outil qui a compilé les actifs de données de type. Malheureusement, l’outil s’est avéré très fragile. Nous avons donc fini par contourner le problème en exportant le texte de données de type anglais vers un fichier entièrement nouveau et en y faisant référence depuis le jeu uniquement si la langue était définie sur l’anglais. Bien que ce ne soit pas une solution idéale, c’est une solution sans inconvénient pour le jeu lui-même, nous en étions donc toujours satisfaits.
L’un des derniers problèmes que nous avons résolus était que, du fait que le texte anglais prenait généralement plus de place que le japonais, certains éléments de l’interface utilisateur devaient être redimensionnés afin de l’adapter. Réduire le texte est également une option ici, mais a tendance à sembler plutôt mauvais, en particulier dans les cas où des multiples du même type de texte sont à l’écran, comme dans une liste.
Enfin, il y avait aussi des images avec du texte et des vidéos avec du texte. La solution ici était simplement d’utiliser à nouveau l’approche des fichiers multiples et de les charger en fonction de la langue.
L’arrière-plan du nom de l’emplacement a dû être modifié afin de s’adapter correctement à tous les noms d’emplacement
En fin de compte, chaque projet est une opportunité d’apprentissage avec ses propres défis à surmonter. C’était la première fois que nous portions un RPG d’exploration de donjons sur des plates-formes modernes et nous en avons beaucoup appris.
Thomas Jongman était l’un des responsables du projet Stranger of Sword City Revisited / Saviors of Sapphire Wings de Codeglue et est programmeur de jeux dans l’entreprise depuis 2019.
Découvrez encore plus d’articles dans nos catégories Astuce, Consoles ou encore Jeux.
Merci pour votre visite on espère que notre article Les défis techniques de la localisation et comment les résoudre
, pensez à partager l’article sur Facebook, instagram et e-mail avec les hashtag ☑️ #Les #défis #techniques #localisation #comment #les #résoudre ☑️!