La préparation d'un jeu pour la localisation est une partie importante du développement du jeu.
Nous travaillons sur le jeu "
Cat Movies! " Dans Unreal Engine 4. Il s'agit d'une stratégie économique dans laquelle il y a beaucoup de texte, et nous prévoyons de le traduire dans différentes langues. Comme beaucoup d'autres (mais ce n'est pas exact, et j'espère que ce n'est pas le cas), nous avons décidé de reporter l'étape de la mise en place de la localisation à des itérations de développement ultérieures et, en fin de compte, en vain.
La localisation dans UE4 est élégamment implémentée, et si vous vous souvenez que tout le texte qui sera traduit est suffisant pour être stocké dans les champs Ftext (Text in Blueprint'ah), alors en général, il n'y a aucun problème à récupérer le texte du jeu. Il suffit d'ouvrir le tableau de bord de localisation, de pousser quelques boutons - et le tour est joué.
Et, malgré la simplicité de cette action, nous avons toujours rencontré un certain nombre de problèmes, à cause desquels nous avons dû creuser une partie du code.
Mis à jour le 10.16.19: mise en forme du texte.Comment stocker du texte
Les gars d'Epic Games ont simplifié l'assemblage du texte au maximum, réduisant tout en un clic et une traduction supplémentaire.
Tout fonctionne très simplement - pour la localisation, le type de données FText (Text in Blueprints) est utilisé, dans lequel le texte est enregistré, et ce texte est ensuite collecté par le système de localisation et fourni pour la traduction.
Comment ça marche?FText n'est pas un type de données standard qui stocke des données en soi. Bien sûr, il stocke des données en soi, mais pas les données que nous attendons.
FText est un pointeur. Il indique dans quel tableau le texte est stocké. En d'autres termes, lorsque nous affectons du texte à une variable de ce type, le texte est stocké dans une table virtuelle et la variable elle-même stocke désormais le nom de la table et la clé permettant de trouver le texte dans cette table.
Ainsi, il s'avère que le texte lui-même est stocké ailleurs (nous ne considérerons pas les subtilités de sa mise en œuvre, car nous ne nous y intéressons pas particulièrement), et lors du basculement de la localisation vers l'adresse souhaitée, le texte est remplacé (enfin, ou Je veux le penser).
Lorsque la collecte de texte est lancée, le système de localisation collecte toutes les variables de texte de tous les plans, widgets et tableaux, et déploie une énorme liste de texte qui peut être exportée vers * .po et traduite.
Notre jeu dispose d'un large éventail de widgets à travers lesquels le joueur contrôlera presque tout le gameplay. Nous avons de nombreux noms (par exemple, des départements ou des étapes de création de films ou certaines compétences, des bonus, etc.) qui sont utilisés dans divers widgets qui sont complètement indépendants les uns des autres. Il existe des descriptions de certains objets (par exemple, une description des bonus), et cela est également utilisé plus d'une fois dans divers widgets non liés.
Et ici commence la difficulté. Si nous réécrivons les noms des départements dans chaque widget, à un moment donné dans l'un des widgets, le nom des départements sera mal orthographié. Cette question est compliquée par le fait que les «descriptions» elles-mêmes (par exemple, la description du département) en un grand nombre de caractères sont difficiles à suivre de sorte qu'elles sont les mêmes partout (naturellement, nous ne l'avons pas fait). Encore plus amusant, nous avons la plupart des widgets utilisés comme modèle dans lesquels les données de diverses sources arrivent, et en fonction de la source, les noms et les textes à l'intérieur du code changent.
Nous avons facilité notre tâche en créant une table de données, dans laquelle nous avons commencé à stocker des données de types spécifiques. Par exemple, une table de service qui contient le nom, la description, le niveau maximum, le nombre d'employés par niveau, etc. etc.
Il semblerait qu'il était possible de s'y attarder, mais il y avait une difficulté dans le fait que les données du tableau changeaient constamment, quelque chose était réécrit, qui était supprimé au fur et à mesure que le code grandissait, et il y avait des cas où le tableau entier volait et nous devions reculer, retirer données, revenez à l'état actuel et réinsérez les données perdues.
Tout est devenu beaucoup plus triste quand j'ai décidé de me lancer dans la localisation et finalement de l'essayer pour comprendre si nous le faisons tous correctement.
J'ai retiré tout le texte du jeu et j'ai réalisé que dans le code, malgré le fait que nous essayions d'éviter la répétition, il y avait un grand nombre d'éléments répétés du texte.
La traduction est une chose humaine. S'il y a une possibilité de faire une erreur, les gens feront nécessairement une erreur. Et pour éviter cela ou du moins le minimiser, vous devez réduire tous les textes à un seul modèle. Autrement dit, sortir quelque part en un seul endroit, d'où le texte sera pris dans toutes les parties du code. Et qui ne sera traduit qu'une seule fois afin de minimiser les risques d'erreurs. Il semblerait que vous puissiez utiliser DataTable, mais il y a un certain nombre de problèmes - pour enregistrer uniquement les noms de quelque chose, nous devons créer des tables entières qui stockeront ces noms.
Après avoir fouillé dans la documentation d'Epic Games, j'ai tourné mon attention vers les
String Tables (ci-après dénommées «String Tables»). Il s'est avéré que c'est une option idéale - pour stocker le texte dans un tableau séparé spécial pour les textes, qui a été créé juste pour être connecté aux variables FText. Autrement dit, nous pouvons créer un tableau qui stockera le texte en lui-même. Et nous pouvons connecter ce texte à n'importe quelle variable - que ce soit une variable dans le tableau de données, une variable dans le widget, une variable dans le code - tout se résume à un endroit où le texte est stocké.
Les tableaux de chaînes vous permettent d'éviter de répéter le texte dans un projet plusieurs fois un peu plus que complètement, évitant ainsi les erreurs.
Les tables de chaînes sont créées dans le moteur, tout comme les tables de données dans la section divers:
Il est très facile à remplir - chaque nouvelle ligne doit avoir une clé unique que vous devez inventer vous-même. Et le texte lui-même peut déjà être n'importe lequel. De plus, dans le tableau, vous pouvez spécifier un nom différent pour l'espace de texte à partir du nom du tableau, mais, selon notre expérience, cela n'est pas nécessaire.
Une fois la table de chaînes créée, le texte peut maintenant être connecté à la variable FText:
Ainsi, nous avons réduit le texte à un tableau à une seule ligne, dont il est très facile à extraire. Pour obtenir ce menu de paramètres de texte, cliquez simplement sur la flèche vers le bas à côté de la variable de texte.
Localisation
Il ne nous reste plus qu'à rassembler tout le texte et à commencer à travailler avec. Pour ce faire, nous devons démarrer le Tableau de bord de localisation et démarrer les paramètres de localisation. Vous pouvez exécuter la table via le menu Fenêtre-> Tableau de bord de localisation.
Et avant d'ouvrir quelque chose comme cette fenêtre:
Dans cette fenêtre, vous devez spécifier l'objectif (module) duquel le texte sera extrait. Dans notre cas, c'est un jeu - Jeu.
Ensuite, vous devez spécifier où exactement le texte sera extrait dans le module. Dans notre cas, ce ne sont que des contours, car nous ne stockons pas de texte dans les cours. Par conséquent, nous devons spécifier uniquement «Rassembler à partir de packages» et indiquer dans quels dossiers et quels fichiers nous devons prendre en compte pour rechercher des textes.
Nous devons également indiquer quelles langues seront utilisées pour la traduction et quelle langue sera native (principale). Je recommande fortement si vous écrivez et parlez russe - indiquez la langue russe (ou toute autre langue principale). Cela est dû au fait que si vous ne connaissez pas bien l'anglais, alors en l'indiquant comme le principal, vous compliquez votre traduction en anglais de "English". Par conséquent, il est préférable d'indiquer à l'avance votre langue comme langue principale et d'écrire tous les textes dans votre propre langue, afin de pouvoir plus tard faciliter les traductions pour vous-même et pour les autres.
Toujours dans UE4, il existe une excellente occasion de créer des traductions directement dans le moteur, sans exporter de textes pour des programmes tiers. Pour ce faire, vous devez collecter tout le texte pertinent dans le jeu en cliquant sur le bouton numéro 1. Et puis lancez l'éditeur (bouton numéro 2):
Une fenêtre d'édition de la traduction dans la langue dont vous avez besoin s'ouvre.
Assemblage
Lors de l'assemblage d'un projet, vous devez spécifier les langues qui doivent être incluses dans cet assemblage, ainsi que l'ensemble des langues que votre projet doit prendre en charge.
Dans notre cas, la prise en charge de l'internationalisation est définie sur Tous. Autrement dit, notre projet prendra en charge tous les types de langues, des hiéroglyphes complexes aux simples lettres anglaises. En général, il existe 5 packages:
- Anglais (anglais pur).
- EFIGS (anglais, français, italien, allemand et espagnol)
- EFIGSCJK (comme ci-dessus + chinois, japonais et coréen)
- CJK (chinois, japonais et coréen).
- Tous (toutes les langues).
Cependant, dans les cas où chaque octet du projet est important (le package All pèse 15 Mo et EFIGS 2 Mo), vous devez prêter plus d'attention au package que vous devez choisir.
Commutation de localisation
La commutation de texte se produit dans Runtime, c'est-à-dire que vous n'avez pas besoin de redémarrer le jeu, vous n'avez pas à vous soucier de l'optimisation de la commutation - tout se fait facilement et simplement via la méthode "
SetCurrentCulture ", où vous devez indiquer avec le texte dans quelle langue vous souhaitez basculer.
Et ici, il y a un tel problème. Le fait est que différents pays ont leurs propres branches linguistiques, par exemple, il y a la principale langue russe (ru), mais il y a le biélorusse (ru-BY), le kazakh (ru-KZ), le moldave (ru-MD), l'ukrainien (ru -UA) langues qui relèvent de la branche de la langue russe. Par conséquent, lorsque vous choisissez une langue qui n'est pas la principale, vous devez considérer et indiquer la langue correcte. Si vous sélectionnez uniquement le principal, puis lors du changement, spécifiez simplement "ru".
Ajout d'autres données au texte dans Blueprint.
Si des accolades sont indiquées dans le texte lui-même et que le nom des données y est indiqué, à l'avenir, vous pouvez utiliser la substitution de ces mêmes données dans le texte.
Par exemple:
"Souhaitez-vous apprendre la technologie {Tech_Name}?"Et, en outre, dans BP, vous pouvez utiliser le nœud "Format texte", qui prendra en compte le texte lui-même et les paramètres qui y sont indiqués et créera des broches supplémentaires pour connecter ces mêmes données:
Maintenant, des informations supplémentaires seront incorporées dans le texte, qui peuvent être corrigées sans corriger le texte lui-même. Par exemple, vous pouvez entrer les noms des départements ou des technologies, vous pouvez spécifier des niveaux ou autre chose.
Conclusion
Après avoir rassemblé toutes ces informations, j'ai réalisé que depuis le tout début, nous n'avions pas correctement abordé la création de texte dans le jeu et fait beaucoup de travail inutile. Bien sûr, nous n'avons pas retravaillé le code pendant des mois, mais y avons passé un maximum de 1,5 heure, mais il serait plus agréable de connaître à l'avance les principes de localisation dans UE4 et de les prendre en compte lors de la construction de l'architecture du projet.
Il en va de même pour l'enregistrement et le chargement dans les jeux. Cela ne s'est pas avéré être une tâche si facile dans le contexte de la stratégie, où chaque petite chose devrait être fixée là où elle se trouve / se trouve / a un certain état. Mais j'écrirai à ce sujet une autre fois. Et maintenant, vous pouvez continuer à regarder notre match dans notre groupe =)