UE4 でローカリゼーション対応のゲームを作ることは、ラッキーなことにとても簡単です。基本的なルールをたった 1 つ守るだけで OK です。そのルールとは、
ユーザーに表示する値は、String ではなくすべて Text を使用する
ということです。
Text は、アンリアル・エンジン 4 に導入された新たな基本データ型です。これは、ゲームのための国際化とローカリゼーションを扱うものであり、同時に、そのすべてを抽象化して簡明で最低限のパッケージに仕立てるためのものです。
ブループリントを作成している場合は、Text リテラルと変数をグラフとオブジェクトに使用してください。入力されたテキストは、エンジンによって自動的に検出され、抽出されて、翻訳のためにセットアップされます。
あなたがプログラマーならば、コードに表示用テキスト リテラルを入れる場合は必ず NSLOCTEXT マクロを使用しなければなりません。また、クラス/アセットを作成しているならば、FText UProperty を使用する必要があります。
FText TestHUDText = NSLOCTEXT( "Your Namespace", "Your Key", "Your Text" )
詳細については、このドキュメンテーションのページをご覧ください。
これだけです。
きっとあなたはこう考えていることでしょう。「すごい！これは簡単だ。でも何かやっかいなことがあるはずだ。ローカリゼーションとは普通難しいものだから」。ところが、やっかいごとは何もありません。でも、Text と String の値を変換してこのルールを回避しようとする方も出てくるでしょうね。
しかし残念ながら、それこそ問題が生じるかもしれません。String 型を Text 型に変換すると、その Text 型はカルチャー インバリアントとして扱われてしまいます。言い換えれば、翻訳されなくなります。ですから、表示用テキストを Text 型の値にまず入れることがものすごく大切になります。Text 型の値は、ダイレクトな String 型へのアクセスを抽象化するので、言語の調整をライブで行えるなどの素晴らしい機能が可能になるとともに、ローカリゼーションの安全な操作が保証されるようになります。
Text 型と String 型を相互に変換してもよい場合があります。ただし、特別な注意をもって行わなければ、ゲーム内で該当する部分のローカリゼーションが台無しになってしまう恐れがあります。Text 型を String 型に変換して付加的処理を実行することが許される典型的な例としては、通常、ユーザーによる入力が考えられます。その値がカルチャー インバリアントになることが保証されるからです。
もう一つ注意していただきたいことがあります。私たちは時間をかけてローカリゼーションと国際化のためのシステムを開発してきましたが、適切な型を使用するためにエンジンのあらゆる API を変換する作業が完全には終わっていません。この点に関してはエンジンを引き続き改善することによって、ユーザーのみなさんにベストプラクティスへの道を用意するつもりですので、どうか今しばらくご辛抱ください。
みなさんは、UE4 のローカリゼーションについてどうお考えですか？ぜひ意見をお聞きしたいです。フォーラムにいらしてください！