ローカライズのリグレッション ― 「前回のビルドでは大丈夫だった」は根拠にならない

分かりやすさのために原文の一文が少し書き直される。英語だけ見ると些細な変更に見えるので、誰も再翻訳のフラグを立てない。数言語先で、古い訳文はもう新しい意味と一致していない ― そしてそれに気づくのは、プレイヤーが最初になる。

これがローカライズのリグレッションです。翻訳者が新たなミスをしたわけではなく、周りの何かが変わったせいで、以前は正しかった訳文が誤りになる現象です。コードのリグレッションとまったく同じ失敗のパターンであり、同じ規律を必要とします ― 記憶に頼らず、ベースラインと差分で確認することです。

誰も触っていないのに訳文が古くなる3つの経路

最も多いのは原文の修正です。デザイナーがツールチップの言い回しを変える、ライターがセリフを整える、プログラマーがプレースホルダーの名前を変える。どれも翻訳作業には見えませんが、そのどれもが、全ての対象言語で承認済みの訳文を無効化しうるものです。

二つ目は一括再翻訳や再書き出しです。文字列をまとめて新しい翻訳パスに通したり、スプレッドシートやCATツールからファイルを再書き出ししたりすると、行の順序がずれたり、テキストの折り返しが変わったり、更新するつもりのなかった行まで一緒に触れてしまうことがあります。

三つ目が最も気づきにくいものです。古いバージョンのファイル ― バックアップや古いブランチ、メールの添付ファイルなど ― がビルドに再インポートされ、すでに直したはずのバグが、まるで新規の不具合のような顔をして復活します。

「前回は大丈夫だった」は根拠にならない理由

「前回のビルドでは大丈夫だった」が保証しているのは、その時点で存在していた特定のファイル、特定の文字列セット、特定の原文についてだけです。この三つのうち、ビルド間で変わらないことが保証されているものは一つもありません。ローカライズファイルは一度確認すれば済む事実ではなく、原文・訳文・書き出しパイプラインのどれかが変わるたびにずれていく状態です。

これはエンジニアが「自分のマシンでは動いた」をQAの論拠として信用しない理由とまったく同じ構造です。どちらの場合も直し方は同じで、記憶に頼るのをやめ、実際の状態同士を比較することです。

実行のたびにベースラインをとり、差分をとる

毎回のチェックを、単独の合否判定ではなく、そのファイルの直前の既知の良好な状態との比較として扱います。具体的には、前回のチェックで見つかった課題を記録として残し、今回の課題をそれと突き合わせて分類します。

• 新規 ― このファイルの前回のチェックには現れなかった
• 解消 ― 以前は現れていたが、今回はなくなった
• 再発 ― 以前現れ、一度は解消したが、再び現れた

この分類が何をもたらすか

翻訳パスの後に「解消」の件数がほぼゼロであることは、課題の総数が一見妥当に見えるかどうかとは独立に、早期の警告として役立ちます。「再発」が出ているということは、特定の修正がどこかの書き出しや再インポートの工程を生き延びられなかったという強いシグナルであり、文字列そのものではなく、パイプライン側を調べる価値があります。

レビューのやり方も変わります。数百行あるファイルを毎回すべて読み直す代わりに、翻訳者やレビュアーは「新規」と「再発」の少数の行に集中できます。速いだけでなく、実際に変わった箇所を見落とさずに済みます。

ローカライズファイルもコードと同じように扱う

根底にある考え方自体は新しくありません。リグレッションテストを、それがめったに適用されない領域に持ち込むだけです。ローカライズファイルはコンテンツ更新のたびに変化し、複数のツールで書き出し・再インポートされ、必ずしもプログラマーがバージョン管理で見るのと同じ差分を見ているとは限らない人たちの手を経由します。

コードにはすでに当たり前になっている規律 ― ベースラインをとり、差分をとり、何がなぜ変わったかを分類する ― を同じように適用することで、「前回のビルドでは大丈夫だった」は推測ではなく、実際に確認できるものに変わります。