アップデート告知とパッチノートを多言語で回す
ゲームは6言語で出している。パッチノートは1言語しか出していない。これは非常によくある状態で、理由もはっきりしています。ゲーム内テキストは予算のついた計画的なローカライズ工程を通りますが、告知は配信当日の朝に、リリース作業に一番近くにいる人が書くからです。
プレイヤー側から見ると、これは奇妙な非対称に映ります。自分の言語で遊べるから買ったのに、アップデートは読めない文字の壁として届き続ける。何かが変わったことはわかるが、何が変わったのかはわからない。そして時間が経つにつれ、「自分が持っているのは、本当は別の誰かに向けて作られているゲームの翻訳版なのだ」という印象が固まっていきます。
この記事では、その部分を再現可能な運用に変える話をします。告知が本当は何をしているのか、どこまでを訳す線を引くか、訳す費用がほぼゼロになる原文の書き方、そして告知の用語をゲーム内の用語と一致させ続ける方法です。
告知は本当は何をしているのか
役割を正確に切り分けると考えやすくなります。情報を伝えているのは一部にすぎないからです。パッチノートは同時に三つの仕事をしていて、それぞれ言語に対する要求が違います。
一つ目は、今のプレイヤーに何が変わったかを伝えること。誰もが思い浮かべる部分です。二つ目は、このゲームは生きていて手入れされていると示すこと。最近の投稿一覧をざっと眺めている人は、内容ではなくリズムを読んでいて、更新が続いている事実そのものが、中身を精読しない人にも安心を与えます。三つ目は復帰の誘導で、離れたプレイヤーを呼び戻し、再インストールする理由を与えることです。
二つ目と三つ目は関係づくりの仕事です。読めない言語で行われた関係づくりは、単に効果がないだけでなく、疎外の合図として働くことがあります。読めない告知が賑やかに流れているのを見たプレイヤーは、自分が優先順位のどこにいるかを学んでしまいます。
もう一つ、名指ししておくべき読者がいます。まだ買っていない人です。告知は公開されており、ストアページに並び、検索にも拾われます。このゲームはまだサポートされているのかを確かめようとしている購入検討者は、他の何より先に告知一覧を読みます。つまり告知はコミュニティの面であると同時に、ストアの面でもあります。
線を決めて、その線を守る
すべての投稿を一字残らず訳すのは小規模なチームには現実的ではありませんし、できるふりをするのが、3回目の更新あたりで運用が崩壊する原因です。事前に、必ず訳す種類・たいてい訳す種類・訳さない種類を決めて、それを一貫して適用してください。線が引かれていること自体より、線が揺れないことのほうが大事です。大きな告知は多言語なのに、不具合を出したときのお詫びだけ1言語、という差にプレイヤーは気づきます。
例外にしてはいけないのは、結果が生じる種類の告知です。お金、提供状況、データ消失、互換性を壊す変更、サーバー停止。理解できなかったせいでプレイヤーが進行を失う・アクセスを失う・課金される可能性があるなら、その投稿はどれだけ短くても訳します。
それ以外については、「要約+詳細」の構造にするだけで、費用のごく一部で価値の大半が取れます。何が変わったかの短い要約を全対応言語で訳し、その下に網羅的な修正リストを1言語で置く。100行の修正リストを精読する人はどの言語でもほとんどいませんが、最初の段落はほぼ全員が読みます。
部分的にしか訳していないときは、それを明示してください。「詳細な修正内容は英語のみです」という正直な一行はコストゼロで、沈黙よりはるかに印象が良い。沈黙は手落ちだと解釈されます。チャンネルについても同じです。ストアの告知は全対応言語で出し、コミュニティサーバーは主に1言語で運用する、というのはまったく妥当な方針です。ただしそれが、探り当てるものではなく明言された方針であるかぎりにおいて。
- 必ず訳す — 価格の変更、提供状況、データ消失の恐れ、サーバー停止、互換性を壊す変更、返金に関すること
- たいてい訳す — 大型アップデート、季節イベント、ロードマップ、離れた人に戻ってきてほしい内容
- ほぼ訳さない — 網羅的な修正一覧、細かいホットフィックスの詳細、開発雑記
- 黙って済ませない — どこまでが訳されているかを、影響を受ける言語で書く
訳に耐える原文を書く
多言語告知のコストを最も大きく左右するのは、誰が訳すかではなく、原文がどう書かれているかです。翻訳を前提に書かれた告知は数分で回せて、機械翻訳にかけたときの危険もずっと小さい。ジョークと内輪ネタの流れとして書かれた告知は、いくら払っても回せません。
毎回同じ構造を使ってください。骨組みが固定されていれば、翻訳者もツールも見慣れた形として扱えますし、見出しは投稿をまたいで一字一句同じになり、読者はどこを見ればいいかを知っています。そして何より、必ず訳す部分と、ときどき訳す部分を機械的に切り分けられるようになります。
文は短く、そして文として完結させてください。英語の見出しの下では意味が通る体言止めや断片は、見出しがその行と切り離されて訳された途端に曖昧になります。とくに見出しでは、駄洒落・ミーム・文化依存の言い回しを避けてください。見出しは、周囲の文脈なしに訳される可能性が最も高い部分です。
画像に文字を焼き込まないでください。アップデート名を入れたバナーは決して訳されませんし、たいていその投稿で最も大きく目立つ要素です。どうしても画像に文字を入れるなら、バージョン番号程度にとどめ、意味は本文に置きます。
- 1項目1論点 — 三つの変更を一文にまとめない
- 数値・バージョン表記・日付は毎回同じ書き方にし、機械翻訳する予定の文章の中に埋め込まない
- 意味を持つ文字をバナーやスクリーンショットに焼き込まない
- 見出しは毎回工夫せず、テンプレートからそのまま使い回す
定型文集を作り、同じ文に二度払わない
告知は驚くほど繰り返します。1年分の更新を書けば、「クライアントの再起動が必要です」「以前のバージョンのセーブデータは引き続き使用できます」「本件は把握しており、修正を進めています」の類を何十回も書くことになります。それを毎回ゼロから訳すのは純粋な無駄であり、さらに悪いことに、毎回少しずつ違う言い回しになります。同じ情報が違う情報に見えてしまうということです。
ですから一度だけきちんと訳して、保存します。定型文集といっても、文ごとに固定のキーを振った再利用可能な文のファイルを、対応言語ぶん用意するだけです。新しい告知は既存の行を組み合わせて大部分が作られるようになり、通常のホットフィックス告知の追加翻訳コストはほぼゼロに近づき、言い回しはリリースをまたいで完全に一致します。
テンプレートも同じフォルダに、同じバージョン管理の下に置いてください。狙いは、告知を書く作業を、締切に追われながら白紙から書き起こす作業ではなく、決まった形を埋める作業に変えることです。
announcements/ template.md 固定の見出し順。すべての投稿はここから始める phrases.tsv 再利用する定型文。言語ごとに一度だけ訳す glossary.tsv アイテム・スキル・モード名。ゲームの文字列から抽出する # template.md <バージョン> - <一行要約> ## 新要素 (必ず訳す) ## 変更 (必ず訳す) ## 修正 (決めた線に従う) ## 既知の不具合 (必ず訳す。信頼はここで得られる) # phrases.tsv restart_required 本アップデートの適用にはクライアントの再起動が必要です。 saves_compatible 以前のバージョンのセーブデータは引き続きご利用いただけます。 hotfix_intro 前回の更新後に報告された不具合の修正版です。 server_downtime 更新の適用中、サーバーはご利用いただけません。 known_issue 本件は把握しており、修正を進めています。 thanks_reports ご報告いただいた皆様、ありがとうございます。
実際に壊れるのは用語のほう
最も被害が大きく、最も見逃されるのがこれです。パッチノートがゲーム内と違う名前でものを呼んでしまう。あるスキルを調整したと書いた告知が、告知のためにその場で作られた訳語を使っている一方、ゲーム本体は同じ言語でそのスキルをまったく別の名前で呼んでいる。プレイヤーは告知を読み、探しに行き、何が変わったのか見つけられません。
これが起きるのは、告知がゲーム内テキストとは別の経路を通るからです。ゲームの文字列は、文脈と用語集を持った翻訳者を通っています。告知は、そのどちらも持っていない人が急いで機械翻訳にかけたものです。ゲーム内の固有名詞はすべて、その経路上の地雷です。アイテム名、スキル名、モード名、地名、キャラクター名、通貨名。
対処は機械的です。ゲーム自身のローカライズファイルから固有名詞を抽出し、テンプレートの隣に用語集として置く。告知を書く人・訳す人はそのファイルを唯一の正とし、すでにゲーム内に存在する語について新しい訳を発明しない。
確認は、この点を狙って行ってください。訳文を自然さの観点で読んでも見つかりません。間違ったアイテム名は日本語としては完璧に読めてしまい、ビルドとの関係においてのみ間違っているからです。つまり用語集と一語ずつ突き合わせる以外に見つける方法はありません。
機械翻訳・確認・そして時間の問題
告知に対して機械翻訳を使うのは妥当な選択です。ゲーム内の物語テキストに使うよりずっと妥当で、文体が平易で構造が反復的だからです。ただし確認工程なしで使うのは妥当ではありません。とはいえその確認は、文体まで含めた通読である必要はなく、この形式で機械翻訳が間違えるものを狙って見るだけで足ります。
その確認は短く、毎回同じです。固有名詞がすべて用語集と一致しているか。数値とバージョン表記が壊れずに残っているか。日付が誤解されない書き方か。お金・返金・データ消失に関する記述が、少し意味の違う言い方に置き換わっていないか。この四点で、実害の大半は防げます。
そして時間の問題があります。多くのチームがここで諦めます。告知はパッチの配信と同時に出す必要があるのに、翻訳には時間がかかり、パッチはリリース直前まで確定しない。つまり訳したいテキストは、訳し始めたい時点ではまだ存在しません。
抜け道は、やはり「要約+詳細」の分割です。このアップデートが何であるかという要約は、たいてい数日前から分かっていて変わりません。だから先に訳しておけます。最後の1時間まで動く詳細部分は、1言語で出すか、少し遅れて追記する。これで不可能なスケジュールが普通のスケジュールに変わります。12回のアップデートを越えて続く運用と、3回目で静かに止まる運用の差はここにあります。
最後に、配信先が何を扱えるかを確認してください。Steamのイベント・告知の機能は、一つの投稿に言語別の版を持たせて、プレイヤーのストア言語で表示させることができます。訳文の入力方法は最新のSteamworksのイベント関連ドキュメントで確認してください。同じ内容を言語ごとに別投稿として出すのも一応は成立しますが、フィードが散らかり、コメントも分断されるので、プラットフォーム側の仕組みがあるならそちらを使ってください。