対応可能なローカライズバグレポートの書き方

ローカライズのバグには、普通のバグにはあまりない特徴があります。問題に気づいた人が原文を読めないことが多く、直せる人が対象言語で書かれた報告を読めないことも多い、という点です。この非対称性があるからこそ、レポート自体が普通のバグ報告以上の仕事をしなければなりません。報告する側と直す側が同じ前提を共有している、という前提に頼れないからです。

「日本語がなんか変」は事実としては嘘ではありませんが、何の役にも立ちません。何がどこでどんな基準に照らして間違っているのかを一切伝えていないからです。この種の報告はたいてい放置されるか、実際に何を言いたかったのかを確認するための往復に時間を食います。最初からもう少し具体的に書けば、その往復はまるごと不要になります。

対応可能なレポートに含まれるもの

対応可能なローカライズバグレポートは、問題の種類にかかわらず毎回同じ6つの問いに答えます。どの文字列か、現在どう表示されているか、本来どうあるべきか、なぜか、どこで確認したか、どのビルドか。どれか一つでも欠けると、レポートは「誰かが動く前に追加情報を求める依頼」になってしまいます。

• 文字列のキーやID — 似たような行が何千とある中から、その一行を確実に特定する唯一の手がかり
• 原文 — 訳の自然さだけでなく正確さも判断できるように、原文そのもの
• 現在の訳文 — 記憶からの言い換えではなく、実際にビルドに載っている文字列をそのままコピーしたもの
• 期待値と実際の違い — 誤訳・トーン違い・文字切れ・プレースホルダーの誤りなど、印象ではなく具体的な差分として
• スクリーンショット — 文字切れや重なり、フォントの問題は文章だけでは伝わりません
• ビルドと言語 — 報告者がどのビルドとどの言語版でテストしたか。ある言語のビルドでの修正が、別の言語について何も語らないため

最小限のテンプレート

短くても構造化されたテンプレートは、自由記述欄より優れています。報告者が省略しがちな項目を強制的に埋めさせるからです。大掛かりである必要はありません。

Key: dialogue.quest_042.line_03
Source (EN): "You've got nerve, showing up here."
Current (JA): それは度胸がありますね、ここに来るとは。
Expected: 皮肉・威圧的なトーン。丁寧な褒め言葉になっている
Build: 1.4.2-rc3
Language: ja-JP
Screenshot: 添付

曖昧な報告が何も生まない理由

「なんか変」「不自然」といった言葉は、反応であって欠陥の記述ではありません。これを受け取った翻訳者は、報告者が頭の中に持っていた文脈をすべて再構築しなければなりません。どの行か、具体的に何が引っかかったのか、どう直せば良いのか。ほとんどの場合この再構築は起こらず、レポートは開いたまま放置されるか、「再現しない」として閉じられ、実際の問題はそのまま出荷されます。

これは報告者の怠慢というより、上の6項目のうちどれが重要なのかを誰にも教わっていないだけのことがほとんどです。短いテンプレートは、覚えている人が任意で書いてくれることに期待するのではなく、具体的な項目を明示的に求めることでこれを解決します。

ビルドではなくファイルを直す

ローカライズのバグは、原本ファイル — スプレッドシート、CMSのエントリ、翻訳メモリなど、パイプラインが正本として扱っているもの — が修正されて初めて解決したことになります。ビルド側のアセットに直接当てたパッチ(オーバーライドファイル、ビルド設定内での手動編集)は、症状を消すだけで原因を残します。

次に正本からテキストが書き出されるとき — 新しいビルド、新しいプラットフォーム、あるいは通常のコンテンツ更新のとき — 直したはずの古い誤訳が復活します。正本側には「これは間違っていた」という情報が一切伝わっていないからです。同じローカライズバグを二度トリアージした経験があるなら、たいていこのパターンに当てはまります。修正が本来あるべき場所になかったのです。