設計

ローカリゼーション

更新日時: 2025/01/13

アプリのローカリゼーションにより、テキストやボイスオーバーコンテンツを翻訳するだけでなく、意図した方法で楽しんでもらえるように設計要素をアップデートして、世界中のオーディエンスに届けることができます。このプロセスには時間とリソースが必要ですが、世界中の新たなオーディエンスにアプリを発見、購入してもらえる可能性が広がるため、実行することをおすすめします。

ローカリゼーションを考慮したアプリの計画および設計方法

ローカリゼーションの時間とリソースを節約するため、アプリがいずれ翻訳され、より広いオーディエンスと共有されるということを念頭に置いて設計と構築に取り組みましょう。アルファ版ビルド前の計画と開発におけるベストプラクティスを、以下にご紹介します。

文字列ファイルを準備する

ローカリゼーションにはバイリンガルのファイル指向プロセスが必要なため、このプロセスを効率良く成功させるには文字列ファイルが非常に重要です。この文字列ファイルに、ローカライズされるコンテンツを構成する、すべてのアプリ内コンテンツの文字列を含める必要があります。計画と構築における効率を最大化するには、以下のポイントが重要です。

ローカリゼーションの計画と実行を担当する窓口として、チーム内の1人を割り当てます。

すべてのアプリ内コンテンツに対して1つのマスターファイルを利用します。

文字列を外部化して翻訳用に準備します。テキストをハードコーディングしないようにします。

文字列ファイルがローカリゼーションツールに対応していることを確認します。XLS、PO、JSON、XML、CSVは業界標準として幅広く受け入れられています。

同じソーステキストがアプリの異なる領域で使用されていても、文字列ごとにユニークな文字列ID/キーを割り当てます。これにより、1つの単語を複数の言語に翻訳する際のプロセスが効率化され、異なるテキストレイアウトが必要な場合の柔軟性が高まります。

文字列IDを静的なものにし、エクスポートプロセス中に変更されないようにします。新しい文字列IDにはローカリゼーションツールによってフラグが設定されてレビューされるので、余計な作業と追加の翻訳コストが必要になります。

文字列内で特定のプラットフォームに言及しないようにします。必要に応じて、プラットフォーム固有のすべてのテキスト部分に可変文字列を追加し、この内容を適宜変更、削除します。

ローカリゼーションプロセスに固有の開発者ノートを追加して、言語の専門家が各セクションを正確に翻訳できるようにします。テキスト/文字列の目的に関するコンテキストの提供、品詞(動詞、名詞など)の明確化、特定のシーンにおける話し手の明確化、複雑な言い回しや駄じゃれが使用されている場合の強調などを処理します。

ローカリゼーション用に書式設定されたXLSファイルの例については、以下をご覧ください。

string_ID	英語	開発者ノート
mainmenu_start_button	START	ゲームを開始するためのUIボタン
mainmenu_credits_button	CREDITS	ゲームのクレジットを見るためのメインメニュー
scene_1_cutscene_char1_1	Hey, wake up!	ダイアログ。文字数上限: 15
scene_2_objective_name_record	Record	動詞。目的の名称: ボイスレコーダーで会話を録音する

ローカリゼーション対応UIの構築

柔軟性が高く、サイズ変更が簡単なUIを設計し開発すると、ローカリゼーションプロセスの時間を大幅に節約できます。英語と比較すると、ほかの多くの言語では、文や単語の見た目の長さが2～3倍長くなる傾向があります。また一部の言語では、追加のアクセント記号やストローク文字に合わせるために少し縦幅の大きいレイアウトが必要です。UIをローカリゼーション対応にする詳しい方法については、以下を参照してください。

応答性の高いレイアウトにより、さまざまな言語の文字タイプに応じた変更に対応できるようにします。これには、テキストボックス、ボタン、テキストの自動サイズ変更が含まれます。

行送りの課題の解決策として、水平方向にスクロールできるティッカーテープボックスをサポートします。

改行タグと改行なしタグについて、翻訳ファイル内でリッチテキストタグを統一します(<br>、<nbsp>など)。これにより、特に各単語間の間隔が非常に狭い言語で、行送りのためのローカリゼーションプロセスの効率が上がります。

より効率的にローカリゼーションプロセスを計画するために、レイアウト内のベイク処理されたテキストを含むすべてのビジュアルアセットを文書化します。

レイアウトのスペースに特定の文字数しか収まらない場合、アプリのそのセクションの最大文字数を開発者ノートに記録するようにします。

ローカリゼーションプロセスを開始する前に、必ず文字列の全体レビューを行ってください。ローカリゼーションプロセスをさらに最適化するために、翻訳する必要がない使われなくなった文字列を削除し、タイプミス、文法、句読点の誤りを修正します。

1つの言語が世界中の複数の地域で使われている場合があるため、国旗を使って言語を表すことは避けてください。

アプリ内の言語サポートの管理

Questアプリは 25の言語⁠に対応していますが、特定の言語にターゲットを絞ることも可能です。アプリ内言語とユーザーのデバイス言語でロケールが一致する場合は、アプリ内言語はユーザーのデバイス言語で提供してください。Meta QuestプラットフォームSDKまたはネイティブAndroidメソッドを使用して、実行時にロケールオブジェクトを検出し、そのオブジェクトに基づいて、特定のユーザーに送信されるアプリのローカライズバージョンを決定します。ユーザーロケールを取得する方法については、ユーザーロケールの取得のドキュメントページをご覧ください。

ただし、ユーザーが好みの言語を選択できるように、アプリ内にカスタムの言語選択機能を用意することを強くおすすめします。ユーザーのデバイス言語をサポートしていないアプリは、デフォルトで英語で読み込まれるようにしなければなりません。留意すべきその他の要件については、Questバーチャルリアリティチェック(VRC)ガイドラインを確認してください。

ローカリゼーションファイルを管理する際に、言語パックの使用も必ず検討してください。これを使用するとインストールアプリのサイズを減らすことができます。

国際言語対応のフォント

多くのゲームエンジンやフレームワークは、デフォルトでは非ラテン文字を正しくレンダリングせず、ブロックとして表示します(一般的に「豆腐」と呼ばれています)。非ラテン言語をレンダリングするには、該当言語のフォントを含める必要があります。

UnityのデフォルトフォントLiberation Sansで表示された韓国語のテキスト。Liberation Sansには韓国語のグリフがないため、正方形のブロックとしてレンダリングされています。

韓国語のグリフをサポートするNoto-Sansフォントで正しく表示された韓国語のテキスト。

ローカライズされたコンテンツがアプリの確立された外観および雰囲気とマッチするように、オリジナル版のスタイルに合ったフォントを調べて実装します。多数のフォントが無料で利用できるほか、商業目的で利用可能なライセンス付きのフォントもあります。

Unity: Unityにフォントファイルをインポートして、Text Mesh Proアセットを作成します。デフォルトでは、Atlas生成モードはダイナミックに設定されています。各グリフは実行時に生成されるため、テクスチャーのサイズが大きいことは心配する必要はありません。例えば、中国語や日本語のように画数やバリエーションが多いアジア言語の静止テクスチャー画像を使う場合、サイズが数百メガバイトを超えることもありますが、ダイナミックテクスチャーを使えば、テクスチャーのサイズを10KBほどに減らすことができます。

静止テクスチャーを使う場合、何千もの文字があるマルチバイト言語について、可能性のあるすべての文字を画像に含めることは非現実的です。そのため、最も一般的な方法として、テキストをスキャンして文字列ファイル内に含まれる文字のライブラリを作成し、それらの文字のみを含む画像を生成します。

Unrealおよびその他のサードパーティエンジン: ほとんどのゲームエンジンでは、テキスト出力方法が完全なカスタムプロセスである傾向があります。柔軟に対応し、サポートされるフォントを多数提供するようにしてください。

新しいフォントをテストするには、ランダムに翻訳されたテキストのブロックを使用してビルドをデプロイします。多くのフォントはアジア言語やキリル言語に対応していないため、ターゲットとなる市場でこれらの言語が一般的な場合は、必ずこれらの言語でアプリをテストするようにします。サポートされていないグリフ(文字)は、テストビルドをデプロイしても表示されないか、単に四角として表示される可能性があることに注意してください。

ローカリゼーションプロセスを実行する

アプリのローカリゼーションを進める際に、以下のベストプラクティスに従うことで、円滑で効率的なローカリゼーションプロセスを実現できます。

リリースパイプラインにローカリゼーションを追加し、それに応じて計画を練る。単語数やテスト、バグの複雑さによってはアプリの翻訳やテストに数週間または数か月かかることがあります。作業開始前にコンテンツがロックされていれば、ローカライゼーションチームは正確なタイムラインとコストの見積もりを提示することができ、比較的シンプルでわずらわしさもなく作業を進めることができます。これは、最初に英語でリリースしてからローカライズバージョンでリリースする場合でも、アプリを複数言語で同時に公開する場合(別名: 世界同時発売)でも同じです。

ローカリゼーションプロセスを構成するステップの概要については、以下をご覧ください。

文字列ファイルのロック

アプリ内コンテンツとストアコンテンツの翻訳

翻訳したコンテンツのレビューとテスト

ローカリゼーションの問題と不具合の修正

ストア承認の申請

バージョン管理および変更管理

アプリのアップデートやバグ修正などは避けられないものの、ローカリゼーションを始める前にコンテンツをロック(例: 文字列ロック)し、ローカリゼーションが終わってから変更を加えるようにしましょう。ローカリゼーション中に設計/ビルドの変更が必要な場合は、バージョン管理が非常に重要になります。ローカリゼーションプロセスに次から次へとアップデートが追加されると、コミュニケーションやビルド管理が特に困難になる可能性があるためです。

アプリ内コンテンツの翻訳: 文字列ロックの重要性

ローカリゼーションを開始するには、翻訳対象のすべての文字列を単一の文字列ファイルにまとめます。これを翻訳チーム(社内チームか社外のサービスプロバイダーかに関係なく)に送信する際には、ローカリゼーションの初期段階が完了するまでロックしておくようにします。ローカリゼーションの開始後に文字列に変更を加えた場合は、アップデートされた文字列ファイルを送信して翻訳チームにこれらの追加変更を依頼する必要があり、余計な作業とコストが増えることになります。また、QAチームに変更が通知されていなかった場合や、古くなったビルドのテストが完了していた場合に、テストプロセスをさらに混乱させることになります。そのため、文字列ロックを実行することを強くおすすめします。

Meta Horizonストアのコンテンツの翻訳とアップロード

Meta Horizon開発者ダッシュボードでは、一括ローカリゼーションを簡単にするためにTSVファイルのインポートとエクスポートがサポートされています。英語ストアのメタデータを入力したら、[Bulk Localization (一括ローカリゼーション)]をクリックして、ストアコンテンツをローカライズするための推奨ステップを実行します。その後、ポップアップモーダルの[Download TSV (TSVをダウンロード)]をクリックしてTSVファイルをエクスポートし、翻訳チームに送信することができます。

Bulk localization overlay within Developer Dashboard

必要なMeta Horizonストアのメタデータについては、以下をご覧ください。

アプリ名: 最大40文字

アプリの簡単な説明: 最大500文字

アプリの詳細な説明: 最大1,000文字

検索キーワード: キーワードごとに最大50文字で、最大5つのキーワード(任意だが推奨)。キーワード内ではスペースは使用できません。

キーワードの構築方法に関するヒントは、アプリ名とアセットのベストプラクティスとストア申請の成功に関するガイドを確認してください

注: アプリ名のローカリゼーションとそれが推奨される理由

アプリ名をローカライズすることで、アプリの外観と雰囲気が海外のユーザーにとって身近に感じられるようになります。西欧諸国のユーザーは英語の習熟度が高い傾向がありますが、東洋諸国のユーザーは一定のタイトルの意図された意味を理解できないという傾向が見られ、中には読み取りに苦労する人もいます。ローカライズされたアプリ名を使うことで、アプリがより多くのオーディエンスにとって魅力的に映るようになります。

注目すべき点は、大多数の映画スタジオが映画のタイトルを翻訳または音訳しているということです。音訳とは、文字を1つのアルファベットから音の似たアルファベットに変換することを意味します。例えば、ヘブライ語のחנוכהは英語のHanukkahまたはChanukahに音訳されます。元々英語で開発されたアプリでは、東洋の言語をターゲットにする場合は音訳されたアプリタイトルが好まれることが多く、西洋の言語の場合は英語の習熟度が高いため元の英語のタイトルが推奨される傾向があります。これらの地域で新たなIPを展開する際は、ローカリゼーションチームの提案を参考にマーケティング方法を決めるようにしましょう。アジア言語の非ローカライズタイトルについては、アプリマネージャにアプリの検索キーワードとしてアプリ名の音訳を追加して、それが検索結果に表示されるようにします。

ローカライズしたコンテンツのレビューとテスト

翻訳チームは英語のソーステキストと開発者ノートを頼りに最も正確な翻訳になるようにしますが、通常、翻訳担当者はアプリの完全なエクスペリエンス(UI設計、物語のコンテキストなど)を目にすることはできないため限界があります。翻訳チームが文字列ファイル内の各文字列のつながりを理解するのが困難である可能性があり、翻訳が意図したとおりに表示されない、特殊文字のサポートがない、翻訳されたテキストがUIに重なっているなどの不具合がこのプロセスで生じる可能性があります。ここでローカリゼーションに特化した品質保証テストが必要になります。よくローカリゼーション品質保証(LQA)と呼ばれるこのプロセスには、従来、ローカライズされたビルドをレビューする専門的なバイリンガルQAテスターが含められ、これによって、このようなアップデートを改善し、ローカリゼーション固有の問題をより効率的に修正できるようになります。

LQAテストで見つかる一般的なUIの不具合に関しては、以下をご覧ください。

LQAテストの準備をするには、翻訳チームと共有したほかのすべての資料と一緒に、翻訳済み文字列ファイルをLQAチームと共有します。最新の翻訳を実装した新しいビルドをデプロイし、LQAチームをビルドチャネルに追加します。LQAテスト計画に、ローカリゼーションが重視されるアプリ要素をテストするための最も効率の良い行程を含めてください。例えば、ローカリゼーションプロセスの影響を受けない特定の領域はスキップするように指示して、翻訳が重視されるアップデートを含む領域がすべてトリガーされるようにします。また、デバッグツールを提供して、ローカライズされた設計の変更や翻訳済みテキストがないアプリのセクションをテスターがスキップできるようにします。

LQAフェーズの最後に、ローカリゼーションの不具合を解決した新しいビルドをデプロイし、LQAチームにこれらのアップデートを検証してもらいます。ローカライズした新しいビルドの重大な不具合が解決され、LQAチームがその全体的な質を承認するまでこのプロセスを繰り返し、その後、ストア承認に向けてアプリを提出する準備をします。