翻訳キーを安全にリネーム・削除する — 翻訳資産を失わないために
コード内の変数名のリネームは、見落としがあってもコンパイラが教えてくれる日常的なリファクタリングです。翻訳キーのリネームはこれとは種類が違います。原文ファイルより下流のどの仕組みも「リネーム」という概念を理解していません。理解しているのは「このキーが消えた」「この新しいキーが現れた」という、見た目以上に破壊的な二つの出来事だけです。
リネームは「削除+追加」として扱われる
翻訳ファイル、翻訳管理ツール、あるいは翻訳者のタスクキューの視点から見ると、checkout_buttonをcheckout_cta_buttonに変えることはリネームではありません。checkout_buttonが消え、まったく新しい未翻訳のcheckout_cta_buttonが突然現れたように見えます。旧キーの翻訳を持っていたすべての言語ファイルはその翻訳を失い、新キーについてはすべての言語で、誰かが翻訳するまで空欄またはフォールバック表示になります。
これは英語や原文言語での意味がまったく変わっていない場合でも起こります。変えたのは識別子だけです。リネームのコストはリネームした言語では発生せず、意味が実は何も変わっていない文字列の再翻訳を突然求められる、他のすべての言語で発生します。
// 原文ファイルだけ見ると無害に見える - "checkout_button": "Buy now" + "checkout_cta_button": "Buy now" // しかし他のすべての言語のcheckout_buttonの翻訳は孤立し // checkout_cta_buttonは空の状態から始まる
翻訳を失わずにキーを廃止する
どうしてもキーをリネームする必要がある場合、より安全な手順は、先に新しいキーを追加し、すべての言語ファイルにわたって旧キーの既存の翻訳を新しい名前の下にコピーしてから、旧キーを削除することです。こうすれば翻訳済みの文言を捨てて、すでに終わっていた作業をすべての翻訳者にやり直させることを避けられます。文字列の意味は変わっていないのですから、名前と一緒に言葉まで失う理由はありません。
一部のチームは移行期間中、旧キーと新キーの対応表を小さく保持しておき、各言語ファイルごとに手作業でコピーする代わりにツールで同じコピー処理を自動的に適用できるようにしています。
即削除ではなく非推奨化を挟む
コードのどこからも参照されなくなったキーを見つけると、すぐに削除したくなります。より穏やかなやり方は、まず非推奨としてマークすることです — 翻訳自体はそのまま残し、コメントや別のリストで「もう使われていない」とだけ示しておき、何も依存していないと十分確信できるだけの時間が経ってから削除します。
これは、コードベース全体を網羅的にgrepするのが難しい形でキーが共有されている場合に特に重要です。設定ファイル内で名前によって参照されているキー、変数から動的に組み立てられるキー、翻訳ファイルを直接読む外部連携で使われているキーなどです。即削除は「参照の検索が完全だった」という前提に立っていますが、非推奨化はその前提が外れていた場合の猶予期間を与えてくれます。
孤立したキーを見つける
孤立キーとは、翻訳ファイルにはまだ存在するものの、もうどのコードからも参照されていないキーのことです。通常は機能が削除されたときや、片付けをせずにキーをリネームしたときに残ります。孤立キーは単なるゴミではありません。それぞれが新しい言語を追加するたびに同期・翻訳の対象であり続け、誰にも見られることのない文字列を維持するために費やされる無駄な労力になります。
これを見つけるには、翻訳ファイル内のキー全体の集合と、コード内で実際に参照されているキーの集合を突き合わせ、ファイルには存在するがコードには存在しないキーを洗い出します。これは自動化しやすく、かつ手動では実行を忘れやすいタイプのチェックです。ファイル自体には、あるキーが死んでいることを示す見た目の手がかりが何もないからです。
- ファイル内のキー集合と、ソースコード内で使われているすべてのキー文字列を突き合わせる
- 動的に組み立てられるキー参照も検索対象に含めるか、手動レビュー対象としてフラグを立てる
- 孤立キーが大量にあることは無視していいノイズではなく、片付けをスケジュールすべきシグナルとして扱う
存在しないキーを見つける
逆の問題は、コードが参照しているのにどの翻訳ファイルにも定義されていないキーです。通常は、開発者がUIに新しい文字列を追加した際に原文言語ファイルへの対応するエントリを追加し忘れたり、原文ファイルには追加したものの他のすべての言語ファイルには追加し忘れたりしたときに発生します。実行時にはたいてい、アプリの設定次第で、ユーザーにキー名そのものが表示される、空文字列になる、あるいは別の言語にフォールバックする、といった形で表面化します。
事前に検出するには、先ほどとは逆方向の同じ突き合わせを行います。コードで使われているすべてのキーは、少なくとも原文言語ファイルには存在し、理想的にはアプリが出荷するすべての言語ファイルに存在するべきです。このチェックをビルドや定例レビューの一部として実行しておけば、ユーザーが翻訳された文の代わりに生のキー名を画面上で目にする前に、その抜けを発見できます。