Aperçu de la localisation dans l'Unreal Engine | Unreal Engine 5.7 Documentation

Localisation et internationalisation

La localisation et l'internationalisation (L10N et I18N) sont deux concepts qui sont souvent combinés sous le terme générique de « localisation ». Cependant, il s'agit de deux choses distinctes et l'Unreal Engine (l'UE) les gère de manière différente. Le système de localisation dans l'UE est centré sur notre type « texte », tandis que notre prise en charge de l'internationalisation utilise la bibliothèque International Components for Unicode (ICU).

Bien que distincts, dans l'UE, la localisation à l'exécution nécessite la prise en charge appropriée de l'internationalisation.

Prise en charge de l'ICU et de l'internationalisation

ICU est une bibliothèque d'internationalisation mature et robuste que l'UE utilise pour gérer tout ce qui implique des données ou un traitement spécifiques à une culture, y compris les éléments suivants :

Obtention de la culture actuelle pour la plate-forme ou le système d'exploitation.
Gestion du repli prioritaire des cultures.
Gestion de la mise en forme culturellement correcte des nombres (y compris les pourcentages et les devises), des dates et des heures (y compris les données de fuseau horaire).
Gestion de la pluralité culturellement correcte des nombres (lors de la mise en forme du texte).
Gestion de la transformation de texte conforme à Unicode (par exemple, ToUpper, ToLower).
Gestion de la comparaison et du collationnement de texte conformes à Unicode.
Gestion de l'analyse des limites conforme à Unicode (caractères, mots et sauts de ligne).
Gestion de la détection de texte bidirectionnelle (BiDi) conforme à Unicode.

Les données spécifiques à la culture dont l'ICU a besoin pour fonctionner sont stockées en dehors de l'ICU elle-même, et l'UE fournit des ensembles de données simplifiées que vous pouvez utiliser pour réduire la taille de votre projet :

Anglais (~1,77 Mo)
EFIGS - Anglais, français, italien, allemand et espagnol (~2,38 Mo)
EFIGSCJK - Anglais, français, italien, allemand, espagnol, chinois, japonais et coréen (~5,99 Mo)
CJK - Chinois, japonais et coréen (~5,16 Mo)
Tout (~15,3 Mo)

Le choix que vous ferez dépendra des régions pour lesquelles vous localisez votre projet, et ces choix peuvent être définis dans vos paramètres de projet. Voir Empaquetage des données de localisation pour plus d'informations.

Cultures

Les cultures de l'UE contiennent des informations d'internationalisation pour des paramètres régionaux spécifiques. Les noms de culture sont composés de trois parties séparées par des traits d'union (une étiquette d'identification de langues IETF) :

Un code de langue à deux lettres ISO 639-1 (tel que « zh »).
Un code de script facultatif à quatre lettres ISO 15924 (tel que « Hans »).
Un code de pays facultatif à deux lettres ISO 3166-1 (tel que « CN »).

Lorsque l'UE recherche des données de localisation pour une culture spécifique, elle les traite de la plus spécifique à la moins spécifique. Exemple :

zh-Hans-CN est traité comme « zh-Hans-CN », puis « zh-CN », puis « zh-Hans » et enfin « zh ».
en-GB est traité comme « en-GB », puis « en ».

Pour obtenir la couverture la plus large possible pour une culture donnée, il faut utiliser le code de culture le moins spécifique possible. En général, il s'agit simplement du code de langue, mais vous devez être conscient des variations linguistiques régionales qui doivent être prises en compte.

Dans la plupart des cas, ces variations régionales sont limitées à un code de pays spécifique, ce qui les rend faciles à résoudre. Il existe cependant des cas plus complexes, comme indiqué ci-dessous.

Chinois

Le chinois possède deux variantes, simplifié et traditionnel, représentées par les codes de script ISO-15924 « Hans » et « Hant ». Utilisez « zh-Hans » pour votre localisation en chinois simplifié et « zh-Hant » pour la localisation en chinois traditionnel.

Espagnol

L'espagnol a deux variantes principales : européen et latino-américain. Cependant, il n'existe pas de code de script pratique qui puisse être utilisé pour distinguer les variantes entre elles. Il existe une étiquette d'identification de langues IETF pour l'espagnol latino-américain (« es-419 »), mais la plupart des plates-formes ne la fourniront pas et vous donneront à la place un code de pays réel (comme « es-MX »).

Pour résoudre ce problème, utilisez « es » pour l'espagnol européen et « es-419 » pour l'espagnol latino-américain. Utilisez ensuite la fonctionnalité de remappage des cultures de l'UE pour mapper les pays hispanophones d'Amérique latine sur « es-419 ».

Vous pouvez le faire en ajoutant ce qui suit à votre fichier DefaultGame.ini :

	[Internationalisation]
	+CultureMappings="es-AR;es-419"
	+CultureMappings="es-BO;es-419"
	+CultureMappings="es-CL;es-419"
	+CultureMappings="es-CO;es-419"
	+CultureMappings="es-CR;es-419"
	+CultureMappings="es-CU;es-419"
	+CultureMappings="es-DO;es-419"
	+CultureMappings="es-EC;es-419"
	+CultureMappings="es-GT;es-419"
	+CultureMappings="es-HN;es-419"
	+CultureMappings="es-MX;es-419"
	+CultureMappings="es-NI;es-419"
	+CultureMappings="es-PA;es-419"
	+CultureMappings="es-PE;es-419"
	+CultureMappings="es-PR;es-419"
	+CultureMappings="es-PY;es-419"
	+CultureMappings="es-SV;es-419"
	+CultureMappings="es-US;es-419"
	+CultureMappings="es-UY;es-419"
	+CultureMappings="es-VE;es-419"

Cibles de localisation

Les cibles de localisation sont des modules nommés et autonomes de données de localisation. Les cibles de localisation ont les propriétés suivantes :

Elles disposent de textes collectés à partir d'un ensemble spécifique de sources ;
Elles sont stockées dans un fichier manifeste ;
Elles sont traduites dans des fichiers d'archives spécifiques à chaque culture ;
Elles sont compilées dans des fichiers de ressources de localisation spécifiques à la culture et ce sont les fichiers de ressources compilés spécifiques à la culture qui sont affichés par le système.

Un projet peut avoir une seule cible de localisation pour plus de simplicité ou en avoir plusieurs afin de diviser les données de localisation du projet en sections. L'Unreal Editor dispose d'une cible de localisation distincte du reste de l'UE, de sorte que l'éditeur peut être localisé sans distribuer ces données de localisation avec les jeux. En règle générale, un jeu aura une cible de localisation pour toutes les données de localisation du projet de base et des cibles de localisation supplémentaires pour toutes les extensions.

Pipeline de localisation

Le pipeline de localisation de l'UE est modélisé autour d'une approche de localisation « author-at-source » (créer à la source). Cela signifie que si vous avez besoin d'un texte indiquant « Bonjour le monde ! » dans votre interface utilisateur, il vous suffit de saisir « Bonjour le monde ! » dans la propriété de texte (ou d'utiliser les macros NSLOCTEXT ou LOCTEXT en C++) et le collecteur de localisation se charge de capturer le texte afin qu'il puisse être localisé.

L'approche « créer à la source » est très dynamique et évite aux développeurs toute réflexion excessive sur la localisation au cours du développement. Cependant, cela peut également être frustrant pour les équipes qui recherchent un contrôle strict sur le texte utilisé dans leur projet. Pour résoudre ce problème, l'UE prend en charge les tables de chaînes pour permettre une approche de localisation « author-once-and-reference » (créer une fois et référencer) [bien qu'en interne, le pipeline traite simplement les tables de chaînes comme une autre source de création à la source (« author-at-source »)].

Une ancienne méthode (qui n'est plus prise en charge) pour contourner l'absence de tables de chaînes natives consistait à utiliser une « fausse » culture native (très probablement « es-US-POSIX ») avec des identifiants comme texte source, puis à utiliser les fonctions de réduction de chaînes dont disposait l'UE avant la version 4.14 pour traduire ces identifiants dans chaque langue. Vous pouvez trouver des références à cette méthode dans des questions d'assistance plus anciennes, mais elle ne doit plus être utilisée. Les projets utilisant cette méthode doivent migrer vers les tables de chaînes.

Le pipeline de localisation lui-même fonctionne sur des cibles de localisation, et une cible de localisation est composée de deux parties : sa configuration (stockée dans Config/Localization/) et ses données (stockées dans Content/Localization/{TargetName}/).

Si nous supposons une cible de localisation fonctionnant avec l'anglais (« en ») et le français (« fr »), sa disposition dans le dossier Content/Localization/ ressemblerait à ceci :

	{TargetName}/
	{TargetName}.manifest
	{TargetName}.locmeta
	en/
		{TargetName}.archive
		{TargetName}.po
		{TargetName}.locres
	fr/
		{TargetName}.archive
		{TargetName}.po
		{TargetName}.locres

Tous les fichiers et dossiers ci-dessus sont générés par les différentes parties du pipeline de localisation.

Dossier	Description
{TargetName}.manifest	Les manifestes sont des fichiers JSON personnalisés qui stockent tout le texte collecté à partir de votre code source et de vos ressources par le pipeline de localisation. Les manifestes sont régénérés chaque fois que l'étape de collecte de localisation est exécutée et ne doivent pas être modifiés manuellement.
{TargetName}.archive	Les archives sont des fichiers JSON personnalisés qui stockent les traductions par culture pour le texte collecté dans le manifeste. Les archives sont réduites chaque fois que les étapes de collecte ou d'importation de localisation sont exécutées pour supprimer des entrées des anciennes sources. Les archives peuvent être modifiées à la main, mais nous vous le déconseillons fortement. Notre flux de travail recommandé consiste à modifier les fichiers PO exportés et à les réimporter.
{TargetName}.po	Les fichiers PO (Portable Object) contiennent le texte par culture à traduire, ainsi que leurs traductions actuelles. Les fichiers PO sont générés par l'étape d'exportation du texte de localisation et sont réimportés dans les archives par l'étape d'importation du texte de localisation. Le format PO est un format courant qui peut être modifié localement soit à la main, soit via un outil de traduction comme Poedit, ou de manière collaborative via une solution comme OneSky ou XLOC.
{TargetName}.locres	Les fichiers LocRes sont des fichiers binaires personnalisés qui stockent les traductions compilées par culture pour une utilisation au moment de l'exécution. Les fichiers LocRes sont régénérés chaque fois que l'étape de compilation de localisation est exécutée et sont intégrés dans une version empaquetée. Les fichiers LocRes sont les seuls fichiers à partir desquels votre projet chargera les données de localisation au moment de l'exécution (y compris dans l'éditeur), de sorte que les modifications ou changements apportés à vos données sources (comme l'importation d'un fichier PO) doivent être compilés avant de prendre effet.
{TargetName}.locmeta	Les fichiers LocMeta sont des fichiers binaires personnalisés qui stockent les métadonnées cibles compilées (uniquement la culture native de la cible pour l'instant) pour une utilisation au moment de l'exécution. Les fichiers LocMeta sont régénérés chaque fois que les données de localisation sont compilées et sont intégrés dans une version empaquetée.

Les cibles de localisation spécifient également une culture « native », qui doit être définie sur la culture dans laquelle vous créez votre contenu (communément appelée « texte source » ou « données sources »).

Les cultures natives peuvent contenir des « traductions » comme toute autre culture, bien que les traductions des cultures natives n'existent que pour faciliter la révision de votre texte source sans modifier directement le code source ou les ressources.

Les cultures étrangères utilisent le texte de la culture native comme texte source pour la traduction et deviendront « obsolètes » si le texte de la culture native est modifié (il existe un paramètre dans l'étape de compilation de la localisation pour autoriser les traductions obsolètes si nécessaire).

Pour plus d'informations sur l'optimisation de votre pipeline de localisation, consultez Optimisation du pipeline.

Format de fichier PO

L'Unreal utilise le format par défaut suivant pour ses fichiers PO, en fonction du mode de réduction utilisé dans l'exportation de fichiers PO.

Lorsque vous utilisez le mode de réduction Identical Text Identity and Source Text (Identité de texte et texte source identiques) :
- msgctxt contient l'identité Unreal de l'entrée.
- msgid contient la chaîne source.
- msgstr contient la traduction.
Lorsque vous utilisez le mode de réduction Identical Namespace and Source Text (Espace de noms et texte source identiques) :
- msgctxt contient l'espace de noms Unreal de l'entrée.
- msgid contient la chaîne source.
- msgstr contient la traduction.

Nous avons également un format alternatif qui produit de meilleurs résultats si l'on utilise Crowdin pour gérer les traductions, mais veuillez noter que ce format n'est pas en mesure de détecter les traductions obsolètes importées à partir de fichiers PO (car nous n'avons plus la source à partir de laquelle la traduction a été réalisée).

Ce mode produit le même résultat lorsque vous utilisez le mode de réduction « Espace de noms et texte source identiques », mais pour le mode de réduction « Identité de texte et texte source identiques », il produit ce qui suit :

msgctxt n'est pas utilisé.
msgid contient l'identité Unreal de l'entrée.
msgstr contient la chaîne source (pour la culture native) ou la traduction (pour les cultures étrangères).
L'attribut d'en-tête X-Crowdin-SourceKey spécifie que msgstr est utilisé comme texte source de la culture native.

Empaquetage des données de localisation

L'empaquetage des données de localisation et d'internationalisation correctes pour votre projet nécessite d'ajuster certains paramètres dans la section avancée Packaging (Empaquetage) de vos paramètres de projet.

Les deux paramètres que vous voudrez vérifier sont les suivants :

Localizations to Package (Localisations à empaqueter) - Avec ce paramètre, vous pouvez choisir les cultures pour lesquelles vous souhaitez préparer les données de localisation. Vous pouvez utiliser l'option Show Localized (Afficher la localisation) pour filtrer la liste afin d'afficher uniquement les cultures pour lesquelles vous avez des fichiers LocRes.
Internationalization Support (Prise en charge de l'internationalisation) - Avec ce paramètre, vous pouvez choisir l'ensemble de données d'internationalisation de l'ICU que vous souhaitez préparer. Cette option doit chevaucher les données de localisation que vous souhaitez préparer.