ローカライゼーションの概要

プロジェクトのローカライゼーションに関連する要素の概要。

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

ローカライゼーションと国際化 (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 のような翻訳ツールや、協調的には OneSkyXLOC のようなものを介して編集することもできます。

{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 国際化データセットをステージングするかを選択できます。 このオプションは、ステージングするローカライゼーション データと一致する必要があります。

Unreal Engine のドキュメントを改善するために協力をお願いします!どのような改善を望んでいるかご意見をお聞かせください。
調査に参加する
キャンセル