Übersicht über die Lokalisierung für Unreal Engine | Unreal Engine 5.6 Dokumentation

Lokalisierung und Internationalisierung

Lokalisierung und Internationalisierung (L10N und I18N) sind zwei Konzepte, die oft unter dem Oberbegriff „Lokalisierung“ zusammengefasst werden. Allerdings sind es zwei verschiedene Dinge, die in Unreal Engine (UE) auf unterschiedliche Weise gehandhabt werden. Das Lokalisierungssystem in UE konzentriert sich auf den Typ „Text“, wohingegen unsere Unterstützung der Internationalisierung die (ICU)-Bibliothek International Components for Unicode nutzt.

Obwohl beide unabhängig voneinander sind, ist eine Lokalisierung zur Laufzeit in UE ohne die entsprechende Unterstützung der Internationalisierung nicht möglich.

ICU und Unterstützung der Internationalisierung

ICU ist eine ausgereifte und stabile Internationalisierungsbibliothek, die UE für alle Vorgänge verwendet, bei denen Sprachregion-spezifische Daten oder Verarbeitungen im Spiel sind, einschließlich Folgendem:

Abrufen der aktuellen Sprachregion für die Plattform / das Betriebssystem.
Handhabung des priorisierten Fallbacks von Sprachregionen.
Handhabung der Sprachregion-korrekten Formatierung von Zahlen (einschließlich Prozentsätzen und Währung) sowie Datums- und Zeitangaben (einschließlich Zeitzonendaten).
Handhabung der Sprachregion-korrekten Zahlenpluralität (während der Textformatierung).
Handhabung der Unicode-konformen Transformation von Text (z. B. ToUpper, ToLower).
Handhabung von Unicode-konformem Vergleich und Sortierung von Text.
Handhabung von Unicode-konformen Grenzanalysen (Zeichen, Worte und Zeilenumbrüche).
Handhabung der Unicode-konformen bidirektionalen (BiDi) Texterkennung.

Die Sprachregion-spezifischen Daten, die ICU braucht, um zu funktionieren, werden außerhalb von ICU selbst gespeichert. UE bietet ein paar grobe Datensätze, mit denen Sie die Größe Ihres Projekts minimieren können:

Englisch (ca. 1,77 MB)
EFIGS – Englisch, Französisch, Italienisch, Deutsch und Spanisch (ca. 2,38 MB)
EFIGSCJK – Englisch, Französisch, Italienisch, Deutsch, Spanisch, Chinesisch, Japanisch und Koreanisch (ca. 5,99 MB)
CJK – Chinesisch, Japanisch und Koreanisch (ca. 5,16 MB)
Alle (ca. 15,3 MB)

Für welche davon Sie sich entscheiden, hängt von den Regionen ab, für die Sie Ihr Projekt lokalisieren. Diese Auswahl können Sie in Ihren Project Settings festlegen. Weitere Informationen finden Sie unter Paketierung von Lokalisierungsdaten.

Sprachregionen

Sprachregionen in UE enthalten Internationalisierungsinformationen für ein bestimmtes Gebietsschema. Sprachregionsnamen bestehen aus drei durch Bindestrich getrennten Teilen (einem IETF-Sprachen-Tag):

Ein aus zwei Buchstaben bestehender ISO 639-1-Sprachcode (wie z. B. „zh“).
Eine optionaler ISO 15924-Script-Code (z. B. „Hans“).
Ein optionaler zweistelliger ISO 3166-1-Ländercode (wie z. B. „CN“).

Wenn UE nach Lokalisierungsdaten für eine bestimmte Sprachregion sucht, verarbeitet es sie in der Reihenfolge von den spezifischsten bis zu den am wenigsten spezifischen. Zum Beispiel:

zh-Hans-CN wird als „zh-Hans-CN“ verarbeitet, dann als „zh-CN“, dann „zh-Hans“ und dann als „zh“.
en-GB wird als „en-GB“ verarbeitet, dann als „en“.

Um die größtmögliche Abdeckung für eine bestimmte Sprachregion zu erreichen, verwenden Sie am besten den am wenigsten spezifischen Sprachregionscode, der gültig ist. Normalerweise ist das nur der Sprachcode, aber Sie sollten auch auf die regionalen Sprachvarianten achten, die beachtet werden müssen.

In den meisten Fällen sind diese regionalen Varianten auf einen bestimmten Ländercode beschränkt, wodurch sie leicht aufgelöst werden können. Es gibt aber auch ein paar komplexere Fälle, wie unten dargestellt.

Chinesisch

Chinesisch hat zwei Varianten, vereinfachtes und traditionelles Chinesisch, repräsentiert durch die ISO-15924-Script-Codes „Hans“ und „Hant“. Verwenden Sie „zh-Hans“ für Ihre vereinfachte Lokalisierung und „zh-Hant“ für Ihre traditionelle Lokalisierung.

Spanisch

Spanisch hat zwei Hauptvarianten: die europäische und die lateinamerikanische. Es gibt jedoch keinen geeigneten Script-Code, mit dem Sie die beiden voneinander unterscheiden können. Es gibt einen IETF-Sprachtag für lateinamerikanisches Spanisch („es-419“), aber die meisten Plattformen bieten diesen nicht an und geben Ihnen stattdessen einen tatsächlichen Ländercode („es-MX“).

Um das Problem zu lösen, verwenden Sie „es“ für europäisches Spanisch und „es-419“ für lateinamerikanisches Spanisch. Nutzen Sie dann die Funktion Neuzuordnung der Sprachregion von UE, um die spanischsprachigen Länder Lateinamerikas auf „es-419“ zu mappen.

Dies können Sie erreichen, indem Sie Folgendes zu Ihrer DefaultGame.ini-Datei hinzufügen:

	[Internationalization]
	+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"

Lokalisierungsziele

Lokalisierungsziele sind benannte, eigenständige Module mit Lokalisierungsdaten. Lokalisierungsziele haben die folgenden Eigenschaften:

Sie enthalten Text, der von einem bestimmten Satz aus Quellen erfasst wurde
Sie werden in einer Manifest-Datei gespeichert
Sie werden in Sprachregion-spezifische Archivdateien übersetzt
Sie werden zu Sprachregion-spezifischen Lokalisierungsressourcendateien kompiliert, und die kompilierten Sprachregion-spezifischen Ressourcendateien sind die, die das System anzeigt.

Ein Projekt kann der Einfachheit halber ein einziges Lokalisierungsziel oder mehrere Lokalisierungsziele haben, um die Lokalisierungsdaten des Projekts in Sektionen zu unterteilen. Der Unreal Editor hat über ein vom Rest von UE separates Lokalisierungsziel, sodass der Editor lokalisiert werden kann, ohne diese Lokalisierungsdaten mit Spielen zu verteilen. Normalerweise verfügt ein Spiel über ein Lokalisierungsziel für alle Lokalisierungsdaten des Basisprojekts sowie weitere Lokalisierungsziele für alle Erweiterungen.

Lokalisierungspipeline

Die UE-Lokalisierungspipeline basiert auf einem „Author-at-Source“-Ansatz zur Lokalisierung. Das heißt, wenn Sie einen Text benötigen, der „Hallo Welt!“ in Ihrer Benutzeroberfläche sagt, geben Sie einfach „Hello World!“ in die Texteigenschaft ein (oder Sie verwenden die Makros NSLOCTEXT oder LOCTEXT in C++) und der Lokalisierungs-Erfasser kümmert sich um die Erfassung des Texts, damit er lokalisiert werden kann.

Der „Author-at-Source“-Ansatz ist sehr dynamisch und erlaubt es Entwicklern, bei der Entwicklung nicht zu viel über die Lokalisierung nachzudenken. Allerdings kann es für Teams auch frustrierend sein, die strikte Kontrolle über den in ihrem Projekt verwendeten Text möchten. Um dies zu beheben, verfügt UE über Support für String-Tabellen, um einen „Einmal erstellen und referenzieren“-Ansatz für die Lokalisierung zu erlauben (intern behandelt die Pipeline String-Tabellen jedoch einfach als eine weitere „Author-at-Source“-Quelle).

Eine ältere (und nicht mehr unterstützte) Methode, um das Fehlen muttersprachlicher Stringtabellen zu umgehen, bestand darin, eine „falsche“ primäre Sprachregion (höchstwahrscheinlich „es-US-POSIX“) mit IDs als Quelltext zu verwenden und dann die String-Collapsing-Funktionen zu verwenden, die UE vor Version 4.14 hatte, um diese IDs in jede Sprache zu übersetzen. Sie finden vielleicht Referenzen zu dieser Methode in älteren Supportfragen, aber sie sollten nicht mehr verwendet werden. Projekte, die diese Methode verwenden, sollten zu String-Tabellen migriert werden.

Die Lokalisierungspipeline selbst arbeitet mit Lokalisierungszielen, und ein Lokalisierungsziel besteht aus zwei Teilen: seiner Konfiguration (gespeichert in Config/Localization/) und seinen Daten (gespeichert in Content/Localization/{TargetName}/).

Wenn wir davon ausgehen, dass ein Lokalisierungsziel mit Englisch („en“) und Französisch („fr“) arbeitet, dann sieht das Layout im Ordner Content/Localization/ so aus:

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

Alle oben genannten Dateien und Ordner werden von den verschiedenen Teilen der Lokalisierungspipeline generiert.

Ordner	Beschreibung
{TargetName}.manifest	Manifeste sind benutzerdefinierte JSON-Dateien, in denen sämtlicher Text gespeichert ist, der von der Lokalisierungspipeline aus Ihrem Quellcode und Ihren Assets erfasst wurde. Manifeste werden jedes Mal erneut generiert, wenn der Lokalisierungs-Erfassungsschritt ausgeführt wird, und sollten nicht von Hand bearbeitet werden.
{TargetName}.archive	Archive sind benutzerdefinierte JSON-Dateien, die Sprachregion-spezifische Übersetzungen für den im Manifest erfassten Text speichern. Archive werden jedes Mal bereinigt, wenn die Lokalisierungserfassungs- oder Importschritte ausgeführt werden, um Einträge für alte Quellen zu entfernen. Archive können von Hand bearbeitet werden, aber wir raten Ihnen ausdrücklich, keine Handbearbeitung durchzuführen. Unser empfohlener Workflow ist es, die exportierten PO-Dateien zu bearbeiten und erneut zu importieren.
{TargetName}.po	PO-Dateien (Portables Objekt) enthalten den zu übersetzenden Text pro Sprachregion sowie die aktuellen Übersetzungen. PO-Dateien werden durch den Schritt Lokalisierungs-Exporttext erstellt und durch den Schritt Lokalisierungs-Importtext in die Archive re-importiert. PO ist ein geläufiges Format und kann lokal entweder manuell oder über ein Übersetzungswerkzeug wie Poedit oder gemeinschaftlich über etwas wie OneSky oder XLOC bearbeitet werden.
{TargetName}.locres	LocRes sind benutzerdefinierte binäre Dateien, die die kompilierten Übersetzungen pro Sprachregion zur Verwendung zur Laufzeit speichern. LocRes-Dateien werden jedes Mal neu generiert, wenn der Lokalisierungs-Kompilierschritt ausgeführt wird, und werden in einem verpackten Build bereitgestellt. LocRes sind die einzigen Dateien, aus denen Ihr Projekt Lokalisierungsdaten zur Laufzeit lädt (einschließlich im Editor). Daher müssen alle Bearbeitungen oder Änderungen an Ihren Quell-Daten (z. B. durch den Import einer PO-Datei) kompiliert werden, bevor sie wirksam werden.
{TargetName}.locmeta	LocMeta-Dateien sind benutzerdefinierte binäre Dateien, die kompilierte Ziel-Metadaten (aktuell nur die primäre Sprachregion für das Ziel) für die Nutzung zur Laufzeit speichern. LocMeta-Dateien werden jedes Mal erneut generiert, wenn die Lokalisierungsdaten kompiliert und in einem verpackten Build bereitgestellt werden.

Lokalisierungsziele spezifizieren auch eine „primäre“ Sprachregion, die auf die Sprachregion festgelegt werden sollte, in der Sie Ihren Inhalt erstellen (üblicherweise als „Quelle“ oder „Quell-Daten“ bezeichnet).

Primäre Sprachregionen können wie alle anderen Sprachregionen „Übersetzungen“ enthalten, allerdings existieren primäre Sprachregionsübersetzungen nur, um das Redigieren Ihres Quelltexts zu erlauben, ohne den Quellcode oder die Assets direkt zu bearbeiten.

Fremde Sprachregionen verwenden den Text der primären Sprachregion als Quelltext für die Übersetzung und werden „veraltet“, wenn der Text der primären Sprachregion geändert wird (im Kompilierungsschritt der Lokalisierung gibt es eine Einstellung, um abgelaufene Übersetzungen bei Bedarf zu erlauben).

Weitere Informationen zur Optimierung Ihrer Lokalisierungspipeline finden Sie unter Pipeline-Optimierung.

PO-Dateiformat

Unreal verwendet das folgende Standardformat für seine PO-Dateien, abhängig vom Collapse-Modus, der beim PO-Export verwendet wird.

Bei Verwendung des Collapse-Modus Identical Text Identity and Source Text:
- msgctxt enthält die Unreal-Identität des Eintrags.
- msgid enthält den Quellstring.
- msgstr enthält die Übersetzung.
Bei Verwendung des Collapse-Modus Identical Namespace and Source Text:
- msgctxt enthält den Unreal-Namespace des Eintrags.
- msgid enthält den Quellstring.
- msgstr enthält die Übersetzung.

Wir haben auch ein alternatives Format, das bessere Ergebnisse liefert, wenn Sie Crowdin zur Verwaltung Ihrer Übersetzungen verwenden. Bitte beachten Sie aber, dass dieses Format nicht in der Lage ist, abgelaufene Übersetzungen zu erkennen, die aus PO-Dateien importiert wurden (da wir die Quelle der Übersetzung nicht mehr haben, gegen die sie durchgeführt wird).

Dieser Modus erzeugt den gleichen Output wie bei Verwendung der Collapse-Modi „Identischer Namespace“ und „Quelltext“. Beim Collapse-Modus „Identische Textidentität“ und „Quelltext“ erzeugt er jedoch Folgendes:

msgctxt wird nicht verwendet.
msgid enthält die Unreal-Identität des Eintrags.
msgstr enthält den Quellstring (für die primäre Sprachregion) oder die Übersetzung (für fremde Sprachregionen).
Das Header-Attribut X-Crowdin-SourceKey legt fest, dass msgstr als Quelle aus der primären Sprachregion verwendet wird.

Paketieren von Lokalisierungsdaten

Die Paketierung der korrekten Lokalisierungs- und Internationalisierungsdaten für Ihr Projekt erfordert die Anpassung einiger Einstellungen in der erweiterten Packaging-Sektion Ihrer Project Settings.

Die beiden Einstellungen, die Sie überprüfen sollten, sind:

Localizations to Package \– Hiermit können Sie wählen, für welche Sprachregionen Sie Lokalisierungsdaten bereitstellen möchten. Sie können die Option Show Localized verwenden, um die Liste zu filtern und nur Sprachregionen anzuzeigen, für die Sie LocRes-Dateien besitzen.
Internationalization Support \– Hiermit können Sie wählen, welchen Satz von ICU-Internationalisierungsdaten Sie bereitstellen möchten. Diese Option muss sich mit den Lokalisierungsdaten überschneiden, die Sie bereitstellen möchten.