UE5標準機能のローカライズに挑戦だ。

ローカライズ手順の備忘として、くりえめいくさんの動画のパク⋯、じゃなくて手順を文章化した備忘記事です。加えて「　くりえめいくさん　」では解説されていない実際に販売するゲームプロジェクトでローカライズを行ったときに困ったことや実際の運用での手順も解説します。

 

 

操作手順

1. ツール　→　ローカライゼーションダッシュボード　→　専用のウインドウが開く
   
2. カルチャーに日本語を追加（jaで検索）
   
3. ネイティブ言語を指定（自分の場合は英語ベースでゲームを作成したので、英語にチェックを入れる）（チェックを切り替えると翻訳データが全部消えるので注意）
4. 翻訳するテキストを収集する対象を決める　→　Include Path Wildcards　→　AutoからProjectに変更　→　パスをContentフォルダに指定
   (パスをContentに指定すると導入したアセットも含まれ大変なことになるので、あらかじめローカライズの対象に絞ったフォルダなどを作成して、それらを対象にすることをおすすめします。)
5. File Extensions　→　umapとuassetの2つのインデックスがあることを確認
6. 下のテキストを収集するデカいボタンを押す　→　テキストを収集　→　終わるとOKボタンが押せる　→　OK　（本番プロジェクトでは2016文字のテキストを収集しましたが、モノの1分もかからず収集が終わってしまいました。）
7. カルチャーの小さいボタン（このカルチャーの翻訳を編集）を押す　→　専用の翻訳入力ウインドウが開く
8. ウインドウに翻訳する対象と、翻訳後のテキストを入力する場所がある。さらに下にはコンテキストで翻訳のIDとどのファイルのコンテンツのテキストを指しているのかをパスで確認することができる
   
9. 翻訳を入力したら先程のローカライゼーションダッシュボードのテキストをコンパイルというデカいボタンを押す　→　終わったらOKが押せる　→　OKを押す
   
10. エディターを再起動（初回のみ）
    （一度コンパイルすると、以降はテキストの収集→翻訳→コンパイルをエディターの再起動なしに変更することができ、プレビューも行えます。）
11. UIなどの画面でローカライゼーションのプレビューが更新されていれば成功。
    （言語を切り替えると表示のテキストも切り替わる）
12. ゲーム内で言語を切り替える場合は「　Set Current Culture　」ノードに変更したい言語を「　ja　」などの形で指定して変更できる。
    
13. プレビュー実行したらエディターの言語が変わるぞ？
14. エディターで言語変更を確認するときは、「　スタンドアロンゲーム　」モードで起動してゲーム内で言語が切り替わるかを確認
15. パッケージ化したビルドの場合は別途プロジェクト設定　→　プロジェクト　→　パッケージ化　→　パッケージ化するローカライゼーションで対象の言語にチェックが入っていないと、ビルド実行時に言語が変わらないことに注意。

ローカライズ翻訳を入力していない文字は？

手順8番のウィンドウでローカライズの翻訳語を入力しなかった場合はどうなるのでしょうか？

正解は、ネイティブの言語が表示されるです。

翻訳がない、ということで空白が表示されてまずいことになるのでは？と思いましたが、その当たりは流石アンリアルエンジンといったところでしょうか？不自然にならないように、翻訳データのない単語はネイティブの言語をそのまま表示してくれます。これで文字が何も表示されないと言った不具合は起こらなそうです。

 

 

 

実際に本番プロジェクトでやってみたら・・・

余計なデータがごっそりあるやん

実際に惑星ゲームの本番プロジェクトで上記の手順でやってみました。

すると導入したアセットやローカライズしなくても良いボタンや記号など余計なデータが大量に存在してローカライズ作業を煩雑にすることが判明しました。

手順４でローカライズする対象をプロジェクト制作段階から厳格に管理して、ローカライズするもの、しないものをキッチリ分けておくと後で楽になると思いました。

ローカライズ対象を絞る（フォルダ）

くりえめいくさんの言うとおりに「　Content　」フォルダを指定すると、合計2016文字のテキストが収集されました。流石に余計なモノが多すぎて作業効率が激悪だったので、対象フォルダを絞りました。

自分の場合は、自分で作ったフォルダを「　MyData　」というフォルダに格納しているので「　MyData　」フォルダを指定しました。
またプレイヤーのインプットマッピングコンテクストもキーバインディングオプションで指定していたのでサードパーソンテンプレートが入ったフォルダも指定しました。

合計2個のフォルダを指定することで問題なく翻訳対象を絞って指定できました。

これでローカライズ対象は　2016　→　1202　個に半減しました。デカいですね。

ローカライズ対象を絞る（テキストのフラグ）

また記号や変数で動かす数値を表示するテキストなどは、ローカライズする必要がないので別途テキストのオプションのローカライズフラグアイコンからローカライズの対象外に設定しました。

この当たりはプロジェクト作業を進めるときから意識してローカライズ対象を除外する癖をつけたほうが後々困らないと感じました。

結局ローカライズ対象のテキストは、2016　→　1202　→　937　→　929　と最終調整して930個ぐらいに収束しました。

 

 

制作段階でのローカライズへの対応

ローカライズは基本ゲームが完成してから一番最後の作業になりますが、その作業自体はプロジェクト開始から意識した設計や操作が必要だと感じました。

今回の惑星ゲームは超小規模だったので、1日でローカライズまで終わりましたが、契約の浮遊船ではローカライズシステムが違うこともあり1か月もかかるという地獄を見ました。

ローカライズしないモノは制作時に設定する

1. アセット単位で不要なデータはローカライズ対象から外しておく（フォルダで隔離）
2. UIの記号やローカライズ不要な文字はローカライズ対象から外しておく（テキストフラグを調整）

 

UEのローカライズがメッチャ楽

Unityより遥かに楽なんだが？

今回UEのローカライズ作業が初めてということで、どれだけ苦労するのか？と身構えていたのですが、想像の5倍は簡単でした。

楽なポイント

1. 収集　→　翻訳　→　コンパイル　が何度もできて、登録済みのものは動かない
2. リストがABC順に並んでいるので探しやすい
3. 同じテキストでも参照元の違いを識別できる（手順８）
4. 翻訳の反映をプレビューしながら作業できる
5. 翻訳済み、翻訳前、更新されたモノ（要レビュー）で仕訳されて便利
6. 翻訳の進み具合が％で表示される

といった感じで標準機能にしてほぼ完璧なローカライズシステムだと感じました。これだけでもUnityに戻れないとじんわり感じているところです。