実装Read this article in English

翻訳が抜けているとき、アプリは何をすべきか

多言語対応したアプリは、いずれ必ず、表示している言語に一度も翻訳されなかった文字列に出会います。翻訳が追いつく前にリリースされた新機能、原文ファイルには追加されたのに他のどこにもコピーされなかったキー、あるいは基本言語がカバーするすべての文字列をカバーしていない地域変種、といった原因です。そのときアプリが何をするかは設計判断であり、よくある三つの答えにはそれぞれ異なるトレードオフがあります。

翻訳が抜けたときの三つの対処法

一つ目は原文言語への暗黙のフォールバックです。現在のロケールにあるキーの翻訳がなければ、代わりに原文言語のテキストを表示します。ユーザーは、画面の一箇所だけ違う言語ではあるものの、実在する読める文を目にします。他の言語が一文だけ混ざっていても「翻訳がまだ途中の箇所」に見えることが多く、「壊れたアプリ」には見えにくいため、エンドユーザーにとって最も違和感の少ない選択肢です。

二つ目は、welcome_titleのような生のキー名をそのままユーザーに表示する方法です。これは曖昧さがなく、正しい出力と誤認されることが絶対にありません。まさにそれゆえに開発時には有用です。しかし、本来コード用の識別子を本番環境のエンドユーザーに見せると、壊れているように見え、ユーザーにとって有用な情報は何もありません。

三つ目は空文字列です。単体で見れば視覚的には最も静かな失敗ですが、最も誤解を招きやすい可能性もあります。動いているアイコンの隣に空のラベルがあると意図的に見えることがありますし、空のエラーメッセージはユーザーに何が起きたのかまったく伝えません。静かであることは、優しいこととイコールではありません。

  • 原文言語へのフォールバック — 読めるが、画面上で言語が混在する
  • 生のキー表示 — 見間違えようがないが、エンドユーザーには無意味で洗練されていない
  • 空文字列 — 見た目は静かだが、何かが欠けている事実そのものを隠してしまう

開発では派手に、本番では穏便に

こうしたトレードオフは、環境ごとに異なるデフォルトを示唆します。開発環境では、翻訳の欠落はできる限り目立つべきです — 生のキー、明確な視覚的マーカー、あるいはコンソールの警告など。なぜなら画面を見ているのはそれを直せる本人であり、目的はリリース前にその抜けを絶対に見逃せないようにすることだからです。

本番環境では、同じ派手な失敗は負債になります。実際のユーザーには欠けた翻訳を直す手段がなく、画面上の生のキーを見ても何の役にも立ちません。本番環境はできる限り穏やかに劣化すべきで、それはほぼ常に、アプリが十分な網羅性を確信できる言語へのフォールバックを意味します — 生のキーは絶対に出さず、ユーザーが実際の情報を必要としている箇所での無言の空欄表示もできる限り避けます。

// 開発環境: 見間違えようがない
t("welcome_title") // => "[[welcome_title]]"

// 本番環境: 穏やかに劣化する
t("welcome_title") // => 原文言語のテキストにフォールバック

連鎖的フォールバック — 地域変種から基本言語へ

フォールバックは、原文言語へ一気に飛ぶ単一のジャンプである必要はありません。よくあるパターンは連鎖です。pt-BRのような地域変種は、まずその基本言語であるptにフォールバックし、その基本言語にも該当する文字列がなかった場合にのみ原文言語にフォールバックします。地域変種とその基本言語は、地域変種と無関係な原文言語よりもはるかに語彙や語調が近いため、原文言語へ直接飛ぶよりも通常は良い結果になります。

この連鎖は明示的で短くあるべきです — 地域変種、基本言語、原文言語、そこで停止 — アプリが出荷しているすべての言語を際限なく探索するものであってはなりません。連鎖に上限がないと、ある欠けた文字列についてユーザーが最終的にどの言語を目にすることになるのかを予測するのが難しくなります。

なぜ答えは「両方」なのか

開発環境と本番環境を同じように扱うと、たいていどちらかの方向に失敗します。どこでも派手に失敗させると、本番環境のユーザーが時折画面上の生の識別子を目にすることになります。どこでも穏やかに失敗させると、アプリが毎回静かにその穴を埋めてしまうため、翻訳者や開発者は一群の文字列がまるごと翻訳されていないことに何週間も気づかないままになり得ます。

定石は、この二つの挙動を意図的に使い分けることです。直せる人がそれを目にする場所では派手に失敗させ、それを目にしても何もできない人がいる場所では穏やかに失敗させます。どの環境にどちらの挙動を割り当てるかは、ハードコードではなく設定で切り替えられるようにしておくべきで、そうすれば翻訳者のレビューに使うステージング環境を、必要なときだけ派手なモードに切り替えることもできます。

関連記事