ゲームローカライズの最良の手法
Initial Draft by Richard Mark Honeywood, IGDA Loc SIG Co-Chair
st
February 1
, 2011
Second Draft by Jon Fung
st
February 1
, 2012
これはビデオゲームの翻訳、カルチャライズに関する“最良の手法”もしくは“ハウツー”についての初稿で
す。基本的に、この分野で何年もの経験を持つ方々からの提案をリスト化したものになります。新しく
この分野に入ってきた方にはこの仕事の概要を、より経験を積んだローカライズスタッフにも今後のプ
ロジェクトに活かせるようなヒントを与えることが出来れば幸いです。
Best Practices for Game Localization by Richard Honeywood, Jon Fung and Takuya “Tom” Shiraiwa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
1
2
目次
カルチャライズ
ゲームの”カルチャライズ”とは何か？
ゲームカルチャライズの各段階
上位４つの文化的な要因
カルチャライズの最良の手法
インターナショナライズ
ユーザーインターフェイス
構造
プログラミング
開発チームへのアドバイス
ローカライズ
ファミリアライズ
グロッサリーとスタイルガイドの制作
翻訳
ボイスオーバー収録
言語QA
マスターアップと作業完了
プロジェクトのプランニング
プリ・プロダクション
プロダクション
アルファ段階
ベータ / ローカライズ作業完了 / ゴールドマスター段階
付録１ – 最良の手法のリスト
付録２ - カルチャライズの例
付録３ – 文法的なトークンの例
付録４ – ローカライズスケジュールのサンプル
寄稿者一覧
3
カルチャライズ
[注: 以下のポイントは、２０１２年後半に発売予定のKate Edwards氏によるゲームのカルチャライズに
関するハンドブックからの抜粋です。]
ゲームの“カルチャライズ”とは何か？
カルチャライズとはローカライズの一歩先を行くもので、あるゲームの設定や決め事を根本的に調査
し、それらのクリエイティブな選択が世界中の多文化市場、および特定地域においても受け入れられう
るものかどうかを見極める作業です。ローカライズは翻訳を通してゲーマーがゲームのコンテンツを理
解するのを手助けするものに過ぎませんが、カルチャライズはより意味深いレベルでゲーマーがゲーム
のコンテンツに関わることを可能にします。逆に言えば、カルチャライズはゲームの環境内において違
和感を感じたり、時には不快に感じられるようなコンテンツのせいでゲーマーが疎外感を感じないよう
に保証する作業とも言えるでしょう。
文化的な過ちは、時にゲームデベロッパーやパブリッシャーにとって高価なものについてしまうことが
あります – 潜在的な収益を失うということだけでなく、ネガティブな広報活動、会社イメージに対する
ダメージ、対象国の政府との緊張した関係、など大きな影響が考えられます。最悪のケースでは、対象
国の政府からゲームの発売が禁止されるだけでなく、詰問や投獄を目的とした地元担当者の留置を含
む、より直接的なアクションが会社に対して取られる場合があります。
ゲームカルチャライズの各段階
Tローカライズの必要性はゲーム業界でよく知られていますが、カルチャライズの必要性はまだそれほど
認識されていません。カルチャライズとはある特定のタスクを言うのではなく、コンテンツを国際的に
通用するものにしようとする全般的な意思です。最も基本的な形式においては、コンテンツのカルチャ
ライズは以下の３つの段階と見ることができます:
受け身のカルチャライズ
: コンテンツをリリース可能なものにする。例えば、破壊的な内容は取り除
いてそのゲームがターゲット市場で存在できるようにする。
2. ローカライズ＆インターナショナライゼーション
: コンテンツを理解しやすいものにする。例えば、
“典型的な”ローカライズを施してゲームの内容が理解されるようにする。
3. 積極的なカルチャライズ
: コンテンツを意味深いものにする。例えば、内容の適合化を行い、対象地
域に特定のオプションを提供することにより、ゲームの内容が対象地域の人々にとってしっくりくる
ものにする。
これらのカルチャライズの段階の理解については、いくつかの補足が役に立つかもしれません。:
1.
●
●
●
ローカライズは大変重要ですが、翻訳を通して内容を理解しやすいものにするというプロセスは、他
の文化圏に向けてコンテンツを準備する上で必要とされるステップの一つに過ぎません。これはその
他あらゆるタイプのコンテンツ同様、ビデオゲームにとっても当てはまります。 ゲームを“リリース可能なもの”にする前に、“理解しやすいもの”にするべきだという議論があるかも
しれません。しかし、ゲームがローカライズされているかいないかに関わらず、問題のある内容が含
まれていれば政府によってゲームが規制されてしまう場合があるのです。 上述の各段階は序列を表しているわけではありません。ローカライズ同様、カルチャライズはゲーム
開発サイクルにおける様々な段階で発生するものであり、全体的な開発工程を通じて統合された様々
なタスクや優先事項の調整の結果です。 上位４つの文化的な要因
ゲームデザイナーが現実の文化的な世界観から外れて考えようとすればするほど、自分のいる場所以外
の地域で問題を引き起こすかもしれない問題について気がつくことは難しくなります。しかしながら、
ゲームのコンテンツと現地の文化の間でしばしば問題を引き起こす以下の４つの文化的な要因を常に考
慮することによって、問題が起きる可能性を減らすことは可能です。:
4
1. 歴史: 過去と現在
歴史的な正確さに関する問題は現地のマーケットにとって最もセンシティブな問題の一つです。多くの
文化がその歴史的な遺産や起源について非常に保護する立場を取っており、改ざんされたり不正確な歴
史描写は強烈で感情的な反発を生む可能性があります。歴史は魅力的な題材ではありますが、ゲーム内
である歴史上の出来事の内容を余すところ無く表現する事はほぼ不可能です。また問題になりうるのは
古い歴史の問題だけではありません。最近の歴史も、その出来事や結果の記憶が人々の心のなかで新鮮
であるがゆえにとてもセンシティブな話題になりえます。
2. 宗教と信念体系
ゲームコンテンツのクリエイターは、そのゲームがリリースされる文化圏を構成するシステムに敏感で
ある必要があります。一般的に、 神聖な規則に基づいた社会は情報が現れる状況に対して柔軟でなく譲
歩しない傾向があります。なぜなら、彼らは自分たちが人間の判断よりも上位に位置すると考える基準
に従っているからです。; 要するに、問題になりうるコンテンツが登場しさえすれば、その文脈には関係
なく、反発を生む可能性があるということです。
3. 民族性と文化的な摩擦
歴史や宗教などの一触即発の問題以外にも、様々な形の意見の相違、誤解、態度や、文化的なグループ
の間で継続的な摩擦を引き起こす広い範囲に渡る多くの要因があります。これらの中で最重要のものは
民族的または文化的なステレオタイプの使用であり、特定のグループに対するネガティブな偏見を含め
るか含めないかに関する認識です。
4. 地政学的な想像力
中央政府はしばしば、オンラインマップやビデオゲームを含むデジタルメディアを通して、自分たちの
世界観や地理的な支配権の拡大を強化します。これは、政府がある領土の権利を主張し、それらの領土
が機能的なマップやビデオゲームの世界などで、自国と統合されているように表示されることを期待す
るというような状況を含みます。（故に、彼らが要求している描写としての”地政学的な想像力“という
言葉は現実を反映していません。）中国やインドの政府は自国の地図の表示方法や地元の政治的な状況
の表現方法について法律で指示しており間違いは許されません。
これら４つのカルチャライズに関する要因を含むゲームの例については、付録２を御覧ください。
カルチャライズの最良の手法
カルチャライズの基礎をなす原則は、ゲーム開発プロセスの間に少しの時間と労力を投資するだけで、
発売後の問題を解決するために大量の時間、お金、PRを失う事態を防ぐことが出来るということです。
幸いなことに、カルチャライズの戦略に関してより積極的になるためにデベロッパーが取ることの出来
る重要なステップがいくつかあります。
自覚を得ること
1. 基本的な自覚を持つこと
: 一つの重要なステップとして、文化的な問題を引き起こす可能性のある問
題について基本的な自覚を得るということが挙げられます。コンテンツのクリエイターやマネー
ジャーは、文化的な問題が起こりうるということ、またその際の鍵となるマーケットはどこか、鍵と
なるコンテンツのタイプは何か、を理解する必要があります。例えば、中国、インド、韓国、中東が
センシティブなマーケットであることは多くの人が知っています。また、地図、国旗、歴史的な情報
など特定のタイプのコンテンツが反発の火種となりうることも多くの人が知っています。
2. 質問をすること
: ここでの目的は主題専門家のような熟練を身につけることではありません。ただ、
開発中に適当と思われる質問をするというだけのことです。例えば、格闘超人（２００２）という
ゲームにはイスラム教のコーランの詠唱部分が含まれた簡単なオーディオトラックが含まれていたた
め、広範囲に及ぶ反発を買い、最終的には発売禁止となりました。この問題は誰かが質問をしていれ
ば避けられたかもしれません。“この歌詞はどうやって生まれたの？どういう意味なの？”と。
もし何かが変だと感じたら、正確な理由は分からなくても、その問題を直ちに提起すべきです。
3. 説明責任を果すこと
: カルチャライズを成功させるためには、それを開発サイクルの通常の要素とし
て扱うことが必要です。これはそのプロセスの責任が特定の個人・チーム、多くの場合コンテンツの
コーディネーターやエディターに与えられるべきであるということを意味します。また、“文化関連”
または“地政学関連”など適当な名前の新しいバグタイプをバグ追跡システムの中に作り、それらの問
題が認識され、解決されるようにすることが必要です。
5
問題を特定すること
上述の通り、カルチャライズはできるだけ早い段階でゲームコンテンツに適用されればされるほど有効
であり、コンセプトの段階でキャラクター、プロット、環境、オブジェクトなどの意味や意図、目的に
ついてチームと話し合っておくことで大部分の潜在的な問題は事前に察知できることが良くあります。
以下は、潜在的な問題を特定するための基本です。:
文脈の近接性
: 簡単に言うと、文脈の近接性とは、あるコンテンツの要素が実在の人物、場所、時間
や形式などに近ければ近いほど、文化的にセンシティブな問題が起きる可能性は大きくなるという考
え方です。デベロッパーは現実世界の場所、建物、人々、イベント、宗教、国籍、民族性などを模倣
したコンテンツをまずは求め、その後コンテンツが、そのインスピレーションとなった現実世界の対
象物とどの程度まで似ているか評価すべきです。
2. 外部のリソースを利用する
:
a. 文献資料: 文化的な研究、特定の国に関するガイド、シンボルに関する辞書、宗教や神に関する
百科事典など、基本的な研究に役立つ参考文献はたくさんあります。
b. オンラインリサーチ: Wikipedia、政府の公式サイト、NGOサイト、宗教組織のサイト、など。
c. 地元の意見: 特定の地域や文化圏の人の知識に触れることは特に有用です。もしあなたが国際的
な大企業に勤めているなら、会社内部の多様性を利用して同僚に意見を聞いてみてください。あ
るいは、オンラインの様々なフォーラム（例えば、Yahoo Answersなど）で様々な意見を募るこ
とも可能です。このようなその場限りの意見収集には主観的なものも含まれると思いますが、十
分な量のサンプルを集めれば明白なパターンが見えてくるものです。
d. 主題専門家: 上述したリサーチでも明確な結果が得られない場合は、歴史、比較文化研究、地理
学など様々な分野の専門家を頼りましょう。
1.
重大性を見積もること
リサーチで問題が見つかったからといって、必ずしも全ての潜在的な問題を修正しなければならないわ
けではありません。潜在的な文化的問題を特定したら、次の段階への鍵は”修正必須“の問題を効果的に
決定出来るようになることです。
見つかった問題の優先順位を決める
: “明白に問題となる点”を分離する – “当然予想されるリスク”か
ら判断して
“
問題になることが確実にわかっているもの – 何らかの問題を引き起こすかもしれないが
対象マーケットからゲームを引き上げるような事態にはならないであろうと思われるもの。
2. 自分の選択を書面にする
: 全てのゲームパブリッシャーには、センシティブなコンテンツを変更する
かしないかについて選択する権利があります。大抵の会社は変更することを選びますが、問題がセン
シティブであるかどうかぎりぎり不明確な場合には些細なコンテンツ変更であってもあまり意味が無
いように思われるケースがあります。そのような場合には、政府や消費者から問題提起された場合に
備えて意思決定の過程を自己防衛的な説明文で書面にしておくことが大変重要です。
1.
正確性をもって実行すること
カルチャライズとは大変更を行い、ゲームの全体的なアイデアを考えなおすことである、という先入観
を持つゲームデザイナーは多くいます。これは誤った考えであり、多くのゲームデザイナーが地政学
的、文化的側面に全く向きあおうとしない大きな理由の一つです。そうすることは破壊的な問題を引き
起こすと思っているからです。このことはカルチャライズにおける最も大切な原則の一つを明らかにし
ます。:
1.
外科的なアプローチを取ること
: 最低限のコンテンツについて最低限の変更を施すように心がけてく
ださい。そのゲームをターゲット市場で確実にリリースするために絶対に変更しなければならない内
容のみ変更するようにしてください。文化的な問題を含むケースの大部分は、特定のシンボルや言
葉、キャラクターデザインなどについて少量の、ただし正確な修正を施すだけで解決する場合があり
ます; ゲーム全体の設定を見直すというような大きな問題になることは稀です(そういう場合もないで
はありませんが。)
結論
作りたいゲームを作ってもらえば良いですが、あなたの創った世界に参加し、できることなら文化的な
途絶を感じることなしに楽しみたいと願っている世界中の多文化のユーザーが居るということを忘れな
いでください。開発サイクル内でうまくカルチャライズを行うことは、一朝一夕に実現できるものでは
ありません。; うまく組み込めるようになるには時間が掛かります。しかしながら、その会社のコンテン
ツのクオリティー、政府機関との関係、地元のゲーマーのイメージ、などへの良い影響は長期投資とし
て価値あるものであることが分かるでしょう。
6
7
インターナショナライズ
I18N と省略されるインターナショナライズは、ゲームローカライズを実行可能にするプロセスです。イ
ンターナショナライズの前には、製品は一つの言語でしかゲームコンテンツを表示することができませ
ん。インターナショナライズ後、製品のコードベース、構造、ユーザーインターフェイスは複数言語で
ゲームコンテンツを表示することが可能になります。インターナショナライズされた製品には、地域に
よって異なるような要素は含まれていません。
ユーザーインターフェイス
フォント
日本語、韓国語、中国語といったアジア言語は、主に固定幅のフォントを使います。もしオリジナルの
アジア版のプログラマーが、欧州言語版用にプロポーショナルフォントを扱えるようにシステムをプロ
グラムし直すことを嫌がれば、欧州言語版は文字間の無駄なスペースのせいでゲームの見た目が悪くな
り、一行の文字数も短くなることから翻訳の質も下がり、悪影響を受けることになります。
これは大部分のPCやコンソールゲームではもはや問題ではなくなっていますが、携帯機においては未だ
問題のように思われます。
画面のスペースを更に最大化するために、プロポーショナルフォント以外に、カーニング可能なフォン
トディスプレイシステムを利用すると良いかもしれません。(文字の組み合わせによって文字間隔を変
え、重なりあった文字の下の白紙のスペースを最大化する、など。)
固定フォントの言語に慣れたプログラマーにとって頭痛の種であるということ以外にも、これは翻訳者
にとって一列の幅の限界を調べるのが複雑になるという弱点もあります。シンプルな一列の幅のチェッ
クツールや、各文字のピクセル幅を足して画面上の文字列は別でスペースの制限内に収まるかどうか調
べるようなExcelのマクロを作ることも必要になります。ですが、その結果としての翻訳の質やゲームの
見た目の向上は充分苦労の価値のあるものです。
開発サイクルの初期段階で、翻訳チームと開発チームが協力してフォントを選択することは重要です。
翻訳者の方で、選択したフォントに自国の言語で使用される文字が全て含まれているか確認できる必要
があります。 さらに、画面に表示された際に問題なく読めること、また表示幅のテストに使用するピク
セル幅を決定するため（すなわち、翻訳が画面上の与えられたスペースに問題なく収まるよう）に、
フォントサイズやフォントタイプも決めなければなりません。フォントが“しっくりきているか”、例え
ばヨーロッパ言語でアクセントマークが正しく見えるか、アジア言語で漢字がちゃんと読めるか、と
いったことはその言語のネイティブスピーカーにしか判断できません。ですから、いつも必ず、翻訳が
始まる前にフォント承認のステップを入れるようにしてください。
U.I.とメッセージウインドウ
複数言語を扱い始め、テキストが画面に表示されると、言語によってレイアウトを調整することは避け
られないということが分かるでしょう。この点に関して、以下の提案が役に立つかもしれません。:
●
●
●
“吹き出し”がメッセージウインドウに合わせて自動でリサイズしたり、より柔軟に領域表示するよう
にしたりする。(このようなシステムをプログラムするための一度限りのコストは、後々開発チーム
が手作業でリサイズしたりする為の多くの時間を削減することにつながります。) もし自動化された
システムは負担が大きすぎるようなら、少なくともテキストファイル中でx,y,w,h座標を指定するこ
とでリサイズ出来るようにはしておくべきです。そうすることで、大量の修正要求で開発チームを苦
しめることなしに、翻訳チームの方で修正対応を行うことができます。
● あるいは、もしすべてのテキストボックスが全言語を通じて同じ大きさでなければならない場合
は、英語テキストの長さではなく予想される翻訳の長さに合わせるようにしてください。経験則
から言って、翻訳は英語の30-40%増しで長くなると思います。
自動テキストラップをシステムに組み込む。すなわち、改行を翻訳者に手作業でコードを入力するよ
う頼むのではなく（そして、画面上の正しい位置で改行されているように見えるように常にテキスト
を入れ替え続けるのではなく）、ゲームシステムに自動でやらせるようにしてください。(また、単
語が自動で二行にわかれてしまうのが嫌な場合はオーバーライドを許可するようにしてください…こ
の点については後で詳しくお話します。)
これはユーザーが解像度や画面サイズを変更することが出来るPCゲームにとっては実質的に必須の
内容と言えます。
8
●
●
(もう一つ適当な場合のオプションとして…) テキストが指定されたエリアに完璧に収まるように、
フォントの拡大縮小システムを組み込む。すなわち、メニューの見出しなどで、テキストがわずかに
指定エリアからはみ出るような場合、システムがフォントを縮小して収まるようにする。(翻訳を単
語の途中で切ってしまうより良い手法。)
(またもう一つ、適当な場合の手法として…) テキストがスクロールしたり、ポップアップ画面に展開
されるようにする。そうすることでGUIでスペースが限られている場合などでも、プレイヤーは省略
された言葉や切断された単語の意味を解読したりする必要なしに、ハイライトすることでテキスト全
体を見ることができます。
プリレンダームービーのサブタイトル
ディスクスペースをセーブし、開発チームが同じムービーの複数のバージョンをレンダリングする必要
がないように、サブタイトルをムービーファイルに“焼き付ける”のではなく、ムービーをプレイする際
にリアルタイムでサブタイトルがムービーの上に重ねて表示されるようなシステムを組込んでみてくだ
さい。そのようなシステムを作ることが大変過ぎると思われる場合は、各言語について毎回サブタイト
ルに関するバグフィックスを行わねばならないコストを計算してみてください。(そして、サブタイトル
が最初から正しい見た目で、完璧に同期がとれていることは非常に稀です。そのため、全てを何度も何
度もレンダリングし直すのではなく、もっと柔軟性を持ったシステムを強くお勧めします。)
サブタイトルの為の最良の手法には以下のようなものが含まれます。:
●
●
●
●
●
明るい色で暗い縁取りのsan serif fontを組み込む。そうすることで、明るい背景でも暗い背景でもよ
く見えます。(例として、Red Dead Redemptionを参照してください。)
ゲーム中を通じてサブタイトルは画面内の同じエリアに位置するようにする。; インターフェイスを
邪魔しない限り、画面の下３分の１にあるのが好ましい。
各テキストのセットは３秒間表示、左詰め、一行には９６文字、一度に表示するのは３行までとす
る。それ以上の行数を一度に表示するとユーザーが読むのが難しくなります。
可能な限りスクロールするテキストは避け、固定されたテキストを使用するようにする。
二人の人間が会話をしているときは、話者が変わったことをセリフの前にハイフン(-)をつけること
で表現する。特に新しい話者が画面外にいる場合は重要。(これは英語のサブタイトルでもやるべき
ことです。)
構造
ローカライズアセットはローカライズチームがアクセスできるフォルダー構造を持ったコンテンツ管理
システムに保存されるべきです。エクスポート・インポートを簡単にする為によく使われる提案として
は、アセットをレベル、ゲームのロケーション、言語などに分けて保存することが挙げられます。
言語とカントリーコード
言語や特定地域のバージョンであることを示すためにファイルネームの最後や、ディレクトリー名、プ
ログラムラベルなどに単一の文字(例えば“E,F,I,G,S,J,K,やC”)を付けたくなるかもしれませんが、そのよ
うにすることは結局、米語と英語、欧州スペイン語やポルトガル語と南米スペイン語やブラジルポルト
ガル語、また大陸の簡体字と台湾の繁体字と香港の繁体字との区別に困ることになるでしょう。さら
に、どのコードでどの言語を表すべきなのかについても混乱する可能性があります。(例えば、ドイツ語
は “Ge”とすべきなのか、Deutshの“De”とすべきなのか。) 言語とカントリーコードの間の混乱を解決す
るための良い方法の一つは、業界を通じてよく知られているISO基準に準拠することです。
http://en.wikipedia.org/wiki/List_of_ISO_6391_codes http://en.wikipedia.org/wiki/ISO_31661 (または
http://www.loc.gov/standards/iso6392/php/code_list.php
)
例えば、二文字のランゲージコードと二文字のカントリーコードを組み合わせれば、言語と地域のバー
ジョンを区別するための短いながらも容易に認識できる方法となります。(南米のように一つの言語が複
数の国で使われている場合は、例えばメキシコのように最も代表的な国を選べば良いのです。) カント
リーコードとランゲージコードの間はダッシュ(PT-BR)、アンダースコア(PT_BR)、システムが許せばよ
りコンパクトに一方を小文字、もう一方を大文字(ptBR)で書くとよいでしょう。
このようにすると以下の様な表記になります。:
enUS
米語
9
enGB
英語
deDE
ドイツ語
esES
欧州スペイン語
esMX
南米スペイン語
frFR
(欧州)フランス語
itIT
イタリア語
jaJP
日本語
koKR
韓国語
ptBR
ブラジルポルトガル語
ptPT
欧州ポルトガル語
plPL
ポーランド語
ruRU
ロシア語
zhCN
簡体字(中国語)
zhTW
繁体字(中国語)
これらを使うのに慣れるには少し時間がかかるかもしれませんが、混乱をなくすのに多いに役立つはず
です。
ローカライズツールとファイルフォーマット
開発チームがリソースを管理する目的(Visual Source Safe, AlienBrainなど)やプログラミングをスムーズ
にする目的(Visual Programming Environmentなど)で様々なツールを使うように、翻訳チームにも仕事
をスムーズに進める事を手助けするツールが必要であると思われます。大部分の仕事はただのテキスト
ファイルやExcelファイル上で行われることが多いですが、ファイル管理ツール、翻訳メモリーツール、
電子辞書、ファイル比較ツール(BeyondCompareや古い“Diff”系のツールも)といったツールは翻訳プロセ
スを最適化するのに役立ちます。これはリソースファイルに頻繁に変更が掛かる環境、また大規模な
チームで作業をする場合において特にそうです。ここでそのようなツールの詳細に触れることはしませ
んが、あなたの開発チームや翻訳チームのニーズに合った最適な方法を見つけられることを強くお勧め
します。
ファイルフォーマットについていうと、プレーンなテキストファイルを使用している場合、特にアジア
言語を扱う場合にはファイルフォーマットの違いに気をつけなければなりません。拡張ASCIIとJIS
フォーマット等の間で文字化けの問題を心配するよりも、最初からターゲットとする全ての言語が共存
できるフォーマット、例えばUTF-8に決めておくほうが賢明でしょう。
ゲームで良くある落とし穴のひとつは、グラフィック中で使用されるテキストの問題です。2Dテクス
チャーであろうと3Dポリゴンモデルであろうと、開発チームはゲーム中のどこにテキストが現れるのか
を追跡し、それらが正しくローカライズされるようにしなければなりません。各言語バージョンに合わ
せて全てのグラフィックテキストを描き直す必要があるのです。(もしくは、テキストの代わりにグラ
フィックアイコンやシンボルを使い、グラフィックアーティストの負担を減らす、という方法もありま
す。) これらはその他のテキストリソース同様、翻訳者に提供され、変更箇所を追跡していく必要があり
ます。
リソースファイルとキャラクターのエンコード
UIテキストはソースコードにプログラムで書き込んでしまわないことをお勧めします（この点で言う
と、誤って翻訳者に変更されてしまうと問題になるようなゲームスクリプトは全てそうです。）また
ファイルが論理的にフォーマットされていることは必須です。もし、ゲーム中の“イベント”やストー
リーラインがファイルを通してバラバラになっていたり、順番通りになっていない場合は、翻訳者がテ
キストの順番やそれがゲーム中のどこで表示されるのかが分かるようなコメントや何らかのラベリング
システムを入れるようにしてください。
ある文字列がどのプラットフォームの為のものなのか明示するようにしてください；これは特にセー
ブ、ロード、その他プラットフォームの規則に準拠することが必要な機能については重要です。ローカ
ライズチームはこれらの文字列を翻訳する際、プラットフォームホルダーによって決められた用語を使
用するように注意深く進める必要があります。
もちろん、全てのファイルが似通ったフォーマットであれば物事はより明確でスムーズに進むでしょ
10
う。特に、開発チームか翻訳チームが変換ツールを使用している場合、フォーマットの変更が少なけれ
ば少ないほど、変換、再変換に伴う作業量は（エラーの可能性も）減ります。
ファイルのエンコードの仕方によっては、メモリーの問題に遭遇するかもしれません。アジア言語がダ
ブルバイトのキャラクターセットを使用しており、英語やヨーロッパ言語もそうすることを想定してい
る場合、文字列の長さが予想以上のメモリーを使用していることにやがて気がつくでしょう。（英語は
日本語に比べて平均で約1.5倍のキャラクターを使用します。スペイン語やドイツ語は、日本語の二倍以
上の文字を使用します。） メモリーのオーバーフローや単なる無駄遣いを避けるためには、ヨーロッパ
言語の文字をシングルバイトにしておくエンコーディングを使用してください（例えば、UTF-8などの
可変型バイト長のエンコーディング。）
逆のケースで、中国語、韓国語、日本語などで、欧米のデベロッパーがアジア言語の全てのフォント
セットをメモリーに入れておくことが困難な場合（例えば携帯機など）は、ゲームのある箇所で表示さ
れる文字や記号だけをリアルタイムでメモリーにロードするという方法があります。それが難しく全て
のフォントをロードする必要がある場合は、フォントのどの部分が必要ないかを翻訳者と話し合って決
め、最低でもその部分はフォントファイルから削除するという手法が取れます。例えば日本語の場合、
大抵のフレーズは2000文字のセットで翻訳することが可能です（学校に通う児童に教える文字数。）
プログラミング
一般的なプログラミングのヒント
プログラム内でテキストを“ハードコーディング”してしまうことを避けるべきなのは言うまでもありま
せん。なぜならそれは、修正が必要な場合に、ビルドの時にシステムに自動でやらせるのではなく、プ
ログラマーが毎回手作業で修正作業を行わなければならないことを意味するからです。更に、テキスト
がハードコードされていると、プログラマーは翻訳すべきテキストをプログラムソースから分離し、ま
た手作業で再入力するか、もしくはソースコードを翻訳者に渡して翻訳箇所を見つけてもらう（誤って
プログラミングコードが変更されてしまうリスクも冒しながら）必要があるでしょう。最良の方法は、
ゲーム中で使用される全てのテキスト文字列を各言語毎にリソースファイルとして独立させておくこと
です。
UIやメッセージウインドウのところでも述べたように、テキストをセンタリングしたり、既定の位置に
表示させたりしたい場合は、座標をハードコーディングするのではなく、ターゲット文字列の長さに基
づいてシステムでテキストのセンタリングや位置決めをするようにした方が良いです（でないと、プロ
グラマーが毎回手作業で修正しなければならなくなります。テキストの位置決めやセンタリングは必要
だが、システム的に自動でサポートすることが出来ない場合の代案としては、座標がテキストファイル
や別のリソースファイルに表示されるようにし、プログラマーの貴重な時間を奪うことなしに、翻訳者
やQA担当者がビルド毎、各言語毎に位置を変更できるようにするという方法があります。）
リソースファイルは言語ごとに分けられているべきです。全ての言語を一つのExcelファイルの別ページ
や行にまとめることは整然としているように見えるかもしれませんが、実際には異なった言語の翻訳者
が同時に同じファイルで作業することが出来ず、誰かが全言語のテキストをコピー＆ペーストして一つ
のファイルに戻さなければならないということを意味します。これは、人的ミスや時間の無駄につなが
ります。各言語のファイルは独自のディレクトリーに存在し、ビルド時にそこからコピーするというや
り方をお勧めします。
また、ローカライズチームを手助けするために、ビルドの全てのバージョンを通してソース言語のテキ
スト変更箇所のリストを含めるようにしてください。これによって、ローカライズチームが新規や編集
された文字列を見逃す可能性を最小限にすることができます。
翻訳テキストにXMLを使う
プロジェクトの翻訳を行う際にプレーンテキストファイルやExcelテーブルではなくXML（拡張マーク
アップ言語）を使うほうが良いと考える企業が増えてきています。例えば、1バージョンの文字列しか必
要としない言語と、同じ文字列が6バージョンまで必要な言語がある（後者には文法上、単数・複数、男
性・女性・中性の別が存在し、前者にはないとか）とわかっている場合、XMLタグを使えば両方のケー
スに対応できます。ですから、全ての言語で同じ文字列を全く同様に6バージョン翻訳する代わりに、一
度翻訳するだけで済みます。一方、より多くのバージョンが必要な言語は必要な箇所に加えることもで
きます。（プログラムのメモリーには各ラインに最大数のコンビネーションを許可するようにしても良
いでしょう。そのほとんどは最終的にNULL文字列に終わるかもしれませんが。またXMLファイルは
パースされコンパイルされているので、XMLに存在する実際の文字列はソースコードの中に置かれ、シ
11
ステムは実行時にそれらの文字列に分岐するよう指定されます。）
そうすることで、日本語、中国語、英語では店員さんに“Hello!”に相当するシンプルな挨拶をさせ、イタ
リア語では”Hello Sir!”, “Hello Madam!”, “Hello gentlemen!”, “Hello ladies!”に相当する挨拶をさせること
ができます。この場合、適当に定義されたXMLタグを用いることで、単数・複数、男性・女声などの分
岐が存在すること、またゲーム内の文脈によってリアルタイムで分岐させることをゲームシステムに記
録させることができます。
XLIFF (XML Localization Interchange File Format)
多くのプラットフォーム、ゲームエンジン、その他のテクノロジーではテキストリソースを様々な
フォーマットで保存していますが、これらのフォーマットをサポートすることはローカライズチームに
とって問題となる場合があります。第一に、各フォーマットは別個のワークフローを要求するので翻訳
の要求と組み込みのサイクルが複雑になります。またチームが高品質でコスト削減につながる翻訳ツー
ルを開発する際の妨げにもなります。
2002年に、XLIFFフォーマットはこの問題を解決し、全てのデベロッパーにローカライズチームとテキ
スト翻訳をやり取りするための標準的なフォーマットを提供するために確立されました。この標準仕様
を組み込むには、翻訳リクエストを目的としてネイティブフォーマットからXLIFFスキーマにテキスト
リソースを加工することが必要になります。翻訳の組み込みにはXLIFFからネイティブのテキストリ
ソースファイルフォーマットに戻すためのポスト加工が必要になります。
XLIFFに関する更に詳しい情報やサポートツールについては、以下のリンクを参照してください：
http://docs.oasisopen.org/xliff/xliffcore/xliffcore.html http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xliff http://en.wikipedia.org/wiki/XLIFF テキスト中の変数の順番
CやC++のprintfや同様のテキスト出力機能を使用すると、%sや%dといったテキスト文字列に組み込まれ
た変数の順番が言語間で変わってしまうことが多いことにご留意ください。例えば：
msg="
%s
bought
%d %s
for
%d
dollars."; という文は日本語や韓国語では順番が変わって以下のようになります…
msg="
%s
が
%s
を
%d
個買って、
%d
ドルを支払いました。"; （要するに、キャラ名、個数、商品、費用という順番が
キャラ名、商品、個数、費用という順番に変わります。）
翻訳者がターゲットテキスト内の変数を自由に変更することを可能にするシステムを作らなければ、プ
ログラマーが自らターゲット言語内の順番に合うように各テキスト文字列の順番を変更しなければなら
ないかもしれません。
注：上で単数・複数のトークンについて話してきた通り、上述したシステムを組み込むことで結果的に
テキストがいかに自然で正しいものになるかが証明できます。
例 "
John
bought
6 potion
for
1
d
ollars
." …という文は明らかに間違っていますが、トークンシステムを組み込めばテキストは以下のようになりま
す…
msg="<Cap>
<Character1>
bought <IF_SING_Number1><INDEF_ART_SING_ITEM_2><ELSE_NOT_SINGLE_Number1><Numb
er1> <PLR_ITEM_2><INDEF_SING_ITEM_2><END_IF_SING_Number1>
for
<Number2> <IF_SING_Number2>dollar<ELSE_NOT_SING_Number2>dollars<END_IF_SING_Number2>
.
12
"; …そして、正しく組み込めば、上記のシステムは以下の結果のどれも出力することができます…
John bought
an
apple for 1 dollar. John bought
2
apple
s
for
2
dollar
s
. Mary
bought
a pear
for
3
dollars. などなど….
日付、時間、通貨、数字のフォーマット
日付や数字の表示フォーマットは地域によって異なります。ゲーム開発の前にローカライズチームと連
携を取っておくことで、開発チームはゲームで影響を受ける部分の洗い出し、言語ごとに組み込むべき
フォーマットを確定することができます。
以下は最も一般的な言語の標準フォーマットです。
US English
French
German
Spanish
Italian
Japanese
Date
mm/dd/yyyy
dd-mm-yyyy
yyyy-mm-dd
dd/mm/yyyy
dd/mm/yyyy
yyyy年mm月dd日
Time
hh:mm:ss am/pm
hh:mm:ss
hh:mm:ss
hh:mm:ss
hh:mm:ss
hh:mm:ss
(12-hour clock)
period (.)
(24-hour clock)
comma (,)
(24-hour clock)
comma (,)
(24-hour clock)
comma (,)
(24-hour clock)
comma (,)
(24-hour clock)
period (.)
comma (,)
space ( )
space ( )
comma (,)
15,631.87
15 631,87
12 345,67 €
space ( ) or
period (.)
15 631,87 or
15.631,87
€ 12.345,67
1º 2º 3º … or
1ª 2ª 3ª …
1º 2º 3º … or
1ª 2ª 3ª …
1目 2目 3目 …
Decimal
Separator
Thousand
Separator
Number
Example
Currency
Ordinals
$12,345.67
12 345,67 €
space ( ) or
period (.)
15 631,87 or
15.631,87
12 345,67 €
1st 2nd 3rd …
1er 2e 3e … or
1. 2. 3. …
15 631,87
15,631.87
¥ 12,345
1re 2e 3e …
これら様々なフォーマットを組み込む最良の方法の一つは、翻訳される各数字フォーマットタイプのリ
ソースファイルに文字列を含めることです。そうすることで、年、月、日の順番や数字を分けるための
様々なキャラクターを正しく識別するのは翻訳チーム次第ということになります。
ゲーム内で通貨をローカライズする場合には、各言語の独自の通貨シンボルに気を配るだけでなく、為
替レートも見積もるべきです。例えば、アメリカでゲーム内でチーズバーガーを2ドルで売っているのは
問題ないですが、日本版で値段を2円と表示していたら現実感がありません。例えば160円程度にすべき
でしょう（1米ドルを80円と仮定すれば。）
自動改行とテキストのラッピング
大量のテキストを含むゲームに自動改行やワードラップのシステムを組み込むことは、テキストオー
バーフローバグの可能性を大幅に減らします。また、オリジナルのライターや翻訳者が手作業で全ての
改行を入れる場合と比べて、作業時間もQA時間も大幅にスピードアップします。
更に、同じテキストがいくつかの場所で異なった幅で表示されている場合などは、同じテキストの複数
のバージョンを用意する苦労をなくします。（もっと悪い場合には、翻訳者に最悪の場合の幅に備えて
テキストを用意させ、別の画面では残りのスペースは使用されないということになります。）
そうは言っても、自動改行アルゴリズムを無効にする必要がある場合もあるでしょう。例えば、ハード
メーカーはしばしば、ある種の用語について行をまたいではいけないというルールを強制します。この
場合、“行をまたがない白い空白”シンボルが役に立ちます。これには、Unicodeフォントセット(0xA0)の
中の特殊な隠しキャラクターコード；または、“<nbsp>”とか“_”（アンダースコア）などの、実行時に変
換されて空白のように見えるが改行アルゴリズムの例外となるようなトークンが利用できます。（さら
に、改行アルゴリズムがハイフンでも改行されるような場合は、ハイフンで改行できない単語が改行さ
れないように、特殊な行をまたがないハイフンシンボルや“
<nbhy>
”が必要になるかもしれません。その
ようなケースは恐らく稀だと思われますが。
さらに、ゲームテキストが以下の様な特殊な環境にある場合もあるかもしれません：
“
Brigadoon > < Xanadu
” もし自動改行システムだけに任せておけば、この道標のテキストは以下の様に表示されるかもしれませ
ん：
13
“
Brigadoon > < Xanadu
” ここでも、改行しないよう指定するキャラクターや“
<lb>
” といったトークンを加えることで、このよう
な問題が発生するたびにプログラマーが介入して例外をハードコーディングしなければならないといっ
た事態を防ぎます。
英語、ドイツ語、スペイン語、イタリア語における句読点の例外
基本的な自動改行アルゴリズムは以下のように動作します：テキストがその行のウインドウの長さを超
えていたら、画面に収まる最後の文字を見つけ、そこかテキストを遡ってスペース””かハイフン”-“を見
つける。そうしたらスペースかハイフンの後に表示される全てのテキストを次の行に移動し、次の行で
も同じプロセスを繰り返す。行を遡ってスキャンした時にスペースもハイフンも見つからなければ、行
の制限を超える文字のところで強制的に単語の途中で改行するしかありません。（文法的に言えば、単
語の途中で改行する場合は、音節のところで改行し行の最後にハイフンをつけるのが正しいのですが、
これは大抵のゲームで必要とされるよりも進んだ手法ですし、強制的に改行することで解決するという
手法で稀な例外として扱った方が良いでしょう。）このアルゴリズムについて可能なちょっとした最適
化としては、行全体ではなく15文字程度のみを遡ってスキャンすることが考えられます（特に、以下の
“隠された改行トークン”システムを組み込む場合には。）
コンマ ”,”、ピリオド（フルストップ） “.”、エクスクラメーションマーク “!”、クエスチョンマーク “?”、
セミコロン “;”、コロン “:”はそれらが繋がっている前の単語の一部であるかのように扱って、それらが単
体で次の行に表示されることのないようにしてください。
また“em-dash”や“en-dash”（それぞれmとnの幅を持つ長めのハイフン“—”）、スペイン語の“raya” (キャ
ラクターコード0x97でクォーテーションマークのように使われる約三倍の長さのあるハイフン)といった
キャラクターにも注意してください。これらは次の行に移すことができます。しかしながら、フォント
やテキスト表示システムがこれらのキャラクターをサポートしていない場合、翻訳者は2つのハイフンで
代用する場合があり、このようなときはシステムで例外扱いとして、2つの連続するハイフンの前か、後
ろで改行しなければなりません。
注： ドイツ語には行の最後に使用する99の形をしたクォーテーションマークがあり、スペイン語にはセ
ンテンスの始まりに使用する反転したエクスクラメーションマークがありますが、これらも自動改行シ
ステムに関する限りは、上述した他の句読点と同じ規則に従っています。
（ドイツ語の引用符はこのような見た目で:
コードは0x84と0x93になります。）
句読点の話題といえば、翻訳者がシングル‘’とダブル“”両方のクォーテーションマークを使えるようにし
ておくと良いと思います。イギリス英語はテキストを引用する際にシングルクオートを、アメリカ英語
はダブルクオートを使用しますが、どちらも別の引用内でテキストを引用する際には交互に使われるこ
とになります。スタイルに拘る人は結びのシングル引用マークを再利用する代わりに、真っ直ぐなアポ
ストロフィー（6や9の形をした引用符ではなく、コード0xB4の縦に真っ直ぐなアポストロフィーマー
ク）を使用することを望むかもしれません。これは多くの引用マークを持つテキストにおいてシングル
の引用符をアポストロフィーと差別化するのに役立ちますが、読みやすさを改善するためにここまでや
る会社はまだ多くありません。
ゲームシステムや翻訳ツールが何らかの理由により“”"`'’といった句読点を扱えない場合、
<66>,<99>,<11>,<6>,<9>, <1>といったトークンを組み込み、コンパイルや実行時にそれらのシンボル
に置き換えるという回避策があります。（これらはシンプルでどういうものかが視覚化しやすく、必要
であれば翻訳者が簡単に入力することができます。）
フランス語の句読点の例外
フランス語には自動改行システムを組み込む際に考慮すべき、いくつかの異なった句読点の規則があり
ます。エクスクラメーションマーク “
!
”, クエスチョンマーク “
?
”, セミコロン “
;
” コロン “
:
”, ダブルクォー
テーションマーク “
“
” “
”
”（66と99の形をした引用符）は一般的にそれらの前にスペースが一つ入りま
す。これに対処するために、以下の内容を組み込むことを提案します:
1.
フランス語の翻訳者に、改行されないスペース(0xA0)、または“<nbsp>”などのnon-whiteスペースと
して扱われるが、実行時にはスペースとして表示されるようなトークンを使うようにさせる。納品前
に、フランス語翻訳者はテキストをサーチして、改行されるスペースが前についている箇所を見つ
け、それらを改行できないスペースに変更する必要があります。最良の方法の一つは、ローカライズ
テキストを組み込んでいるローカライズエンジニアが時々フランス語テキストをチェックして、改行
できないスペースが無くなっていないかを確認し、それを翻訳チームに指摘するということです。
2. フランス語版ゲームのテキスト表示時には、改行システムがフランス語の句読点を正しく扱うように
14
する。これは“
Bonjour !
”を一続きの“単語 + スペース + 特殊な句読点”として扱うということを意味
します（望ましい代案。）
3. 安易で扱いにくい代案としては、フランス語フォントの以下のキャラクターの前に1スペース分の幅
の空のピクセルを加えておくというものがあります： “
!
”, “
?
”, “
;
”“
:
”, “
“
”“
”
”。 （これはフォント
の幅データ中でこれらの文字の幅に1スペースの幅に相当するピクセルを加えることで実現できま
す。）フランス語の翻訳者には、翻訳時にこれらのシンボルの前にスペースを加えなくても良いこ
と、それでも画面上では問題ない見た目になること、改行アルゴリズムを再プログラムする必要もな
いこと、などを説明する必要があります。しかしながら、この場合でも、句読点がスペース無しで他
の文字に連なる“
What the…!?!
”などのケースに備えて、トークン(<!>, <?>, <:>, <;>, <“>, <”>など)
や、これらのフォントが通常の幅に見えるような別のキャラクターを用意しなければならないものと
思われます。
日本語、韓国語、中国語の句読点
日本語、韓国語、中国語は改行位置に関してそれほど厳格ではありませんが、従うべき句読点の一般的
な規則がいくつかあります。それは単純な固定幅のフォントや改行アルゴリズムを使っている場合で
あってもです。（注 アジア言語ではスペースを使用する場合があまり多くなく、改行できるスペース
を探すよりも、文の途中で分割しようとして行の最後になるケースがしばしばです。）例外はヨーロッ
パ言語の場合と同様：ピリオド・フルストップ“
。
”、コンマ“
、
” “
，
”、締めのクォーテーションマーク
“
」
” “
』
”です。The exceptions are similar to European languages: periods/full-stops “
。
”, commas “
、
”
and “
，
”, 、ハイフンのようなセンタードット“
・
”が、新しい行の先頭に来てはいけないこと、また頭の
クォーテーションマーク“
「
” “
『
”が、その後に続くテキストがない状態で行の最後に来てはいけないと
いうことです。基本的には、テキスト表示エリアの最後に多少のバッファースペースを設けて、必要で
あれば行の最後にピリオドやコンマのようなキャラクターをねじ込めるようにしておくことです。そう
しないと、句読点だけが次の行の頭に表示されないように、その前にある文字列を句読点ごと次の行に
移さなければならないでしょう。一方、オープニングのクォーテーションマークぽい文字のところで改
行しようとする場合は、正しい句読点のルールを守るためには、それに続く文字と一緒に新しい行の頭
までその文字を移動させてください。
より詳しい情報はリンク先にあります:
http://en.wikipedia.org/wiki/Line_breaking_rules_in_East_Asian_language 英語、欧州言語に関する進んだオプション: 隠された改行トークン
特にテキストがリアルタイムでゲームシステムによって生成されている場合、またテキストが異なる
（またはサイズ変更可能な）ディスプレイエリアに表示されている場合、長い単語は画面に表示された
場合に行の長さのバランスを壊し、その結果テキストウィンドウやUIの見た目を損なう場合がありま
す。 このような場合、印刷メディアからヒントをもらって、長い単語を最も近いもしくは論理的な音節
で適切に改行するようにし、行の最後にハイフンを付けて単語が次の行に続いていることを示すように
するという方法がとれます。
翻訳者（とソース言語のライター）に“隠された改行トークン”を提供すれば、彼らはそのトークンを長
かったり問題があったりする単語の中に入れることで、自動改行システムがそれをガイドとして使いテ
キストを適正な位置で改行するようにできます。
<hlb>
のような長いトークンの代わりに、対象テキス
トが画面上でチルダ “
~
” やキャレット “
^
” を使わない場合は、これらをトークンとして使用し、長い単
語の音節の間に挿入することができます。テキスト表示システムが実際にこれらを画面上で表示するこ
とはありませんが、自動改行ルーチンは最も近いハイフンや文字列の最後の１５文字の間のスペースを
探している時にこれらの場所で改行することができます。
e.g. 論理的にいうと、印刷物でテキストを手書きしたり、表示する場合には、“
broadsword
”という語
は “
broad-
” で改行し、 “
sword
” を次の行で続けるでしょう。なので、翻訳者は “
broad^sword
” と記
述しておけば、あとは単語が今の行を超えて続く場合はシステムがうまく処理します。
同様に、もし “
supercalifragilisticexpialidocious”
という語が行をまたがってテキストが重なる場合
にゲームに問題を起こす時は、主な音節に隠れた改行をいくつか追加することを提案します。:
“
super^cali^fragilistic^expi^ali^docious
”
もちろんもっと入念に全ての音節に入力して
“
su^per^ca^li^fra^gi^lis^tic^ex^pi^a^li^do^cious
” とすることも出来るでしょう。このよう
な自由さは、画面に出た際のテキストの見た目や読みやすさを改善します。（英語の場合は少し贅沢過
ぎる方法のように思われるかもしれませんが、ドイツ語などの単語が長い言語においては、この方法は
画面スペースの有効活用の点で大きな差を生みます。）
しかしながら、当然のことですが代償として翻訳者はこれらのシンボルを翻訳中に付け加えなければな
15
らず、時間も取られますしオートコレクトやスペルチェッカー機能のせいで頭痛にも悩まされるでしょ
う。しかし、上手にプレビューしたりラインチェッカーツールを使うことでこれらの問題は大きく改善
されるでしょう。
さらに進んだ方法:
翻訳テキストに直接隠された改行トークンを加える方法の代案としては、各言語毎に
一般的な長い単語がどこで改行されるのかをリストにした辞書や参照テーブルを用意することです（例
えば、ビルドの時点で全ての“
broadsword
”という語を“
broad^sword
”に置き換えるようにシステム
に伝えるテーブルです。) そうすることで、翻訳者はこれらの語をテキストに入力する必要はなくなり、
代わりに、ファイルがゲームシステムの組み込み用に予備的な処理をされる段階で、辞書・参照テーブ
ルにある言葉は全て置き換えられ、テキスト全体を通してあたかも翻訳者が手作業で入力したかのよう
に機能します。これは翻訳を通して毎回手作業でトークンを入力するのに比べて、翻訳者への負担も少
ない方法です（スペルチェッカーや自動修正フラグで苦労する必要がないことは言うまでもありませ
ん。）
特殊シンボルの使用を許可すること
“”"`'’
といった句読点が、ゲームシステムやローカライズツールと問題を起こす場合、これらのシンボ
ルを表示するためにコンパイル時やランタイム時に入れ替えられる
<66>
,
<99>
,
<11>
,
<6>
,
<9>
,
<1>
と
いったトークンを組み込むことによって解決できることは既にお話しました。 同様に、enダッシュ、em
ダッシュ、raylaについても、
<->
,
<-->
,
<--->
を使用することで解決できます。ここではトークンを象徴
する目的で<xxx>を使っていますが、{xxx}や/xxxなど、あなたのシステムで動作する表現で問題ありま
せん。
もう一つのオプションとしては、もしあなたのフォントにワープロ、テキストエディター、Excelなどに
タイプしてアクセスすることが難しい特殊なシンボルがある場合、翻訳者が何らかのトークンシステム
を通じてそれらにアクセスすることを許可してみても良いかもしれません。以下は、アジア言語に見ら
れる記号の内、欧州言語の翻訳者も使用することを希望するかもしれないもののサンプルです（同じ
フォントをシェアしていたり、これらの2バイト記号がシングルバイトでも使える場合に限りますが。）
←
<l_arrow>
, →
<r_arrow>
, ↑
<u_arrow>
, ↓
<d_arrow>
, ⇔
<2way_arrow>
,⇒
<doub_arrow>
, ☆ <star>
, ★
<blackstar>
, ※
<snow>
, ～
<swungdash>
, ♪
<music> (or
<.|>
), △
<triangle>
, ▲
<blktriangle>
, ▽
<invtriangle>
, ▼
<invblktriangle>
, □
<square>
, ■
<blksquare>
, ○
<circle>
, ●
<blkcircle>
, ℃
<Celsius>
, °
<degree>
, ①
<circleone>
, ②
<circletwo>
, ③
<circlethree>
, ④ <circlefour>
, ⑤
<circlefive>
, ⑥
<circlesix>
, ⑦
<circleseven>, ⑧
<circleeight>
, ⑨
<circlenine>
, ⑩ <circleten>
, ♂
<male>
, ♀
<female>
, ＋
<plus>
, ＝
<equal>
, and ／
<slash>
etc. これはすべての言語で、有用な楽しい記号を翻訳中で使用することを可能にする簡単に組み込める拡張
機能です。
文法的なトークン
ターゲット言語において、テキストを文法的に正しく、より自然な見た目にするために、以下の様な
トークンのシステムを組み込むことを考えてみても良いかもしれません。あなたのタイトルの要求内容
にマッチするものを取捨選択して下さい。それほどテキスト量が多くないタイトルの場合は、ソース
コードに分岐をハードコーディングし、それぞれの場合に独自の文字列を用意する方がリーズナブルか
もしれません。しかし、様々なテキストの組み合わせが実質的に無限にある大規模なRPGやMMORPGの
場合、読みやすさや理解しやすさを臨むならトークンシステムは必須と言えます。
注:
SQUARE
ENIXはこれらの組み込み方法のいくつかについて知的財産権を申請中(日本特許申請
2003-178063)ですから、コンセプトを理解し、貴社のシステムに合った異なった組み込み方を見つける
ことが大切です。安全面を考え、意図せず著作権侵害となることのないよう、ここではいかなるソース
コードも掲載しません。
(一方、SEGAはネームエントリー画面とプレイヤーネームをゲームテキストに置き換える特許を持って
いますが、ほぼ全てのゲームが法的な訴訟になることを恐れずにそのようなシステムを使用していま
す。ですから、どのような内容を組み込み、それに伴うリスクをどう判断するかはデベロッパー次第と
も言えます。)
以前と同様、我々はトークンを表すのに<xxx>を使っていますが、{xxx}や/xxxなど貴社のシステムに合
うものを使っていただいて問題ありません。
●
●
●
<Cap>
以下に続く文字列の最初の文字を大文字にするトークン。
<CAP>
以下に続くテキストの全ての文字を大文字にするトークン。
<bold>
と
<italic>
のトークンはシステムがサポートしている場合にボールド、イタリックのフォン
トを使用可能にします。
16
システムがカラーのテキストをサポートしている場合の
<red>
や
<white>
といったカラートーク
ン。
● <wait x> 数フレームの間テキストの表示をポーズするためのトークン。ポーズすることで意味を強
調するための追加“パフォーマンス”をテキストに加えたり、字幕がセリフのタイミングに合うよう手
助けすることができます。
● 冠詞トークン(英語では、数字の1を“the, a, an”に置き換えるなど。フランス語ではもっと多くの組み
合わせがある。)
● 単数・複数アイテム、群れ名称トークン。(多くの名前を持っている場合、自動的に“s”をつけるので
はなく、参照テーブルシステムが必要になるでしょう。英語でさえgoose->geese; genius->geniuses;
fish->fishのように多くの例外があります。また一対のものを一つとして数える場合も例外として扱
うようにする必要があります。)
○ 注: 日本語や中国語のようなアジア言語は単数・複数表現をあまり使用しないので、母国語にそ
のようなコンセプトがないプログラマーはそのことをよく理解する必要があります。
○ 注: 0に注意して下さい…大抵の欧州言語では複数として扱われますが、フランス語では単数で
す。フランス語やそれに類する言語を扱う場合は、あなたのシステムがこの例外を扱えるように
しておいて下さい。
● 男性・女性・中性文法のトークンで欧州言語における“his/her/its”のような文法のバリエーションが
扱えるように。
● 最初の文字が母音か否かでテキストを分岐させるトークン。
○ 大抵の場合、最初の文字を単純に調べるだけで上手くいきます。しかし、発音しないh,yなどの
特殊なケースを含むフランス語の場合には拡張する必要があるかもしれません。大規模なゲーム
の場合には、全ての言語のあらゆる例外を扱うためのコードを教えるよりも、全ての名前につい
て、それを母音として扱うべきか、子音として扱うべきかをリストアップした参照テーブルを持
つ方が望ましいケースが一般的です。
● テキストの最後の文字が母音か子音かによってテキストを分岐させるトークン。これは、文中で冠詞
が目的語の後に続き、最後の文字が母音か否かで分岐する必要のある韓国語において特に有効です。
● テキストの最後の文字が“s”か“S”で終わるか否かでテキストを分岐させるトークン。ドイツ語用に拡
張してz, Z, x, X,ß (shaffen-S, ドイツ語のダブル-s)を扱うようにすることも可能です。英語を含む多
くの言語は所有格に対して規則があり、ほとんどの名詞に対してアポストロフィs(‘s)を付けるが、既
にsで終わっている場合は例外で、その場合はアポストロフィのみを付けます。
● 可変文字列に置き換わるテキストが固有名詞か否かをチェックするトークン。
st
● ドイツ語の問題（主語・所有格・与格・対格）、ロシア語の語形変化（単数・複数・再帰動詞x 1
/
nd rd
2/ 3（男性・女性・中性）x主語・所有格・与格・対格・助格・前置詞）を扱うトークン。
● 日本語、韓国語、中国語において数字の後に正しい数助詞を表示するトークン。(通常、数えている
ものが何であるかを表すために数字の後に文字を付ける必要があります。例えば、小さな獣の場合は
この数助詞、より大きな動物の場合はこの数助詞、平坦な物体はこれ、小さな物体はこれ、などと
いった具合です。これは欧州の言語には存在しないコンセプトです。) 名前リストの各名前の後に簡
単なフラグを付けることで充分対応できるはずです。そうすれば、どの数助詞を印刷すべきか決める
ための参照トークンを持ちさえすれば良いのです。
先ずは翻訳者と話して各タイトルに関する彼らの要求事項を知り、同時に開発チームの能力、時間、予
算の範囲を調べることをお勧めします。我々は全ての言語で正しい文法であることを推奨しますが、貴
社のゲームが各言語でどの程度まで正しく表示されるかということはビジネスディシジョンであること
も理解しています。
●
注: これらのトークンによって実現される見た目の美しさや文法的な正しさの代償としては: プログラ
マーや翻訳者にとって作業が複雑になること、よりフレキシブルなテキストシステムがより多くのテキ
ストの組み合わせを正しく表示できるかを確認するために追加のレベルのQAテストが必要になることが
挙げられます。しかし、MMORPGs, RPGsその他のテキストが重要なゲームにおいては、これらのこと
がストーリーの理解しやすさ、クオリティーに多大な貢献をします。(即ち、人間対人間の関わりが作用
し始めると、単数・複数の別や、誰が誰に対して何をしているのか、といったことを大変明確にしたく
なるものです。)
実際のトークンの名前がついた文法的なトークンの詳細な説明については付録３を見て下さい。
PAL vs NTSC TV
古い型のテレビで動作させることが予想されるコンソール向けにゲームを作っている開発チームへの余
談ですが、プログラムの際に地域ごとのテレビの仕様を考慮するようにして下さい。例えば、北米や日
本でゲームを開発していて、欧州版をリリースすることを決めた場合、フレームレート(60fps vs 50fps)
17
や画面サイズの問題に直面するでしょう。もしテレビのフレームレートと無関係に動作するようにプロ
グラムを組んでいない場合は、PAL
TV版は1/5ほどのゲームプレイのスローダウン、ガタガタのアニ
メーションやプリレンダームービー再生、また恐らくは画面上下の大きな黒い帯を持ったものになるか
もしれません。最近のコンソールやデジタルHDテレビはこれらの問題を解決しつつあるので、これらを
解決するためのプログラム方法やムービーの再レンダリングの方法などの詳細にはここでは触れませ
ん。ただ、多くの開発チームにとって開発サイクルの終盤になるまで気づかないローカライズに於ける
落とし穴にｎなりうる問題である為、注意を促しておきます。
開発チームへのアドバイス
プロジェクトのできるだけ早い段階でローカライズチームと協力して下さい。
1.
開発中にローカライズの必要事項を考慮に入れておくことで、後で各言語バージョン毎に何度も何度
も繰り返さなければならない仕事量を減らすことができます。
2. ソース言語のリソースをシステマチックにするほど、コンテンツを翻訳するのに必要な時間を減ら
し、翻訳ミスや文字数制限を超えたエラーを減らし、結果的に品質を上げ、本来であれば次のタイト
ルにかかっていたはずの開発チームを使って修正しなければならないバグの量も減ることになるで
しょう。
3. 標準化されたフォーマットやプロセスに基いて作業することで、わかりきったことを個々にやり直し
たり、開発チームごとの違いに合わせるために時間を使ったりする必要がなくなるため、あらゆる部
署がローカライズに費やす時間が減ります。
4. 地元のレーティング団体だけでなく、ディストリビューターやコンソールメーカーのチェックリスト
を貴社の製品がスムーズにパスするためには明確なコミュニケーションが欠かせません。(例えば、
翻訳者には必要に応じてコンソールメーカーからの最新のインターフェイスガイドラインやその他の
書類を提供するようにしてください。これらは変更されることがしばしばで、ビルドを何度も焼いた
りマスターを再提出するようなことになると、発売を遅らせることも必要になるからです。)
ローカライズはより幅広いユーザーに届けるための通り道であることを忘れないで下さい。別の文化圏
の人に、オリジナル言語版と同じくらいにあなたのタイトルを楽しんでもらいたい（そして、貴社の製
品を買い続けてもらいたい）と願うなら、翻訳チームに与える情報は多ければ多いほど、必要な変更は
取り入れれば取り入れるほど、結果は良いものになるでしょう。
18
ローカライズ
L10Nとも略されるローカリゼーションとは、特定の地域に合った製品を制作するプロセスのことです。
ローカライズされたリソースやアセットの制作、国際化されたビルドにアセットを組み込む作業、テス
ト、編集、バグフィックスが含まれます。ローカライズアセットとは、翻訳されたリソースファイル、
ローカライズされたボイスオーバーのファイル、翻訳されたパッケージ素材、翻訳されたメタデータな
どを含みます。
ビデオゲームのローカライズプロセスは以下の段階に分類できます:
● ファミリアライゼーション
● グロッサリーとスタイルガイドの制作
● 翻訳
● ボイスオーバーの制作
● 言語QA
● マスターアップと承認
翻訳、編集、収録とQAの時期は重なることがあり、スケジュールを最適化するために並行して行われる
ことがあります。各段階がどのように重なりうるかは付録４のサンプルスケジュールを参照してくださ
い。
ファミリアライゼーション
プロジェクトの大小にかかわらず、翻訳者は翻訳を始める前にコンテンツを読んだり見たりして対象の
内容をつかむ必要があります。小説や映画の翻訳者には翻訳を始める前に作品を読んだり見たりするこ
とを期待するのですから、ゲームの翻訳者に対しても内容を教えるようにすべきではないでしょうか？
（複数のストーリー分岐や論理的な順番になっていないテキストファイルなどがあるため、ずっと複雑
な内容ではありますが。）誰がどの程度の時間をかけるべきかは、タイトルのサイズと予算の制限によ
ります。小さめのタイトルについては最低３日程度のゲームプレイと背景資料を読む程度で良いと思い
ますが、前作がローカライズされている場合はあと２日ほどかけてそれらも見ておいたほうが良いと思
います。大規模なMMORPGについては、最低でも１ヶ月はかけてすべてのコンテンツをプレイする必要
があると思われます（たとえデバッグやチートコマンドを使ったとしても。）開発中のタイトルの場合
には、プレイアブルが利用できるようになるまで初期ビルドや企画書類を提供することで良しとしなけ
ればならないかもしれません。
翻訳者はゲームをプレイするにあたって各種の名前やアイデアを記録しておくべきです。また彼らの
ペースを把握するために、毎日または毎週進捗レポートを出させるようにしたほうが良いかもしれませ
ん。デバッグコマンドを使う場合でも、少しぐらいはそれらを使わずにゲームをプレイして、どのよう
な要素がゲームプレイにとって重要であるか理解すべきです。また、マルチプレイヤーモードやオンラ
イン要素も含め、ゲームのすべてのモードやエリアをチェックしておくべきです。初期段階で多くの内
容をカバーしておくほど、後でゲームの内容を確認するために翻訳を中断する必要性が少なくなりま
す。ここで出てくる用語のリストは、後で述べるグロッサリーと照らし合わせて、完全で一貫したもの
になっていることを確認しておくべきです。
グロッサリーとスタイルガイドの制作
翻訳者がコンテンツに習熟したら、開発チームはソース言語のスタイルガイドと発音を含む用例リスト
を翻訳者に提供し、担当言語のグロッサリーやスタイルガイドの土台としてもらうようにすべきです。
続編の場合には、前作の資料も提供して翻訳面での一貫性を保つようにすべきです。そのような書類が
存在していない場合は、翻訳者がソースファイルやファミリアライゼーションの際にとったノートから
作成できるようにすべきです。
小さめのタイトルの場合、一週間もあればすべての要素に名前をつけ、スタイルガイドを作り、メイン
キャラクターやクラスを各々特徴づけることは可能でしょう。大規模なMMORPGの場合、６週間かけて
もすべての名称を完了することはできないかもしれませんが、一般的な方針や各カテゴリーの大半の命
19
名が完了しスタイル化されれば、残りの翻訳は速やかに進むはずです。
翻訳者たちはブレインストーミングを行い、大規模なタイトルで必要な場合には特定のグループに分散
し、またその結果をグループに持ち帰るようにすべきです。そうすることで、チーム全体が関与するこ
とになり、プロジェクトが全体としてどこに向かっているのか理解出来ます。この段階では最後まで残
らないであろうようなアイデアであってもバックアップとして持っておき、後で名前を変更する必要が
出た場合に備えるべきです。もう一度集合して新しいアイデアを考えなおす代わりに、バックアップア
イデアの中から素早く引き出すことができるわけです。またネーミングに関する決定の理由は記録して
おくべきで、特にチームがオリジナルと違った名前にリネームしたり、意図的にオリジナルの名前・
キャラクタ付けから離そうとした場合には重要です。そうすることで後で何度も経緯を確認したりする
手間が省けますし、ある言語の翻訳から更に他の言語に翻訳するような場合（“伝言ゲーム”のようなス
タイルの翻訳の場合）に、他の言語の翻訳者は変更の意図を理解した上で、オリジナルのソース言語に
忠実に行くか、中間言語のリライトに従うかを判断することができます。
実用的なグロッサリーやスタイルガイドなしに、翻訳者が首尾一貫した品質の仕事を提供することは困
難です。 グロッサリーを作成したあとに出てきた新規の名称については、グループやリードが承認する
までは、最初に思いついた名前を仮のタイトルとして記入しておくようお勧めします。その後、新規の
名前をアップデートされたグロッサリーに追加して行くようにすべきです。
開発チームはコンテンツに関する質問に答えられるようにしておくべきです。オリジナルのクリエイ
ターがより多くの情報や答えを提供するほど、よりターゲット言語に馴染み、より幅広いユーザーに
合った仕事が可能になります。
スタイルガイドにはそのタイトルに適用されるすべてのスペル、文法、句読法に関するルールが含まれ
ているべきです。スタイルやスペルに関して特定の文法ガイドや辞書を基本にしている場合は、それを
リスト化して翻訳者が翻訳中に参照できるようにしなければなりません。キャラクター付けに関して
は、そのキャラクターがどのように話すのか、言葉の選択、アクセント、吃音症、などなど説明やサン
プルをリストアップしてください（例えば、単に“イギリス人”とか“普通のアメリカ人”と言うのではな
く、正確な年代、地域、言語レベルなどを実際のサンプルや言葉の選択とともにリストアップするよう
にしてください。できるだけ具体的に述べてください。単に“彼はブラッド・ピットのような喋り方で
す”というのではなく、どの映画のどのキャラクターかまで言うようにしてください。）
アップデートされたグロッサリー、スタイルガイド、参照資料（文法ガイドや辞書）は、テストの段階
ではQAにも提供し参照してもらうべきです。
翻訳
スタイルガイドやグロッサリーが完了したら、翻訳者は実際の翻訳に進むことができます。翻訳者たち
は各々の翻訳を完了する前にお互いにチェックしあうようにすべきです。また可能であれば、専門のエ
ディターやプルーフリーダーを用意して一貫性のチェックをさせることをお勧めします。さらに、一人
の言語担当者がいつもリードとして最終的な判断をするような体制にすべきです。
一般的なルールとして、体験上言えることは、アジア言語については翻訳者３名につきエディター１
名、欧州言語については翻訳者４名までにつきエディター１名という比率が適当かと思われます。エ
ディターは主にターゲット言語に特化して作業しますので、翻訳者ほど流暢にソース言語を話せる必要
はありません。しかしながら、ソース言語に強ければそれだけ、QAが見つける前に翻訳ミスや不統一に
気づく可能性は増えます。
各翻訳者には独自の作業スピードがあり、オーディオスクリプトの翻訳にはUIテキストよりも時間が掛
かります。スケジューリングにあたっては、チームの実測値を持っているのでなければ、翻訳者あたり
一日英語２０００ワード（日本語４０００文字）を標準として使うと良いでしょう。もしオーディオが
含まれる場合は、ボイス部分の翻訳者の作業スピードは、リップシンクや尺合わせの必要度合いにもよ
りますが、半分程度まで落ちると思ってください。また、チームが作業にノッてくるまではスローペー
スになります。ですので、常にスピードをチェックしてスケジュールに影響が出ないかを確認してくだ
さい。
また可能であれば、テキストをゲームに仮表示させて、プロジェクトがQA段階に入る前に翻訳者がテキ
ストを画面で確認する機会を与えてください。実際のボイス収録が始まる前にオーディオスクリプトの
テキストを画面上で字幕として見ることで、翻訳者はレコーディング段階の前にテキストをブラッシュ
アップする機会を得ます。このことはまた、テキストの長さやオーディオタイミングの問題について初
期段階で気づくことにもつながります。
20
ボイスオーバー収録
タイトルにオーディオが含まれる場合、一般的にはまずレコーディングスクリプトを翻訳し、プロジェ
クトの最後には追加の収録が出来る余裕を持たせ、そこで新しいセリフを収録したり、最終的なローカ
ライズ承認の前に見つかったオーディオバグを修正したりすることができるようにします。ト書きも翻
訳しなければなりません（または必要であれば指示自体をローカライズしなければなりません。）どの
セリフが映像に合わせて尺合わせの必要があるか、リップシンクの必要があるかも特定してください。
ゲームがより大規模に複雑になるにつれ、収録、管理すべきオーディオの量は扱い難いものになりつつ
あります。開発チームは自分たちのシステムが大量のファイルを扱えることを確認する必要があります
し、すべての最終ファイル（使われないテイクは除いたもの）は整理された方法で開発チームに提供さ
れねばなりません。
キャスティングについては、キャラクターのボイスを本当の意味でローカライズすることを恐れないよ
うにしてください。例えば、アジア言語では甲高い女性の声を好みますし、西洋の言語では低い声が好
まれます。ですから、各翻訳チームに同じような声に聞こえることを強制するのではなく、それぞれの
言語にとって何がベストなのかを決めさせるようにしてください。ユーザーが異なる言語間でボイスを
比較することは稀ですので、ターゲット言語にとって最適なボイスにすることがより重要であると思い
ます。
翻訳者は常にレコーディングに参加して、オーディオディレクターや声優に内容を説明するようにすべ
きです。またタイミング等の問題でその場でテキストを変更しなければならない場合があるので、翻訳
者は必要です（収録中に変更した内容は字幕でもアップデートすることを忘れないようにしてくださ
い。）
コストのかかる失敗を避けるために、以下のことをお勧めします:
見積もりを依頼する
● ベンダーが正確な見積もりを提供できるように、オーディオに関する詳細な情報（ラインカウント、
ワードカウント、声優の人数、セリフごとの尺制限）に基づいた見積もりを依頼するようにしてくだ
さい。ソース言語の収録時間などの情報に基づいた見積もりは、実際と相当な差異が生じる可能性が
あります。
スクリプトの準備と翻訳
● ト書きが明確であり、またそれらを翻訳するための時間や予算があることを確認してください（収録
スタジオがソース言語を読むことができない可能性もありますし、翻訳者がキャストのキャラクター
付けを変更する可能性もあるので、そのための準備をしておくことが賢明です。）
● 翻訳の前にどのセリフに尺合わせやリップシンクが必要かを特定し、英語のオーディオファイルをス
クリプトと一緒に提出するようにしてください。尺合わせの必要なセリフは、セリフとゲーム内のア
クションが密接にマッチしていなければならないイベントやシーンで発生します。リップシンクのセ
リフは、話者の唇が見えるようなクローズアップのカットシーンなどで発生します。もちろん、（
FaceFXのようなシステムを使用して）各言語ごとに唇の動きが調整されるのが好ましいのですが、
全ての言語で英語のセリフ用にアニメーションさせた唇のムービーが使われることも珍しいことでは
ありません。リップシンクや尺合わせのセリフのボイス収録には、通常の４倍程度も時間がかかる場
合があることにご留意ください。
● リップシンクの必要なセリフには、翻訳チームとレコーディングチームに参考映像を提供してそれに
合わせるようにさせてください。参考映像が用意できない場合は、ローカライズチームがリップシン
クにとても良く似た音節合わせを行うこともできます。
● どのセリフはワイルド（制限なし）で収録して良いかを特定し、すべてのセリフが適切な収録条件
（尺あわせ、リップシンク、ワイルド）で扱われるようにしてください。
● また、ターゲット言語とオリジナルの間の尺の差にどれくらいのゆとりが許されるのか明確にしてく
ださい。もしすべてのセリフがオリジナルのタイミングや唇の動きに完璧にマッチしていなければな
らないとすれば、大変コストもかかり収録にも時間がかかることになるでしょう。一方、セリフの話
者も登場しないしセリフのタイミングも融通がきくのであれば、翻訳も収録も迅速に進むでしょう。
● ファイルの命名規則は理論的なものであるようにして、ファイルを再注文した場合などに、収録スタ
ジオがランダムに名づけされたファイルを求めてあらゆるキャラクターやシーンを横断的に探さねば
ならないような事態にならないようにしてください。
● ゲームで使用するテイクはすべてできるだけ早く選び、最終のスクリプトと実際のファイナルテイク
21
●
●
●
がマッチするようにしてください（収録中に行った変更はゲームプログラムのみに反映され、オリジ
ナルスクリプトには反映されない場合があり、どちらが正しいのかわからなくなることがありま
す。）
異なるシーン間でボイスファイルを再利用することは避けてください（ソース言語においては様々な
状況で同じファイルを再利用することはできるかもしれませんが、ターゲット言語においては単数・
複数の問題、男性・女性・中性の問題などで翻訳を変更する必要があるかもしれないからです。）
話をしている相手が誰なのかが明確になるようにスクリプトのフォーマットを整えてください。そう
することでスタジオは、話をしている二人のキャラクターを同じ声優が演じるような事態を避けつ
つ、複数のシーンやファイル間で声優を再利用することが可能になります。
明確な言葉が含まれていないソース言語の叫び声などを他の言語でも使いまわせると思わないように
してください。リアクションボイスは言語や文化によって大きく異なります。これらのファイルはス
クリプトに加えて、他の言語で再利用できるかどうかを翻訳チームに尋ねてみてください。
多言語キャスティング
● ローカライズチームのために、キャラクターの説明（年齢、性別、声のタイプ、キャラクターの背景
情報、似たような声の有名人、など）、キャラクターの画像、サンプルボイスなどで構成されたキャ
スティングパッケージを作成するようにしてください。
● ソース言語で有名な声優が使われている場合は、どの言語で有名な声優が必要かを決めてください。
こういう状況は、海外市場でローカライズされている映画やTV番組に関連するゲームにおいてしば
しば発生します。有名な声優はギャラも特別であることがしばしばで、使える時期についても制限が
あるため、プロジェクトの予算やスケジュールに影響を与える可能性があります。
● ゲームの鍵となるキャラクターについてはデータベースまたはライブでのキャスティングを要求して
ください。データベースキャスティングはスピードも早く安価で、スタジオは大抵３タイプ程度のボ
イスサンプルを提供してその中から選ばせます。ネイティブスピーカーやキャスティングの専門家を
用意してサンプルを評価させ、キャラクターと一致しているか検討してください。
● ゲーム中あまり重要でないキャラクターについては収録スタジオにキャスティングさせるようにして
ください。レコーディングスケジュールとコストは大変複雑ですので、こうすることでスタジオは二
次的な役割のキャラクターに声優を再利用することが可能になり、あなたの時間やお金をセーブする
ことにもなります。これはスクリプトの中で相手を特定することが重要であることの理由の一つで
す。会話しあう二人のキャラクターを同じ一人の声優が演じるというような、意図していない状況を
避けるためです。
オーディオファイルのスペック
● ボリュームのバランスを取った英語のファイルをボリュームのノーマライズ用として多言語を担当す
るスタジオに渡してください。
● 多言語のファイル納品の際に希望するファイル構成に沿った形式で英語のファイルを提供してくださ
い。各ファイル名の最後に言語コードを付加するようスタジオに指定しても良いでしょう。
● 多言語収録スタジオに対し納品の際に使用してほしいフォーマット、ビットレート、周波数、チャン
ネル数を指定するようにしてください。
● オーディオファイルに必要なポスプロ効果を指定してください。キャラクターの中には、リバーブや
ピッチ移動、オーディオデザイナーによる特殊効果などが必要なものがあるかもしれません。
● ボイスファイルのボリュームは言語間で変更できるようにしてください（一般的なボリュームレベル
を指定することはできますが、大量のオーディオを扱い始めるとボリュームを調整しなければならな
いファイルが出てくることは避けられません。この場合、収録スタジオやサウンド部門に各ファイル
のボリューム修正を手作業で行うように依頼するよりは、オーディオ再生システムに行わせるように
したほうが良いでしょう。）
言語QA
テスターは、ターゲット言語の優秀な言語専門家と優秀なゲームプレイヤーから構成されているべきで
す。チームサイズはプロジェクトのサイズやスケジュールによって様々です。会社によってはテスター
に見つけたバグを修正させる場合もありますが、もし予算やスケジュールが許せば、オリジナルの翻訳
者のみが修正できるようにしたほうが良いでしょう。意図的な変更やキャラクター付けがバグと誤解さ
れる場合がしばしばあるからです。しかしながら、翻訳者はそれらのバグを見送るにあたって、それら
が意図的な変更であることを証明できる必要があります。またテスター達が一般的な提案をできるよう
に（そしてより重要な問題の優先を上げるためにそれらをバグと一緒にしないように）してください。
22
バグが（予想外の副作用なしに）間違いなく修正されているかを確認する作業は、各ビルドにおいて複
数回行うべきです。間違って古いテキストが新しいビルドに入っている場合がしばしばありますので、
複数回チェックすることは重要です。
また明確な方針を持つことは大切です:
終的な決定を下すなど。
例えば、QAと翻訳者の見解が異なる場合は、リード翻訳者が最
マスターアップと承認
マスターアップのフェイズでは最終的な変更を行うために翻訳者が待機していることをお勧めします。
QAに加えて、一人か二人程度の翻訳者がゲームを通してプレイし、翻訳が適切に組み込まれ、生産、発
売に向けて問題がないことを確認しておくべきです。
パッケージや書類の翻訳に加えて、このフェイズでは大量のプロモーション的な翻訳やガイドブックの
チェックが行われることが通常です。ですから、ゲームが承認されたあとであっても言語の専門家を待
機させておいてください。
MMORPGSに関するヒント…
基本的に各コンテンツパッチを独自のローカライズサイクルと考え、上述の各段階を小規模なスケール
で実行してください。これは新しいコンテンツが出来るたびに、翻訳者たちはそれに対するファミリア
ライズとブレインストーミングを行う必要があるということです。
不必要なリライトを防ぐため、必ず開発チームから翻訳者に対してどの部分を訳して良いか伝えるよう
にしてください（例えば、交通信号のようなシステムを使っても良いでしょう: 緑=ソース言語はほぼ固
まっており翻訳を始めても良い; オレンジ=まだマイナーな修正はあるかもしれないが、緑のテキストが
もうない場合には翻訳を始めても良い; 赤 = まだソーステキストが安定しておらずリライトが必要かも
しれないので翻訳は自分のリスクでやること）オリジナルソースのライターから翻訳者がどれくらい遅
れているかを常にチェックし、翻訳者とQAに追いつくための十分な時間を与えるためにはオリジナルラ
イターに新しいコンテンツを追加するのを中断するよう指示するのを忘れないようにしてください。
翻訳者は大規模なタイトルの場合間違いなくある特定のエリアに特化しがちです（一人がクエストテキ
ストやある地域のアクセントを担当、別の一人がアイテムのネーミングを担当、また別の一人がイン
ターフェイスを担当など。）長期間に渡るプロジェクトでは疲労が蓄積しがちなので、クリエイティビ
ティーやモチベーションを高く保つために、時々役割やプロジェクトを入れ替えるのも良いかもしれま
せん。こういう場合、よくできたスタイルガイド、グロッサリー、また移行期間・トレーニング期間な
どが一貫性やクオリティーを保つ点で役立ちます。
23
プロジェクトのプランニング
このセクションでは過去に議論された多くの良い方法や典型的なゲーム開発プロセスについて説明しま
す。プロセスや期待する内容は会社によって大きく異なりますし、プラットフォームごとに採用される
手法も変わっていくものなので、これは単にガイドとして使用されることを意図しています。
プリプロダクション
●
●
●
これはプロジェクトの発売計画が決定される段階です。 – プラットフォーム、言語、初期のプロ
ジェクト予算、発売日など。
初期のあらすじ、企画、コンセプトアートなどができたら、その製品に関する潜在的なカルチャライ
ズの問題について検討し始めることができます。
ローカライズ、QA、カルチャライズ評価に関するベンダーの選択、契約書の用意、チームの構成な
どを行います。
プロダクション
●
●
●
●
●
●
●
ローカライズプロジェクトの開始 – プロセスや初期スケジュールについての合意、必要であれば開
発スタッフに対してローカライズに関するまとめを提供する。初期のスケジュールには英語スクリプ
トの確定、英語オーディオの完成時期が含まれていなければなりません。またスケジュールには言語
テストのサイクルや仮のビルドスケジュールも含まれているべきです。
できるだけ早くグロッサリーやスタイルガイドを準備し、ファミリアライズを開始する。
キャラクタープロフィールが用意でき、部分的に英語オーディオが収録されたら、キャスティングプ
ロセスを始めることができます。ローカライズベンダーと協力してキャラクターごとのセリフの数、
ワードカウントの概算、キーキャラクターと二次的なキャラクターの洗い出しなどを行なってくださ
い。ベンダーが声優をブッキングするために、キャスティングから多言語収録の当日まで最低でも２
週間はみてください。
スクリプト翻訳と多言語ボイス収録のプロセスをおさらいしてください; 最初の多言語ビルドへの組
込作業の前に、ボリュームバランス調整、ポスプロ、ファイルネームチェックの時間を十分取るよう
にしてください。
インターフェイスとインゲームテキストの翻訳を始めてください。通常翻訳者の翻訳ペースは一日
2000ワード程度であることにご留意ください。また、英語の段階で完成度の高いものにすればする
ほど、後ほど他言語での変更が少なくて済むことをご理解ください。
開発チームと協力してテキストをシームレスにインポート、エクスポートする技術を含め、多言語ビ
ルドに求められる内容を確定してください。テキストアップデートと新しいビルド制作の実験を行
なっておいてください。
プロダクションフェイズの終わりには、すべてもしくはほとんどのローカライズされたテキストと
オーディオが組み込まれた安定したビルドを入手しているべきです。
アルファ
●
●
●
多言語のテストプロセスをおさらいし、すべてのローカライズアセットが揃っていること、各言語に
おけるすべてのフォントが動作していること、ユーザーインターフェイスが長めの翻訳文にも対応で
きること、などを確認してください。開発チームによっては、最も長い単語を使用した単一言語のビ
ルドを作成し、ユーザーインターフェイスにとって最悪のケースのストレステストをを行う場合もあ
ります。
すべての多言語バグが修正されたビルドが用意できたらローカライズQAを始めることができます。
この時期はバグフィックスと新規の翻訳リクエストが重なるので最も忙しい時期となりがちです。
行うべき作業の最新スケジュールを管理し、パートナーとの連携を強化しておくことがこの時期に発
生しがちな摩擦を減らすことになるでしょう。
英語の変更点に関する最終的な確定日を開発チームからもらってください; ローカライズはソーステ
24
●
キストに依存するので、英語が変更され続ければローカライズプロセスを確定することは不可能にな
ります。
必要であれば、二回目の多言語ボイスオーバー収録を行い、メジャーなバグやスクリプトに追加され
たセリフの収録を行なってください。
ベータ / ローカライズ承認 / ゴールドマスター
●
●
すべての翻訳リクエストが完成し、すべてのローカライズ問題が解決したら、会社に対して承認を出
し全世界での発売を進めてください。おめでとうございます！
その後時間が経ち過ぎないうちに、簡単なポストモーテムを行い将来のプロジェクトで使用すべきア
イデアを書き留めてください。
25
付録 1 – 最良の方法のリスト
カルチャライズ
1. その製品で実現したいカルチャライズの程度を決める; 実行可能で、明瞭な、意味のあるものにする
こと。
2. ターゲット市場に適用される上位4つの文化的な要素を意識する; 歴史、宗教、民族性、地政学的な
想像力。
3. カルチャライズ上の潜在的な問題を特定し、それらの深刻さを見極め、コンテンツに修正を施す。
4. コンテンツの修正は正確さをもって行うこと – ターゲット市場で発売し、発売後の問題発生を防止
するために最低限必要な変更のみを行うこと。
多言語化
5. フォント選択とサイズ調整は、ローカライズと開発チームの協力で実現される。
6. プロポーショナルフォントは北米、欧州言語に使用; アジア言語には固定幅フォントが必要です。
7. 長い翻訳でも問題がないようなインターフェイスをデザインするか、言語ごとにテキストの位置を変
更できるシステムを提供してください。
8. 複数行のテキストを含むエリアでは、ワードラップのシステムを入れ翻訳が長すぎる場合にはテキス
トがスクロールするようにしてください。
9. 一行のテキストしかないエリアでは、カーニングを可能にして長い翻訳を収めるようにしてくださ
い。
10. 字幕については、ダークな縁取りで明るい色のsan serifフォントを使用してください。字幕は画面の
下3分の1の位置に一度に3秒間表示するようにし、一度に表示するテキストは3行以下にしてくださ
い。話者の変更は、セリフにハイフンでつなげることで示すようにしてください。
11. ローカライズアセットは簡単にアクセスできるフォルダーに格納し、直接インポートやエクスポート
ができるようにしておいてください。
12. 特定地域に向けたアセットのマーキングには ISO 639-1 & 3166-1 言語名、国名コードを使用してくだ
さい。
13. ローカライズ作業を自動化するツールの開発期間や予算は別枠で持つようにしてください。
14. テキストアセットについては、すべてのターゲット言語をサポートするエンコーディングを選択して
ください。
15. ユーザーインターフェイスやゲームワールド内のアートアセットに判読可能なテキストが含まれてい
る場合は、入れ替える準備をしておいてください。
16. リソースファイルにはゲーム内で使われるすべてのテキストが入っているべきです; ソースコード中
でテキストをハードコードすることはやめてください。
17. リソースファイルは言語ごとに別のファイルにし、すべての翻訳者が並行で作業できるようにしてく
ださい。プラットフォームに特有の文字列については特定し、翻訳者がコンソールメーカーの指定用
語に沿えるようにしてください。
18. 各ローカライズビルドごとに、ソース言語のテキスト変更リストを提供するようにしてください。
19. 翻訳作業にあたっては、プレインテキストやExcelファイルよりもXMLやそれから派生したフォー
マットが好ましいです。
20. ローカライズされた文字列における変数の順番は言語ごとに変更できるようにしておき、トークンシ
ステムを組み込んで名詞、動詞、冠詞などが言語ごとにどのような順番でも配置できるようにしてく
ださい。
21. 日付、時間、通貨、数字は、言語ごとに異なった文字や記号で表示できるようにしておいてくださ
い。
22. 翻訳でアルファベット順が変わる可能性があるので、テーブルは言語ごとにソートできるようにして
おいてください。
23. 複数行に渡るテキストボックスには自動改行とワードラップの機能を組み込んでください。どこで改
行が入るかは言語ごとに異なります。改行システムは改行されないスペース(0xA0)などの文字を手
入力することでキャンセルされるようにしてください。
24. あなたのゲームがヨーロッパで発売される場合はPAL 60Hzモードをサポートするようにしてくださ
い。
26
ローカライズ
25. 翻訳チームが翻訳に先立ってゲームに親しむ時間を持てるようにしてください;
その際には、ビル
ド、ストーリーのあらすじ、コンセプトアート、企画書類、あれば脚本や前作資料などを共有するよ
うにしてください。
26. 翻訳者たちはゲームの中身に親しむに連れて名称やアイデアに関する知識を身に着けていくはずで
す。
27. ソース言語のスタイルガイド、グロッサリー、重要な固有名詞の発音などを翻訳チームに提供してく
ださい。翻訳チームは各ターゲット言語に対するスタイルガイドやグロッサリーを作成します。
28. 翻訳リクエストを出す前に、ソース言語のテキストのスペル、文法、スタイルチェックを行うべきで
す。
29. スケジュールを立てる際には、最低でも一日2000ワード、プラス翻訳者が追加の情報を求めた場合
の予備日一日で考えてください。
30. 言語QAの前に翻訳をビルドに組み込む実験を行なっておいてください。また可能な限り、オーディ
オ収録に先立って翻訳者が字幕をプレビューできるようにしておいてください。
31. すべての言語で同じディレクターが使えるように、またスタジオのレンタルコストを最小化するため
に、一回のセッションでローカライズされたオーディを収録するように努めてください。プロジェク
トの終わりにかけて緊急の追加セッションを計画しておき、深刻なバグの修正や新たに追加された
ソース言語のセリフを収録してください。
32. Provide detailed プロジェクトの詳細な情報をローカライズベンダーに提供して正確なレコーディン
グ見積もりをもらってください。最低でも、おおよそのセリフ数、声優の人数、収録の制限に関する
情報は必要です。
33. オーディオスクリプトには、ファイル名、話者、英語のセリフ、収録の制限（尺合わせ、リップシン
ク、ワイルド）の情報が含まれていなければなりません。スクリプトは時系列に並べ、会話が文脈の
中で理解でき、登場人物が特定できるようにしてください（複数のキャラクターを演じる声優にとっ
て大変重要な情報です。）
34. ローカライズベンダーに渡すキャスティングパッケージには、キャラクターの説明、画像、ソース言
語のボイスサンプルが含まれていなければなりません。
35. レコーディングスケジュールの管理が楽になるように、あまり重要でないキャラクターのキャスティ
ングはベンダーに任せるようにしてください。
36. 多言語キャストを選択してから声優をブッキングするまでに最低でも2週間は見てください。
37. ローカライズベンダーに使ってもらいたいオーディオファイルのフォーマット、ファイルのネーミン
グ、フォルダー構造、ポスプロ効果を特定するようにしてください。また、ボリュームのバランス調
整を行ったソースファイルを提供して、スタジオがそれを元にボリュームのノーマライズを行えるよ
うにしてください。
38. 各言語における優秀な言語専門家と優秀なゲームプレイヤーからなる言語QAチームを選択するよう
にしてください。
39. ローカライズアセットについて書かれたバグはローカライズベンダーに、多言語化について書かれた
バグは開発チームに報告するようにしてください。
40. 言語QAチームは、すべてのバグが間違いなく修正されたことを確認すべきです。
41. プロジェクトの終盤には、スタッフに連絡が取れるようにしておき、ギリギリで出たバグやコンテン
ツ変更にすぐに対応できるようにしてください。
42. すべてのローカライズコンテンツがゲーム内で適切に機能し、すべてのローカライズバグが修正され
たら、言語QAチームにゲームクオリティーに関する承認を要求してください。
27
1. 歴史: 過去と現在
1. Age of Empires (1997)
:
Age of Empiresでは日本のYamato軍が朝鮮半島を侵略し、効果的に朝鮮
政権を圧倒したというシナリオになっています。歴史家によるとこれは事実であり、ゲームデザイ
ナーは正確に事実を再現したわけです。しかしながら、韓国政府は歴史を異なった見方をしており、
シナリオの正確性に対して異議を唱え、ゲームの販売を認めませんでした。シナリオを少々変更する
ためのダウンロードパッチが制作され、ゲームの世界ではYamato軍の侵略はそれほど圧倒的なもの
ではなく、朝鮮軍には反撃のチャンスがあったということになりました。
2. Six Days in Fallujah (2009)
: 本作は２００４年後半、米英イラクの軍隊がファルージャを基地と
する反乱軍を壊滅させるために行ったファルージャの戦闘を再現しています。戦闘は両軍にとって高
価な代償を伴うものとなり様々な論争を呼びました。連合軍は１００人以上の死者と６００人以上の
負傷者を出し、反乱軍は１３００人以上を失いました。もしこの出来事から数十年経過していたなら
大変説得力のあるゲームシナリオになっていたでしょうが、あまりにも最近の出来事であったがゆえ
に潜在的に大変な怒りを掻き立てる可能性があったためコナミはあえて発売を取りやめました。
2. 宗教と信念体系
1. Kakuto Chojin (2002)
: この対戦格闘ゲームは初期のXboxゲームライブラリーの重要な一作とな
ることを期待されていました。しかし、残念なことにイスラムのコーランの詠唱部分を含むオーディ
オトラックがゲームに含まれていたのです。このエラーは修正されましたが、未修正のディスクが何
本か店頭に並んでしまい問題は数週間の内に広く知られるようになりました。そしてこのゲームはサ
ウジアラビアとその他のイスラム諸国数カ国で発売禁止となり、反発があまりにも広まったため結局
世界中で発売中止となってしまいました。開発チームの大変な努力と善意は、実質的にほんの僅かな
コンテンツによって無になってしまったのです。
2. Resistance: Fall of Man (2006)
: このゲームがイギリスで発売された時、英国国教会は自分たち
のマンチェスター大聖堂がゲーム中で精巧に再現されていることを知りショックを受けました。ただ
精巧に再現されていることだけではなく、その教会の中で暴力的な行為が行われていることを知り、
英国国教会は大変不快に感じたのです。結果、ソニーは謝罪することになり、英国国教会はビデオ
ゲーム開発者やその関係者が宗教的な建物に敬意を払う上での手助けとなることを期待して、新た
に”宗教に関するデジタルガイドライン“を発行することになったのです。
3. 民族性と文化的な摩擦
1. Resident Evil 5 (2009)
: 発売前から、本作はその人種差別とみなされる内容でかなりのネガティ
ブな評判を集めていました。ゲーム中では、典型的な白人の主人公がサハラ以南のアフリカの村で丸
腰の明らかに困窮しているアフリカ人の村人を射殺しています。パブリッシャーであるカプコンはす
ぐにアフリカの村人たちは感染したゾンビであると説明しましたが、白人が黒人の村人を殺している
という明確なイメージは非常に強力なネガティブイメージを生みました。”偉大な白人のハン
ター”、”未開のアフリカ大陸”といった概念がすぐに多くの人の心に浮かんだのです。開発者の側に
はゲームの文脈においてこのような対立の論理的根拠は明確にあったのですが、反発の大きさはその
ようなネガティブなイメージを模倣することが適当であるのかについて、パブリッシャーに立ち止ま
り考えさせるのに十分なものでした。
2. Pocket God (2009)
: このiPhone用ゲームにおいて、プレイヤーは小さな空想上の島の”神”であ
り、サメの餌にする、高いところから落とす、熱い溶岩を垂らす、人喰いアリに食べさせる、などの
方法で原住民たちを苦しめることができます。ゲームの開発社であるBolt Creativeは、このゲームが
特定の国を表現したものではないと明確に述べています。しかしながら、島にある様々な工芸品
（イースター島にあるモアイ像の頭を含む）や、原住民の服装や濃いめの肌の色から、”原始的な”民
族イメージを悪用しているとして太平洋諸島の人々に苦情や抗議をさせるには十分でした。
4. 地政学的な想像力
1. Hearts of Iron (2004)
:
Hearts of Ironというゲームとその続編では、ゲームのマップが著名な
ボードゲームであるRiskに似た任意のセクターに分けられています。第二次世界大戦中を舞台とする
Hearts of Ironでは、中国はいくつかの特徴ある部分に分かれており、チベットや台湾は別の地域と
して描かれています。時代的には第二次世界大戦時でありチベットも台湾も中華人民共和国には属し
ていなかった（１９４９年までは中華人民共和国は存在せず、台湾は今でも中国本土から独立してい
るのですが）にも関わらず、中国政府はこのことを理由としてゲームを発売禁止にしました。歴史
的、地政学的事実は、自身のテリトリーに関する認識をあらゆる意味において強化しようとする政府
にとって二次的な意味しか持たないのです。
2. Ghost Recon 2 (2004)
: 韓国で、Korea Media Rating Board (KMRB; 現在のGame Rating Board＝
GRB) はこのゲームに交戦国北朝鮮の将軍が登場しているという理由で発売禁止にしました。韓国政
28
府は、二国間の現在進行形の緊張状態、また長期に渡る韓国の北との再統一の意思を理由として、北
を敵対国として描くことを厳しく禁じています。KMRBは同じ理由で２００５年のMercenariesとい
うゲームの販売も禁じています。ただ2007年には、GRBは言論の自由に反するという地元ゲーマー
のプレッシャーにより方針を変え、
Ghost Recon 2のようなタイトルの発売を認めています。
29
付録３ – 文法的なトークンの例
実際のトークンの名称とともにより詳細な説明を下記します（ソースコードではありません。大部分の
プログラマーにとって組み込みはそれほど難しいものではないはずですが。）
以下の様なアイテムテーブルがあると思ってください。。。
SING SING SINGULAR
PLR
PLR
PLR INDEF DEF
ITEM NAME
INDEF DEF
ITEM NAME a
the
sword
some the
swords an
the
axe
some the
axes some the
potion
some the
potions the
the
Masamune
some the
Masamune Excalibur
some the
Excaliburs ...
...
...
...
...
... このテーブルから、ゲーム中で発生している内容に従って、リアルタイムで引き出される以下のトーク
ンを定義することができます（ここでは“xxx”と“itemx”を使用していますが、これらは任意の変数で構い
ません。）
* <SGL_I_NAME_xxx> アイテム名の単数形をプリントアウトする。 (現在までのすべてのゲームにおける、ほぼデフォルトのアイテムトークン。) e.g. You got 1 x <SGL_I_NAME_itemx>. → You got 1 x sword. * <PLR_I_NAME_xxx> アイテム名の複数形をプリントアウトする。 e.g. The thief stole all your <PLR_I_NAME_ itemx >! → The thief stole all your swords! * <INDEF_ART_SGL_I_NAME_xxx> 単数のアイテム名の前につながる続く不定冠詞をプリントアウトする。 e.g. Richard found <INDEF_ART_SGL_I_NAME_ itemx >. → Richard found a sword. → Richard found an axe. → Richard found the Masamune. → Richard found Excalibur. * <DEF_ART_SGL_I_NAME_xxx> 単数のアイテム名の前につながる定冠詞をプリントアウトする。 e.g. Richard places <DEF_ART_SGL_I_NAME_ itemx > into the carry bag. → Richard places the sword into the carry bag. → Richard places the axe into the carry bag. → Richard places the Masamune into the carry bag. → Richard places Excalibur into the carry bag. * <INDEF_ART_PLR_I_NAME_xxx> (...おそらく英語では不要？ FIGSで重要。) 複数のアイテム名の前につながる複数の不定冠詞をプリントアウトする。 e.g. Richard found <INDEF_ART_PLR_I_NAME_ itemx >. → Richard found some swords. → Richard found some axes. (→ Richard found some Excaliburs. ...おそらくありえないと思いますが、念の為です。) * <DEF_ART_PLR_I_NAME_xxx> (...おそらく英語では不要？ FIGSで重要。) 複数のアイテム名の前につながる複数の定冠詞をプリントアウトする。 e.g. Richard places <DEF_ART_PLR_I_NAME_ itemx > into the carry bag. → Richard places the swords into the carry bag. → Richard places the axes into the carry bag. (→ Richard places the Excaliburs into the carry bag. ...多分ないと思いますが、念の為です。) 30
* <NUM_I_NAME_xxx, val_yyy> 二番目のパラメーターval_yyyに数字を、その後に数字が1であれば単数形を、そうでなければ複数形を
プリントする。 e.g. You buy <NUM_I_NAME_ itemx, 1>. → You buy 1 axe. e.g. You buy <NUM_I_NAME_ itemx, 2>. → You buy 2 axes. * <DEF_ART_NUM_I_NAME_xxx, val_yyy> パラメーターval_yyyの数字が1であれば、単数の定冠詞に続けて単数の名称をプリントする; そうでない場合はval_yyyの数字に続けて複数の名称をプリントする。 e.g. Richard places <DEF_ART_NUM_I_NAME_ itemx, 1> into the carry bag. → Richard places the sword into the carry bag. e.g. Richard places <DEF_ART_NUM_I_NAME_ itemx, 5> into the carry bag. → Richard places 5 swords into the carry bag. (複数形用に数字をプリントする代わりに、複数の定冠詞をプリントする、同様のトークンを作ること
も可能です。 e.g. "Richard places the swords into the carry bag.") * <INDEF_ART_NUM_I_NAME xxx, val_yyy> パラメーターval_yyyの数字が1であれば、単数の不定冠詞に続けて単数の名称をプリントする; そでなければval_yyyの数字に続けて複数の名称をプリントする。 e.g. Richard buys <INDEF_ART_NUM_I_NAME_ itemx, 1>. → Richard buys a sword. → Richard buys an axe. e.g. Richard buys <INDEF_ART_NUM_I_NAME_ itemx, 5>. → Richard buys 5 swords. → Richard buys 5 axes. (複数形用に数字をプリントする代わりに、複数の不定冠詞をプリントする、同様のトークンを作るこ
とも可能です。 e.g. "Richard buys an axe." & "Richard buys some axes.") * MALE/FEMALE TOKEN: <IF_MALE>...<ELSE_NOT_MALE>...<ENDIF_MALE> 主導的なパーティーメンバーが男性なら、前半の'...'部分をプリント、そうでなければ後半の'...'部分を
プリント。 e.g. "Why, hello there <IF_MALE>handsome boy<ELSE>pretty girl<ENDIF>!" ...リードキャラクターが男性なら、以下のようにプリント... "Why, hello there handsome boy!" ...そうでなければ以下のようにプリント... "Why, hello there pretty girl!" これはテキストにキャラクター性を加えるのにも使えると思いますし、必要なら他のパーティーメン
バーにも拡張できると思います。ただ、RPGではパーティーのリーダーに言及されることがしばしばな
のでこうなっています。 * SOLO/MULTIMEMBER PARTY TOKEN: <IF_SOLO>...<ELSE_NOT_SOLO>...<ENDIF_SOLO> パーティーが一人のアクティブな（生きている）メンバーのみで構成されている場合は、前半の'...'部
分を; そうでなければ、後半の'...'部分をプリントします。 英語では、”you”は単数と複数両方のシチュエーションをカバーするのでおそらく”you”で問題無いと思
います。（日本語、中国語、韓国語には複数の“you”が存在するので、これが役に立ちます。またヨー
ロッパ言語の中には”you”の人数によって名詞と関連する文法の両方が変化するものがあるので、これが
大変役に立ちます！）
基本的に、パーティーが一人のパーティーメンバーのみで構成されている場合は、以下のことが可能で
す...
e.g. 1) Hello <IF_SOLO>you<ELSE_NOT_SOLO>you guys<ENDIF_SOLO>! 31
e.g. 2) <IF_SOLO>You should get your head fixed.<ELSE_NOT_SOLO>You people should get your heads fixed.<ENDIF_SOLO> * 単数/複数トークン: <IF_SING val_xxx>...<ELSE_NOT_SING>...<ENDIF_SING> 数値を伴うものならなんにでも使える素晴らしいトークン。 val_xxxが1なら、前半の'...'部分をプリント; そうでなければ後半の'...'部分をプリント。 明白な使用方法: "You receive <val_1> gold <IF_SING val_1>piece<ELSE_NOT_SING>pieces<ENDIF_SING>. (明確さよりも短さを好む場合は: "You receive <val_1> gold piece<IF_SING val_1><ELSE_NOT_SING>s<ENDIF_SING>." ) → "You receive 1 gold piece." → "You receive 2 gold pieces." 一般的な発言の場合もより良くすることができます。 e.g. <val_2>が少年の人数を表す数を含んでいるとわかっている場合は: <IF_SING val_2>That boy<ELSE>Those boys<ENDIF> will never grow up. → That boy will never grow up. ... if <val_2> == 1; → Those boys will never grow up. ...otherwise. ゲームによっては、以下の様な複雑なセンテンスでも扱うことができます... "<Cap><ART_NUM_M_NAME_mon_no, num_of_mons> gave me <IF_SING num_of_mons>his<ELSE>their<ENDIF> <PLR_I_NAME item_no>." ...同じ一つの文からあらゆる出力形態を得るために... → "A goblin gave me his apples." → "5 goblins gave me their apples."
→ "An anaconda gave me his potions." → "3 anacondas gave me their potions." * 文法的に男性/女性/中性のアイテム名を差別化する <IF_NAME_xxx_M>...<IF_NAME_xxx_F>...<IF_NAME_xxx_N>...<ENDIF_NAME_xxx> (xxxはテスト対象の変数です。) ヨーロッパ言語については、アイテム名の隣に欄を追加してM/F/Nを示すようにし、このデータと上述
のトークンを使用することでより自然な文を作成します。 e.g. 例えば<item_1>を手に入れて、そのアイテムを呼ぶのに'it'を使用したいとします。英語ではそれ
は... You put it in your bag. ドイツ語では以下のように書けます... Du tust <IF_NAME_1_M>ihn<IF_NAME_1_F>sie<IF_NAME_1_N>es<ENDIF_NAME_1> in deine Tasche. もちろん、その言語に男性と女性しかなく中性がなければ、名前の隣の欄にはMかFのみ記入し、翻訳
においてはトークン中でそのオプションは空白にしておきます。 e.g. イタリア語では... <IF_NAME_1_M>Lo<IF_NAME_1_F>La<IF_NAME_1_N><ENDIF_NAME_1> metti nella borsa. 同様に、これらの語が以下の条件を満たしているかによってフラグを立てる欄を追加することもできま
す: ● 母音や子音で始まる、終わる ●
固有名詞であるか否か ●
2つで1つのアイテムか否か (e.g. ズボン、ソックス、メガネ) そうすれば上記に似たようなトークンを作成し、リアルタイムでテーブルの名称の列を見てフラグを判
定し、リアルタイムでテキストを分岐させることができます。 e.g. <IF_VOWEL_x>...<ELSE_CONSONANT_x>...<END_IF_VOWEL_x> もし与えられた名前の最初の文字が母音なら、前半の'...'部分をプリントする; そうでなければ後半の'...'部分をプリントする。 e.g. An orb glows at <leader>'s feet. 32
Un orbe luit aux pieds <IF_VOWEL_HERO>d'<ELSE_CONSONANT_HERO>de <END_IF_VOWEL_HERO><HERO>. <IF_x_PR>...<ELSE_x_NOT_PR>...<ENDIF_x_PR> xが固有名詞の場合は、前半の'...'部分をプリントします; そうでなければ、後半の'...'部分をプリントしま
す。
(もう一つの方法として:
xという名前がその対応する単数の定冠詞（または単数の不定冠詞）に対して
ワールドテーブル内で空のエントリーを持っていたら、それは固有名詞と判断します(i.e. 実際の“キャタ
クター名”。)なので、実際にはフラグは必要ではありませんが、このルールがすべての言語に対して適用
されなければやり易くはなるでしょう。)
ここではドイツ語やロシア語のケース、また語形変化については詳細を語りませんが、基本的には基本
コンセプトの拡張であり、名前や冠詞についての欄を追加し、より多くのトークンを作って増加する
テーブルのコンビネーションにアクセスし実行時にゲームテキストに展開するだけです。興味のある方
はこの書類の最後にあるメールアドレス迄お問い合わせください。ただし、それらの企画書類はかなり
細かく書かれてありますので覚悟して御覧ください！
33
付録４ – サンプルローカライズスケジュール
スケジュールのパラメーター:
● これは言語ごとに一人の翻訳者を使用し、２週間程度の翻訳、１週間程度の音声収録を行う小さめの
プロジェクトです。
● 単純にするために、現地の祝日は考慮していません。
● 翻訳者が音声収録に参加する場合は、スケジュールに１週間加えてください。
● 翻訳者の数を増やして翻訳期間を短縮することはできますが、その場合ファミリアライゼーションや
グロッサリー制作のコストが増えます; 時間とコストのバランスを取る必要があります。
34
寄稿者の皆様
Richard Honeywood (作者)
Alain Dellepiane
Andrea Santambrogio
Davide Solbiati
Domhnall Campbell
Eduardo Lopez
Erik d'Engelbronner
Fabio Minazzi
Jon Fung
Kate Edwards
Miron Schmidt
Rolf Klischewski
Stéphane Bonfils
Steve Williams
Teresa Luppino
Tom Slattery
Víctor Alonso Lion
Virginia Petrarca
続く…
追加/変更/提案などは
[email protected]
までお送り頂ければRichard Honeywoodが喜んで本ド
キュメントの適切な箇所に組み込みます。
我々の目的はローカライズに関する絶対的なガイドブックを作ることではなく、基礎を作って人々を刺
激し自分たちのプロジェクトに活かしてもらい世界中のゲームローカライズのクオリティーを引き上げ
ることにあります。
もしあなたがまだIGDA Game Localization SIGのメンバーでないのなら、すぐにIGDAのサイトで我々の
メーリングリストに登録し議論に参加してください！皆さんとお話できるのを楽しみにしています！
IGDA Localization SIGへのサポートをよろしくお願いいたします！
35
© Copyright 2024 Paperzz
