IT翻訳では、説明書の文章だけでなく、ボタン名、エラーメッセージ、通知、ヘルプ、リリースノートなどが翻訳対象になります。用語が正しくても、画面で切れる、変数が表示されない、説明と実際の操作が一致しない、といった問題があれば利用者は困ります。
そのため、翻訳する言葉と、アプリやサービスの動きとを結び付けて準備することが大切です。ここでは、製品担当者がIT翻訳を依頼するときに整理したい資料と、更新時に確認する項目をまとめます。実装の例にはAndroidの公式資料を用いますが、利用する技術に応じた確認は開発担当者と行ってください。
対象を「製品に組み込む文」と「説明する文」に分ける
まず、翻訳対象をファイル名だけでなく用途で整理します。画面のボタンや通知は製品の動作と直接結び付きます。ヘルプやマニュアルは操作の順序を説明し、販売ページは製品の価値や利用条件を伝えます。同じ日本語でも、文を置く場所によって適切な長さや表現が変わります。
| 対象 | 翻訳者に渡す情報 | 完成時の照合 |
|---|---|---|
| UIの文字列 | 識別子、画面、操作前後の状態、変数 | 表示、操作結果、文字切れ |
| 通知・エラー | 表示条件、原因、利用者が取れる対応 | 誤解や不要な操作を招かないか |
| ヘルプ・マニュアル | 対応バージョン、正式な画面名、手順 | 画面との一致、参照リンク |
| 販売・更新案内 | 対象市場、提供範囲、変更点 | 未提供の機能を約束していないか |
製品に組み込む訳文は、実装担当が受け取る形式も先に決めます。文章の一覧を納品するだけなのか、指定のリソースファイルを返すのかによって、担当する作業と確認の範囲が異なります。
短いUIほど、画面と操作の文脈を添える
「保存」という一語でも、新規作成、既存内容の上書き、変更の一時保存など、対象となる動作を確かめる必要があります。「戻る」は前の画面に戻るのか、処理を取り消すのかで意味が違います。短い語ほど、周囲の文から意味を補えないことがあります。
依頼用の一覧には、変更されない管理用の識別子と、翻訳対象の文字列を別の欄に置きます。さらに、画面の画像、表示条件、文字数上限の有無、利用者が操作した後の結果を添えます。個人情報を含む画面を参考資料にする場合は、依頼前に必要な範囲へ整理してください。
Androidのローカライズ案内も、UIの内容をリソースに置き、アプリの中核となる機能から分離する考え方を示しています。翻訳対象を明確に分けることは、更新範囲を追ううえでも役立ちます。具体的な構成は製品の技術仕様に従います。
変数・タグ・複数形を普通の文章として書き換えない
通知の中には、利用者名や件数を実行時に差し込む部分があります。例えば%1$sのような記号は、表示する言葉そのものとは限りません。意味が不明な記号を削除したり、日本語の記号に置き換えたりせず、開発担当から役割と変更可否の説明を受けます。
Androidの文字列リソースの仕様では、書式設定引数や数量に応じた文字列が説明されています。必要な複数形の区分は言語によって異なるため、「日本語が一つの形なら、他の言語も一つで足りる」とは限りません。翻訳と実装の両方で対応を確かめます。
訳文の語順に合わせて差し込む位置を変えられる場合もありますが、使っている形式のルールを確認してから行います。XML、JSON、別のテンプレート形式の記法を混ぜないことも重要です。納品時には変数の名称と個数、対応するタグ、引用符などを確認し、読みやすさだけで完成としません。
確認用の値には、短い名前だけでなく長い名称、件数がゼロの場合や複数の場合などを用意すると、文章と表示の問題を見つけやすくなります。どの値を試すかは、実際の機能と対象言語に基づいて決めます。
製品用語を画面・ヘルプ・更新案内でつなぐ
同じ機能を画面では「ワークスペース」、ヘルプでは「作業領域」と呼ぶと、利用者が別の機能だと受け取る可能性があります。用語集には、原語と訳語だけでなく、機能の説明、使う場所、翻訳しない名称、採用を避ける候補を記録します。
一般的なIT用語として正しい訳でも、製品の意味に合うとは限りません。例えば「アカウント」が個人のログイン情報なのか、企業単位の契約なのかを確認します。既存の画面用語を変更する場合は、ヘルプ内の説明や検索語、関連通知への影響も調べます。
用語を決める人と、仕様への質問に答える人を分けて指定しておくと、回答を待つ場所が明確になります。翻訳者からの照会には、対象の識別子と画面を添え、回答を一括して反映できるようにします。
翻訳完了後に、実際の表示と動作を確認する
原文と訳文の照合に加え、製品へ組み込んだ状態での確認を計画します。小さい画面での改行、ボタンの幅、文字の重なり、文字化け、リンク先、表示順などは、一覧表だけでは判断しにくい項目です。対象言語のフォントや入力方法も含め、実際の利用条件に近づけて確認します。
Androidの公式案内には、必要なデフォルトリソースが欠けることで、特定の言語設定でアプリが動作しない例が示されています。これは翻訳文の良し悪しとは別の実装上の確認です。翻訳担当者の校正と、開発担当者の動作試験を分担し、問題が見つかった画面と条件を記録します。
レビュー用の環境を渡せない場合は、画面の連続画像や録画で確認できる範囲を定めます。その場合、未確認の操作や表示条件を検収記録に残し、実機で試したかのように扱わないことが大切です。
リリースのたびに変更箇所と対応版を残す
緊急修正で直接書き換えた訳文も、後から正式な管理ファイルへ戻しておきます。画面だけ直して一覧に反映しないと、次の更新で古い訳に戻る原因になります。
更新時は、新規の文字列だけでなく、意味が変わった既存の文字列、削除された機能、参照先が変わった説明も確認します。管理用の識別子が同じでも意味が変われば再翻訳の対象です。文章が同じでも、表示条件が変わった場合は見直しが必要になることがあります。
納品には、対応する製品バージョン、原文の確定日、変更一覧、用語の決定事項、未解決の質問を添えます。翻訳を差し替えた後に画面を再確認し、承認した版と公開する版を一致させます。こうした記録があれば、次の更新で既存の訳をどこまで再利用できるかを判断しやすくなります。
