アプリの海外展開では、画面の日本語を翻訳しただけでは完成しません。文字がボタンからはみ出す、個数に応じた表現が変わらない、案内されたサポート窓口が対象言語に対応していない、といった問題があれば、使い始めた人が操作を続けられなくなります。
開発者と翻訳担当者が共有したいのは、単語の一覧だけでなく、利用者が何をしようとして、どの画面で判断するかという情報です。この記事では、アプリの公開前から更新後までを対象に、翻訳を開発・検証の工程へ組み込む方法を説明します。
国際化とローカライズを、別の作業としてつなぐ
W3Cの解説は、国際化を多様な言語・地域へ対応しやすくする設計・開発、ローカライズを対象地域の言語・文化などの要件に適合させる作業として区別しています。先に対応しやすい構造を作り、選んだ言語・地域に合わせて内容を入れる、と考えると役割を整理できます。
最初の計画では、言語だけでなく配信地域、OS、端末、利用者の目的を決めます。アプリ内の表示、ストアの紹介文、ヘルプ、通知、問い合わせ対応のうち、何を初回公開に含めるかも決めましょう。全言語を同時に追加する以外に、対象を絞って運用を確認してから広げる方法もあります。
予算には翻訳文字数だけでなく、表示調整、動作確認、確認への回答、公開後の修正を含めます。アプリだから必ず少ない資金で海外展開できるとは限りません。対応範囲を小さくしても、利用者に約束した操作やサポートが途中で途切れないように計画します。
文字列を管理し、訳すための文脈を添える
Androidの公式ローカライズガイドは、地域に応じて変える内容を、アプリの中心的な機能からできるだけ分離してリソースとして管理する方法を説明しています。未対応の言語で使われる既定のリソースも必要です。日本語の文字列を画面ごとに直接埋め込み、翻訳時に探し回る構造を避けます。
翻訳に渡す各項目には、変更されにくいID、原文、画面名、使用場面、文字数等の制約、スクリーンショットを添えます。「開く」という同じ語でも、ファイルを表示するのか、詳細パネルを展開するのかで適切な訳が変わるためです。意味の異なる操作を、原文が同じという理由だけで一つの項目にまとめないようにします。
アプリの世界観や語調は、抽象的な説明だけでなく例を用意すると伝わります。初回の歓迎文、操作を促すボタン、エラー、解約の案内などで、丁寧さや簡潔さをどうそろえるかを決めます。魅力的な表現でも、実際に提供していない機能や効果を加えないことが必要です。
変数・複数形・地域形式を文章と一緒に扱う
利用者名、金額、個数などが入る文章は、固定部分だけを訳すと不自然になることがあります。変数が何を表すか、入る値の例、前後の語順を変更できるかを伝えます。変数の記号を削除したり、違う項目に置き換えたりしないよう、翻訳後に機械的な照合と表示確認を行います。
AppleのString Catalogの説明では、言語ごとの複数形や端末に応じたバリエーションを管理する方法が案内されています。単数と複数の扱いを英語の一種類の規則で全言語へ広げず、対象言語で必要な形を開発側と確認します。文を短い部品へ分割して連結すると、訳先で語順を変えにくくなる点にも注意します。
日付、数値、通貨などは地域に応じた表示が必要です。表示形式を変えることと、金額を別通貨へ換算することは別なので、翻訳担当者に換算を任せないようにします。時刻を扱うアプリでは、表示対象のタイムゾーンや予約時刻の意味も仕様として共有します。
右から左へ読む言語に対応する場合は、文章の方向だけでなく、数字や型番が混じる表示、アイコンの意味、入力欄の位置も確認します。すべての画像やアイコンを一律に左右反転させればよいわけではありません。翻訳者へ画面を見せ、開発者が実際の操作と組み合わせて判断する必要があります。
アクセシビリティ用のラベルや読み上げられる説明も、利用者が触れる言葉です。画面に大きく見える文字だけで翻訳対象を確定せず、支援機能で操作した場合に何が伝わるかを確認項目へ加えます。
疑似ローカライズと、対象言語の確認を分ける
Androidの疑似ローカライズは、文字を伸ばしたり右から左へ表示したりして、翻訳に伴う画面の問題を見つけるための機能です。文字列の埋込み、文字数増加による崩れ、連結された文、双方向の文字表示などを調べる助けになります。
ただし疑似ローカライズは、対象言語の訳文が自然か、ボタンが正しい操作を伝えているかを判定するものではありません。翻訳後は実際の言語・地域設定で、登録、検索、入力、購入、取消しなど、提供する主要な操作を通して確認します。ネットワークエラーや空の一覧など、普段は出にくい表示も対象に含めます。
修正報告には、端末、OS、アプリの版、言語・地域設定、操作手順、画面と文字列IDを残します。「訳が変」という報告だけでなく、意味の誤り、表示の欠け、操作との不一致を区別すると、翻訳担当と開発担当が修正箇所を判断しやすくなります。本記事で特定アプリの実機試験を行ったわけではなく、ここでは確認工程の設計を示しています。
公開後の更新とサポートまで、同じ版で管理する
Google Playの公式案内では、アプリのストア掲載情報のローカライズが説明されています。ストアの紹介が翻訳されても、アプリ内の画面まで同じ状態になるわけではありません。説明文、スクリーンショット、対応言語の表示が、実際に配信する版と一致しているかを確認します。
アップデートでは、追加・変更・削除した文字列を区別して渡します。同じIDでも機能の意味が変わった場合は再確認が必要です。未翻訳の項目をどう表示するか、公開を止める条件は何かを決め、言語ごとの進行状況を開発リリースと合わせます。
問い合わせ対応では、翻訳する人と不具合を調べる人を区別します。翻訳会社が自動的に技術サポートまで担うとは考えず、対応言語、受付経路、技術担当への引継ぎ、回答文の承認を決めます。公開後の言葉を直したら用語集や次回の原文にも反映し、同じ疑問が繰り返されない状態を作りましょう。
