UDN
Search public documentation:

LocalizedTextFilesJP
English Translation
中国翻译
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

Unreal Engine でのテキストのローカライズ

ドキュメント概要: ローカライズされたテキスト (.INT など) ファイルを介して Unreal Engine でテキストをローカライズする方法。

ドキュメントの変更ログ: Josh Adams により作成、Richard Nalezynski? により移植、管理。

概観

任意の言語でテキストを表示するのに、Unreal Engine はローカライズされたテキスト ファイルに依存します。

設定は、セクション内に配置されたキーと値の組によって決定されます。任意のキーに対して、1 つ以上の値を関連付けることができます。

言語は、ゲーム プロジェクトの Engine 設定ファイルの Language (言語) 変数を特定の言語に設定することにより変更することができます。この特定の言語は、ローカリゼーション ディレクトリに関連付けられています。

例えば、以下のようにして言語を日本語に設定します。

[Engine.Engine]
...
Language=jpn
...

UnrealLoc

UnrealLoc ツールは、エンジン内のローカライズされたテキストを管理するために書かれており、より日常のタスクを処理します。

ローカライズされたテキスト ファイルでの作業

UE3 でのローカリゼーションは、\Localization ディレクトリとそのサブディレクトリにある一連のローカライズされたテキスト ファイルで処理されます。各言語は、それぞれ 3 文字のコード (JPN = 日本語、KOR = 韓国語、CHT = 中国語、DEU = ドイツ語など) を持っており、その言語のファイルを含んでいるサブディレクトリに対応しています。いくつかのコード、特に ESM や ESN は明瞭でないように見えるかもしれませんが、これらはそれぞれラテンアメリカのスペイン語とヨーロッパのスペイン語に言及しています。デフォルトの英語ビルドでさえ、ローカリゼーション ファイルを使用するべきであり、これは (インターナショナルの) INT という文字コードを使用しています (英語には ENG が使用されることもあります)。

ファイル形式

ローカライズされたテキスト ファイル自身は、単純に INI スタイルの設定ファイルですが、Unicode (UTF-16 リトルエンディアン) で保存されるべきであり、エンジンに対応する部分から継承しては いけません 。ファイル名自身は、ローカライズされたデータが属するパッケージと同じであり、拡張子は、Localization ディレクトリ内で存在するファイルがあるディレクトリと同じです。

セクション、そしてキーと値の組

通常の設定ファイルは、以下のように配置されたキーと値の組のセクションから成り立っています。

[Section]
Key=Value

例えば、MyGame.u というスクリプト パッケージがある場合、MyGame.u 内のスクリプト クラスのデフォルトのローカライズされた文字列のすべてを含む MyGame.int があるはずです。従って、ローカライズされた文字列プロパティである CheckpointReachedStringLoadingString を持つ MyHUD.uc というスクリプト クラスがある場合は、MyGame.int のセクションの 1 つは以下のようになります。

[MyHUD]
CheckpointReachedString=Checkpoint Reached
LoadingString=Loading

このセクションに関して覚えておかなければいけないことは、手動で作成されなければいけないということです。UnrealScript は、ローカライズ可能なプロパティのデフォルト文字列を UnrealScript クラスの defaultproperties セクションで指定することができません。試してみると、スクリプト コンパイルが失敗するでしょう。これは、翻訳されなければいけない文字列に気付き、できる限りすぐにローカライズされたテキスト ファイルに入れることができるので、実際は良いことです。

文字列データ

データの一部であるローカライズされた文字列とマップ パッケージは、似たように動作しますが、重要な差があります。これらのパッケージにローカライズされたテキスト ファイルを手動で作成することができますが、通常はパッケージの Generic ブラウザ内のパッケージ ツリー ビューにあるコンテキスト メニューから Full Loc Export... コマンドを実行するほうがより良いです。これは、パッケージごとに必要なテキストともにローカライズされたテキスト ファイルを自動生成します。

プロパティ ウィンドウに入力するものは、次にパッケージ/マップを読み込んだ際に、すべて INT コンテンツに上書きされるので気をつけてください。エディタ セッションを終了する前に、ローカリゼーション ファイルを再エクスポートする必要があります。

オブジェクトごとの文字列データ

上記の MyHUD の例は、クラスの複数のインスタンスが存在するとしても、 CheckpointReachedStringLoadingString プロパティに 1 つの文字列しか使用されていないことを仮定しています。異なるデザイナーに指定されたローカライズ可能なテキストを各インスタンスに持つことが必要なクラスを作成したらどうなるでしょうか? 例えば、武器をビルドするのにアーキタイプをシステムとして使用すると、それぞれはローカライズされた名前と説明を必要とします。この場合、ローカライズ可能な文字列プロパティを持つクラスは、その定義内で perobjectconfig としてマークされなければいけません。これをすることにより、そのクラスのオブジェクトを含むパッケージ上での Full Loc Export... の実行が、クラスの各インスタンスの個々の文字列を出力するようになります。従って例えば、SpokenText フィールドがそれぞれ埋められているような 3 つの WAV ファイル (WAV1、WAV2、WAV3) が入った VO.upk と呼ばれるパッケージがある場合、そこで Full Loc Export... を実行すると、これらのセクションを持つ VO.int と呼ばれるローカライズされたテキスト ファイルを生成します。

[WAV1 SoundNodeWave]
SpokenText="<WAV1 Text, whatever that may be>"

[WAV2 SoundNodeWave]
SpokenText="<WAV2 Text, whatever that may be>"

[WAV3 SoundNodeWave]
SpokenText="<WAV3 Text, whatever that may be>"

セクション名がリソース名とそのクラスの両方を含んでいることに注目してください。VO.int というファイル名に加えて、これは VO.upk 内のローカライズされた文字列のすべてに明確に対応するべきです。

UIStrings での折り返しと新しい行

ローカライズされたテキスト ファイルを手動で編集する際に、UI Strings での折り返しや新しい行の問題に直面するかも知れません。

例えば、以下は…

[GenericStrings]
Output="Line 1/nLine2/nLine 3"

以下を返します。

Line 1ine2ine3

UI エディタ DataStore ブラウザで文字列をプレビューしても同様です。

しかしながら、UI エディタ DataStore ブラウザで 1 つのローカライズされた文字列を変更し、その変更を適用すると、影響を受ける INT ファイル全体の文字列を囲むいかなるクォーテーション マークをも自動的に削除してしまうように見えます。これは、エスケープ キャラクターが期待通りに動作する原因となります。

ソリューション: テキスト エディタを使用して、手動でローカライズされた文字列を INT ファイルに入力する場合は、クォーテーション マークを使用するのをやめましょう。

以下が、適切な宣言です。

[GenericStrings]

Output=Line 1/nLine2/nLine 3

すると、以下のようになります。

Line 1
Line 2
Line 3

バイナリ データ

バイナリ データに関しては、ローカリゼーションは、対象言語の 3 文字コードを使用する付属の拡張子を持つ異なるパッケージを使用するだけです。従って例えば、ローカライズされる必要のあるテクスチャを持った Art.upk と呼ばれるパッケージがあったとします。現在実行している言語が日本語である (Engine.ini で指定されています) 場合は、エンジンはテクスチャを探すために、Art.upk でそれを検索する前に、自動的に Art_jpn.upk と呼ばれるパッケージを検索します。これは、シークフリー パッケージに正しいローカライズされたデータを入れるために、各言語で 1 つのクックを行う必要がある場合があるので、コンソール クッキング プロセスに影響を与えます。

別のテキスト ファイルにローカリゼーション データを持つ利点としては、コンテンツの再保存の必要なしに、データが素早くイテレートされ、ゲーム内でプレビューされることです。この利点は、コンテンツの変更によって何らかの クッキング ステップが必要となるようなコンソールでは特に明白です。

ローカライズされたテキスト ファイル データの宣言

クラス宣言は、ローカライズされたテキスト ファイルの新しいセクション名を説明します。 localized キーワードを含むすべての文字列はエクスポート可能であり、従って関連付けられたローカライズされたテキスト ファイル内にあります。

例えば、以下の例のクラスは、その文字列が MyGame.int ローカライズ テキスト ファイルにエクスポートされるように宣言します。

class MyHUD extends HUD
   var localized string CheckpointReachedString;
   var localized string LoadingString;

ローカライズされた文字列に関するより詳細な情報は、UnrealScript 言語リファレンスを参照してください。

利用可能なローカライズされたテキスト ファイル

ローカライズされたテキスト ファイルは、任意のプロジェクトの Localization ディレクトリ内の言語に固有のサブディレクトリにあります。

以下は、Unreal Engine を使用する任意のプロジェクトで利用可能なローカライズされたテキスト ファイルのリストです。

  • .int (プロジェクト名)
  • Editor.int (プロジェクトでエディタ変更がある場合)
  • UI.int (UI 用)
  • Content.int (バイナリ コンテンツ用)
  • Credits.int (クレジット用)
  • Subtitles.int (字幕用)