Unreal Engine でのローカライゼーションの概要 | Unreal Engine 5.7 ドキュメンテーション

ローカライゼーションと国際化

ローカライゼーションと国際化 (L10N と I18N) の 2 つの概念は、「ローカライゼーション」の文脈で組み合わせて用いられることが多くあります。しかし、これらは別個のものであり、Unreal Engine (UE) ではそれぞれ異なる方法で処理されます。 UE のローカライゼーションシステムは「テキスト」タイプを中心としているのに対し、国際化サポートは International Components for Unicode (ICU) ライブラリを使用しています。

これらは独立に機能していますが、UE では適切な国際化サポートがなければ、実行時にローカライズできません。

ICU と国際化サポート

ICU は長い間使用されてきた頑健な国際化ライブラリであり、UE は以下のようなカルチャ固有のデータや処理を扱うために使用します。

プラットフォーム / OS の現在のカルチャを取得します。
カルチャのフォールバックの優先順位を処理します。
カルチャに合った正確なフォーマットの数 (パーセンテージと通貨を含む)、日時 (タイムゾーンデータを含む) を処理します。
カルチャに合った正確な複数形のフォーマットの数 (テキストフォーマット化の間) を処理します。
Unicode に準拠したテキストの変換 (ToUpper、ToLowerなど) を処理します。
Unicode に準拠したテキストの比較と照合を行います。
Unicode 準拠の境界値分析 (文字、単語、改行) を行います。
Unicode 準拠の双方向 (BiDi) テキスト検出を行います。

ICU が使用するカルチャ固有のデータは、ICU の外部に格納され、UE は大まかなデータセットを提供して、プロジェクトサイズを最小化しています。

英語 (~1.77MB)
EFIGS - 英語、フランス語、イタリア語、ドイツ語、スペイン語 (~2.38MB)
EFIGSCJK - 英語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語 (~5.99MB)
CJK - 中国語、日本語、韓国語 (~5.16MB)
すべての言語 (~15.3MB)

どちらを選択するかは、プロジェクトをローカライズする地域によって異なるので、[Project Settings] で設定します。詳細は、「Packaging Localization Data」を参照してください。

カルチャ

UE のカルチャには、特定のロケールの国際化情報が含まれています。カルチャ名は、次の 3 つのハイフンで区切られた部分で構成されます (IETF 言語タグ)。

2 文字の ISO 639-1 言語コード (「zh」など)。
オプションの 4 文字の ISO 15924 スクリプトコード (「Hans」など)。
オプションの 2 文字の ISO 3166-1 国コード (「CN」など)。

UE4 は、特定の文化のローカライゼーションデータを検索するときに、特定されたデータから順に処理を行います。例：

zh-Hans-CN は、「zh-Hans-CN」、そして「zh-CN」、「zh-Hans」、「zh」の順に処理されます。
en-GB は、「en-GB」、そして「en」の順に処理されます。

特定のカルチャを広範囲にカバーするには、最も具体的でない有効なカルチャコードを使用します。通常は言語コードだけですが、地域によって言語が異なる場合があることに留意する必要があります。

ほとんどの場合、地域による違いは特定の国コードに限定されているため、簡単に解決できます。ただし、以下に示すように、より複雑なケースもあります。

中国語

中国語には簡体字と繁体字の 2 種類があり、「Hans」と「Hant」の ISO-15924 スクリプトコードで表されます。簡体字ローカライズは「zh-Hans」を、繁体字のローカライズには、「zh-Hant」を使用します。

スペイン語

スペイン語には、ヨーロッパ系とラテンアメリカ系の 2 つの主要な変種があります。しかし、その両方を簡単に区別することができるスクリプトコードはありません。ラテンアメリカのスペイン語用の IETF 言語タグ (「es-419」) は、ほとんどのプラットフォームでサポートされていないか、代わりに実際の国コード (「es-MX」) を使用します。

これを解決するには、ヨーロッパ系スペイン語には「es」を、ラテンアメリカ系スペイン語には「es-419」を使用します。次に、UE4 のカルチャ再マッピング機能を使って、ラテンアメリカのスペイン語圏を「es-419」にマッピングします。

これを行うには、DefaultGame.ini に以下のコードを追加します。

	[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"

ローカライゼーションターゲット

ローカライゼーションターゲット とは、ローカライゼーションデータの自己完結型モジュールのことです。ローカライゼーションターゲットには、以下のプロパティがあります。

指定されたソースからテキストを収集します。
マニフェストファイルに保存されています。
カルチャ固有のアーカイブファイルに変換されます。
カルチャ固有のローカライゼーションリソースファイルにコンパイルされ、コンパイルされたリソースファイルがシステムに表示されます。

プロジェクトを単純化するために単一のローカライゼーションターゲットを持つことも、複数のローカライゼーションターゲットを持ちながらプロジェクトのローカライゼーションデータをセクションに分割することもできます。 Unreal Editor には、UE の他の部分とは別のローカライゼーションターゲットがあるため、ゲームでローカライゼーションデータを配布することなく、エディタをローカライズできます。通常、ゲームには、ベースプロジェクトのすべてのローカライゼーションデータに対して 1 つのローカライゼーションターゲットがあり、拡張された部分に対しては、追加のローカライゼーションターゲットを作成します。

ローカライゼーションパイプライン

UE ローカライゼーションパイプラインは、「author-at-source」アプローチに準拠してローカライズします。つまり、UI で「Hello World!」というテキストが必要な場合には、テキストプロパティ (C++ の NSLOCTEXT もしくは、 LOCTEXT マクロを使用) に「Hello World!」と入力するだけで、ローカライズ収集ツールがテキストをキャプチャしてローカライズできるようにします。

「author-at-source」アプローチのダイナミックな機能により、デベロッパーはローカライズについて深く考えることなく開発を進めることができるようになります。しかし、プロジェクトで使われているテキストを厳密に管理したいと思っているチームにとっては、ストレスになることもあります。これに対処するために、UE は文字列テーブルをサポートし、「author-once-and-reference」アプローチに準拠したローカライズを可能としています (ただしパイプラインは、内部的に文字列テーブルを別の「author-at-source」として扱うだけです)。

ネイティブ文字列テーブルに対応していない時代の旧メソッド (現在はサポートされていません) では、ソーステキストとして ID 付きの「フェイク」ネイティブカルチャ (「es-US-POSIX」) を使用し、バージョン 4.14 より前に UE で提供された文字列統合関数を使用して、これらの ID を各言語に変換していました。サポートに関する古い質問には、この方法への参照が記載されている場合がありますが、この方法は現在使用されていません。このメソッドを使用しているプロジェクトは、文字列テーブルに移行する必要があります。

ローカライゼーションパイプラインは、ローカライゼーションターゲットを処理し、ローカライゼーションターゲットはコンフィギュレーション (Config/Localization/ に保存) とデータ (Content/Localization/{TargetName}/ に保存) の 2 つから構成されます。

ローカライゼーションターゲットが英語 (「en」) とフランス語 (「fr」) であると仮定すると、Content/Localization/ フォルダ内のレイアウトは以下のようになります。

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

上記のすべてのファイルとフォルダは、ローカライゼーションパイプラインのさまざまな部分で生成されます。

フォルダ	説明
{TargetName}.manifest	Manifests は、ローカライゼーションパイプラインがソースコードとアセットから収集されたすべてのテキストを保存するカスタム JSON ファイルです。 Manifests は、ローカライゼーション収集ステップが実行されるたびに再生成されるため、手動での編集はしないでください。
{TargetName}.archive	Archive は、manifest に収集されたテキストのカルチャ別翻訳を保存するカスタム JSON ファイルです。 Archive は、ローカライゼーションの収集またはインポートのステップが実行されるたびに削除され、古いソースのエントリは削除されます。 Archive は、手動で編集できますが、お勧めはしません。エクスポートされた PO ファイルを編集して、再インポートするワークフローを推奨します。
{TargetName}.po	PO (Portable Object) ファイルには、現在の翻訳とともに翻訳されるカルチャ別テキストが含まれています。 PO ファイルはローカライゼーションエクスポートテキストステップで生成され、ローカライゼーションインポートテキストステップでアーカイブに再インポートされます。 PO は一般的なフォーマットであり、ローカルでは手動で編集ができ、あるいは Poedit のような翻訳ツールや、協調的には OneSky や XLOC のようなものを介して編集することもできます。
{TargetName}.locres	LocRes はカスタムバイナリで、実行時に使用するようにコンパイルされた各カルチャの翻訳を保存します。 LocMeta ファイルはローカライゼーションデータがコンパイルされるたびに再生成され、パッケージビルドにステージングされます。 LocRes は、プロジェクトが実行時 (エディタでの実行も含めて) にローカライゼーションデータをロードする唯一のファイルなので、ソースデータの編集や変更 (例えば、PO ファイルのインポート) が有効になる前にコンパイルする必要があります。
{TargetName}.locmeta	LocMeta は、実行時に使用するためにコンパイルされたターゲットメタデータ (現在はターゲットのネイティブカルチャのみ) を保存するカスタムバイナリファイルです。 LocMeta ファイルはローカライゼーションデータがコンパイルされるたびに再生成され、パッケージビルドにステージングされます。

ローカライゼーションターゲットは、「ネイティブ」カルチャを指定することもでき、コンテンツを作成したカルチャ (通常は「ソーステキスト」または「ソースデータ」と呼ばれます) に設定する必要があります。

ネイティブカルチャの翻訳は、ソースコードやアセットを直接編集せずにソーステキストのコピー編集を容易にする目的でのみ存在しますが、ネイティブカルチャには他のカルチャと同様に「翻訳」を含めることができます。

外国語カルチャは、ネイティブカルチャを翻訳のソーステキストとして使用し、ネイティブカルチャテキストが変更されると、「stale」の状態になります (ローカライゼーションのコンパイル手順で、必要に応じて古い翻訳を許可する設定があります）。

ローカライゼーションパイプラインの最適化の詳細については、パイプラインの最適化を参照してください。

PO ファイル形式

Unreal P0 ファイルは、次のデフォルト形式を使用します (P0 エクスポートの折りたたみモードによって異なります)。

同一のテキスト ID とソーステキスト 折りたたみモードを使用する場合:
- msgctxt はエントリの Unreal ID を含む。
- msgid はソース文字列を含む。
- msgstr は翻訳を含む。
同一の名前空間とソーステキスト 折りたたみモードを使用する場合:
- msgctxt はエントリの Unreal 名前空間を含む。
- msgid はソース文字列を含む。
- msgstr は翻訳を含む。

Crowdin を使用して翻訳を管理する場合は、より良い結果を生成する代替形式もありますが、この形式では PO ファイルからインポートされた古い翻訳を検出できないことに注意してください (翻訳のソースがなくなったため)。

このモードでは、同一の名前空間とソーステキストの折りたたみモードを使用した場合と同じ出力が生成されますが、同一のテキストの ID とソーステキストの折りたたみモードでは、次のように生成されます。

msgctxt は使用されない。
msgid はエントリの Unreal ID を含む。
msgstr はソース文字列 (ネイティブカルチャの場合) または翻訳 (自国以外のカルチャの場合) を含む。
X-Crowdin-SourceKey ヘッダー属性は、 msgstr がネイティブカルチャからのソーステキストとして使用されることを指定します。

ローカライゼーションデータをパッケージ化する

プロジェクトに適したローカライズと国際化データをパッケージ化するには、[Project Settings] の [Packaging] セクションの下にあるいくつかの設定を調整する必要があります。

確認する 2 つの設定は次のとおりです。

Localizations to Package - これを使用すると、ローカライゼーションデータをステージングする対象のカルチャを選択できます。 [Show Localized] オプションを使用して、LocRes ファイルがあるカルチャのみを表示するようにリストをフィルタリングすることができます。
Internationalization Support - これを使用すると、どの ICU 国際化データセットをステージングするかを選択できます。このオプションは、ステージングするローカライゼーションデータと一致する必要があります。

Can't find any content