実装Read this article in English

モバイルアプリの多言語対応 — エンジニアが実際に扱う構造の話

モバイルの多言語対応は翻訳の作業だと思われがちですが、エンジニアが実際に触る部分の多くは構造の話です。テキストがどこにあるか、OSがどのバージョンを表示するかをどう決めるか、そして一つの言語向けに作ったレイアウトが二倍の長さの文字列と出会ったときに何が起きるか。構造さえ正しければ翻訳はコンテンツの問題になりますが、構造を間違えると新しい言語ごとに新しいバグが増えます。

言語ごとのリソースファイル

主要なモバイルOSは、翻訳対象のテキストをソースコードから切り離し、言語ごとのリソースファイルにまとめることを前提にしています。welcome_titleのようなキーが各言語のファイル内の文字列に対応し、アプリは実行時にそのキーを参照します。コードに文字列を直接書かないという考え方です。これは他のプラットフォームでのgettext形式のカタログと同じ発想で、コードは安定した識別子を参照し、実際の言葉は翻訳者がコードに触れずに開けるどこかに置かれます。

「ここだけラベル一個だから」という例外を作らず、すべての文字列をこのファイル群に置くことが、以降の多言語対応を扱いやすくする鍵です。レイアウトファイルやソースコードに直接埋め込まれた文字列は、翻訳者からも、完全性をチェックするツールからも見えません。

OSは実際どうやってロケールを選んでいるか

主要なモバイルOSはどちらも、ユーザーがOSの設定で希望言語を優先順位付きのリストとして登録できるようになっています。一つだけ選ぶのではありません。アプリが起動すると、OSはそのリストを順に見て、アプリが用意している言語の中から最も近いものを探します。まず完全一致、次に関連する言語へのフォールバック、それでも見つからなければアプリのデフォルト言語です。

これはよくあるサポート問い合わせ「なぜアプリが違う言語で表示されるのか」の答えでもあります。ほとんどの場合、OSはユーザーの優先順位リストどおりに正しく動いているだけで、開発者が想定した「この人の言語」とは一致していません。たとえばブラジル向けポルトガル語だけを用意し、地域を指定しない標準のポルトガル語ファイルを用意していないと、地域指定なしでポルトガル語を選んでいる端末はデフォルト言語に落ちてしまうことがあります。

文字数が増えても壊れないレイアウト

同じ意味でも言語によって文字の長さは大きく変わります。英語の短いラベルが、一部のヨーロッパ言語では元の長さをはるかに超えて膨らむことがある一方、東アジアの一部の言語では同じ意味がより少ない文字数で収まることがよくあります。英語ぴったりに幅を決めたボタンは、翻訳後に文字が切れたり、予期しない形で折り返されたりします。

実務的な対処は、安全そうなピクセル幅を推測することではありません。コンテンツに合わせて伸縮するレイアウトを作ることです — 固定幅ではなく可変のコンテナ、ラベルに合わせて広がるボタン、切り詰めではなく二行目への折り返しを許すテキスト。開発中にデフォルト言語であえて長いプレースホルダー文字列を入れてテストすれば、翻訳者が画面を見る前に問題の大半を見つけられます。

  • 固定幅のボタンやラベルを避け、コンテンツに合わせて伸縮させる
  • 実際の翻訳文だけでなく、意図的に長い文字列でもテストする
  • 伸びる可能性のあるラベルは折り返しを許可する
  • アイコンとテキストが並ぶ行では、テキストが広がる余地を残す

アプリ内テキストとストア掲載テキストは別の仕事

アプリ本体を翻訳すれば作業は終わりだと思いがちですが、ストアの掲載情報 — ダウンロード前に表示されるタイトル、説明文、スクリーンショット、キーワード — は別の成果物です。独自の文字数制限があり、しばしば別の書き手が担当します。アプリ内テキストが「説明する」ためのものであるのに対し、ストア掲載文は「説得する」ためのものだからです。

更新のタイミングも異なります。アプリ内の文字列はアプリのリリースに合わせて変わりますが、ストア掲載情報はそれとは独立して、より高い頻度で編集できます。この二つを一つの翻訳作業として扱うと、たいてい掲載情報が古いまま放置されるか、逆にアプリ内テキストに不要なマーケティング調が混入します。

端末の言語と地域が一致しないとき

ユーザーの言語設定と地域設定は別の値で、しばしば一致しません。旅行中の人、輸入端末を使っている人、あるいは単に消費するコンテンツの言語とは違うインターフェース言語を好む人もいます。地域設定は日付の書式や通貨、数値の表記などを左右し、言語設定はどの翻訳文字列を表示するかを左右します。

この分離により、たとえばインターフェースは一つの言語なのに、日付や通貨がまったく別の地域向けの書式になる、ということが起こり得ます。これはバグではなく二つの設定がそれぞれの役割を果たしているだけですが、実装としては日付・数値・通貨は地域設定を使って書式化し、表示する翻訳文字列は言語設定を使って選ぶべきで、片方の設定だけで両方を決めようとしないことが重要です。

まとめ

ここまでの内容に特別なツールは必要ありません。テキストをコードから切り離す規律、長さを想定したレイアウトのテスト、ストア掲載情報を独立した成果物として扱うこと。新しい言語をスムーズに扱えるアプリは、翻訳を後から丁寧にやったアプリではなく、こうした判断を早い段階でしていたアプリであることが多いです。

関連記事