英語ができる友人にゲーム翻訳を頼んでいいのか
ゲームを英語対応させたい、予算はない、そして身近にその言語が流暢な人がいる。友人、パートナー、親戚、前の職場の同僚。すぐにこう思うはずです。あの人に頼めばいいのでは、と。
これはおそらく、小規模なゲーム開発で最も多く選ばれる最初の一手です。そして「翻訳はプロに頼むべき」という反射的な助言は、正しくはあるものの、お金がない場面では役に立ちません。もっと役に立つのは、範囲を絞った問いです。翻訳者ではない流暢な人が、この仕事のどこは実際にうまくやれるのか。どこは、双方が気づかないまま失敗するのか。そして、友人関係を失わずに頼むにはどうすればいいのか。
以下は、その友人が本当に流暢で、本当にやる気がある前提で書いています。その前提でも失敗の型は具体的で、予測可能です。そしてそのほとんどは、流暢さと翻訳を同じ能力だと扱ったことから生まれます。
流暢であることと、翻訳できることは別の能力
ある言語を読めて話せるということは、その文が何を言っているか分かるということです。翻訳するというのは、原文にアクセスできない読者に対して同じ効果を生む新しい文を、その言語で書くということです。関連はしていますが、同じ能力ではありません。そしてその差は、はっきり三か所に現れます。
一つめは、理解と産出の差です。第二言語をすらすら読めるのに、書くと硬くなる人はいくらでもいます。その訳文は正確で、意味も合っていて、そして説明書のように読めます。ゲームにとってこれは実害です。テキストがやっている仕事の大半はトーンだからです。判断材料としては、その友人がその言語で話しているところではなく、まとまった量を書いているところを見たことがあるか、を考えてみてください。
二つめは、ゲームテキスト特有の作法です。ゲームのテキストには、実際に扱うまで見えないルールがあります。メニュー項目は文章ではない。台詞はテキストボックスに収まらなければならない。システムメッセージには一貫した文体がある。「Loading」のような断片は、訳す側からは見えない文脈で機能しなければならない。流暢な友人はしばしば文字列を散文として訳し、文法的には完璧なのにボタンの三倍の長さになったラベルを返してきます。
三つめはファイルの扱いで、これが実際にビルドを壊します。{playerName} のようなプレースホルダーは一字も変えてはいけない。マークアップタグは対で閉じていなければならない。キーは編集してはいけない。行を並べ替えたり、結合したり、削除したりしてはいけない。プロはこれらが構造を支えていることを知っています。表計算ソフトで作業している友人には、変数の前後の空白を整えたらゲームが落ちる、と疑う理由がありません。
何を渡してよくて、何を渡すべきでないか
全部任せるか、まったく任せないかの二択ではありません。テキストを「文章力にどれだけ依存するか」と「間違えたときの損失の大きさ」で仕分けるだけで、リスクを大きく減らしながら価値の大半を取れます。
友人に向いているのは、声よりも意味が重要で、こちらが自分で検証できるテキストです。アイテム名、メニュー項目、設定画面、チュートリアルの説明、システムメッセージ。短く、文字数制限と突き合わせられ、多少そっけない訳になっても害がありません。
向いていないのは、ゲームの個性が宿る場所と、間違いが高くつく場所です。ストアページ、最初の1時間、関係性や冗談を担っている会話、そして商業的・法的な約束を含む文言。友人にできないという意味ではなく、できたかどうかを二人とも判断できない、という意味です。
そしてファイルには触らせないこと。プロジェクトごと渡さない。テキストを書き出し、必要な列だけのシートを送り、取り込みは自分でやる。これは前節のファイル事故からビルドを守ると同時に、同じくらい重要なこととして、理解しようのなかった技術的な失敗の責任を友人が負わされる事態を防ぎます。
- プロジェクトではなくシートを送る。キー列はロックか非表示、1行1文字列
- 文脈の列と最大文字数の列を入れ、その文字数は厳守であることをはっきり書く
- 波括弧や山括弧の中身はそのままコピーすること、と明記し、例を一つ添える
- 大きな1ファイルではなく、期限つきの小さな塊に分ける
- エンジン内のファイルを直接編集させることは絶対にしない
友人関係を壊さない頼み方
この種の取り決めで傷つくのは、ほぼ常に翻訳ではなく関係のほうです。原因は、際限のない頼みごとにしてしまうことです。分量が示されていない、期限がない、断る方法がない、そして仕事であると認められていない。
だから境界を引きます。頼む前に、承諾のあとではなく前に、実際の分量を行数か文字数で伝える。守られなくてもこちらが耐えられる期限を示す。相場に届かなくても報酬を提示する。どうしても払えないなら、曖昧にせずはっきりそう言う。金銭の期待が言葉にされないまま残るほうが、払えないと明言されるよりずっと悪い結果になります。そしてゲーム内とストアページに、本人が望む名義で — 匿名希望も含めて — クレジットを載せると伝える。
謝らずに降りられる出口を用意してください。「思ったより大変だったら、そこまでの分を返してくれれば残りはこちらでやる」と最初に言っておくだけで、行き詰まったときに黙り込むしかない、という圧力が消えます。友人翻訳が止まるのは、たいてい興味を失ったからではありません。頼まれごとの規模を超えてしまったのに、体面を保って降りる方法がなかったからです。
会話で伝えるより、短くても書面にしたほうが効きます。曖昧な頼みごとが、終わらせられる作業に変わるからです。
お願いしたいこと
- UI・アイテム関連 420行(約2,300文字)
- 添付シートのC列だけ埋めてください。A列とB列は触らないでください
- { } の中身はそのままコピーしてください
- E列はその行の文字数上限です(超えると画面に収まりません)
条件
- 来月末くらいを目安に。遅れても問題ありません
- 謝礼は[金額]です。相場より安いことは承知しています
- ゲーム内とストアページに[名義]でクレジット。匿名でも構いません
- 思ったより大変だったら、そこまでの分を返してくれれば
残りはこちらでやります。本当に気にしないでください
現実的にいちばん機能する形 — 友人の下訳+有償レビュー
バイリンガルの友人の最も効果的な使い方は、たいてい「翻訳者」としてではなく、二段構えの前半としてです。友人が全体の下訳を作り、有償のプロがゼロから訳すのではなくレビューと修正を行う。
これが機能するのは、レビューが翻訳よりはっきり軽い作業だからです。フルの発注には届かなかった予算で手が届きます。同時に検証の問題も解決します。資格のある誰かが全行に目を通した状態になり、ファイルは「検証できないもの」から「品質の分かるもの」に変わります。そして友人の貢献も実在します。下訳には、外部のレビュアーなら一から築かなければならなかった「このゲームへの理解」が入っているからです。
逆順でもうまくいきますし、そのほうが良い場合もあります。ストアページと最初の1時間のような、短くて価値の高い面だけプロに翻訳を発注し、機械的なテキストの大半は友人が担当する。どちらにせよ原則は同じで、お金は「それなしでは検証できない場所」に使うということです。
レビューの費用も出せない場合の次善策は、もう一人の流暢な読み手です。別の友人、その地域のプレイヤー、貸し借りできる開発者仲間。ただしシートを読ませるのではなく、ゲームをプレイしてもらってください。独立した流暢な読み手が二人いることは、プロ一人と同じではありませんが、一人よりははるかに良く、「文としては正しいが状況に合っていない」種類の間違いを拾えます。
公開後に問題が出たとき
いつか必ず、不自然な訳文、間違った訳文、意図せず笑える訳文をプレイヤーに指摘されます。これは普通のことで、プロが訳したゲームでも起きます。そしてその扱い方が、この選択が良い判断だったかどうかを決めます。
原則は、ゲームは自分のもので、責任も自分のものだということです。返信の中で友人の名前を出さない。好意で訳してもらったのだと説明しない。公開スレッドが友人の語学力の品評会になることを許さない。工程を選んだのは自分であり、結果を引き受けるのも自分です。報告してくれた人に礼を言い、その行を直し、次のパッチに入れる。
修正のたびに友人へ差し戻すのも、既定にしないでください。報告が来るたびに連絡していると、一度きりの頼みごとが期限のない義務に変わります。関係を痛めるのはまさにそこです。報告はまとめておき、本当に本人の判断が要るときだけ聞く。
長い目では、友人による訳文は完成版ではなく第一版として扱ってください。その言語が実際に効いていると分かったら — ウィッシュリストや売上やレビューがそれを示したら — そこが本格的に費用をかけるタイミングです。下訳は無駄になりません。プロが手を入れる土台になりますし、そもそも「投資する価値がある」と判断できた情報は、その下訳が稼いでくれたものです。