IT・ソフトウェア翻訳のポイント｜アプリ・SaaS・UIをローカライズする方法
- Acima Corp.
- 7 時間前
- 読了時間: 8分
ソフトウェア翻訳は、一般的な文書翻訳とはかなり性質が違います。
法人向けの翻訳をご検討の場合は、アシーマの翻訳・ローカリゼーションサービスもご覧ください。
WordやPDFの文章であれば、前後の文脈を読みながら意味を判断できます。しかし、アプリやSaaSの翻訳では、「Save」「Open」「Back」「Cancel」のような短い文字列だけが一覧で渡されることも多く、その言葉がどの画面で、どの機能として使われるのか分からないまま翻訳しなければならないケースがあります。
さらに、文字数制限、ボタン幅、変数、HTMLタグ、改行位置、エラーメッセージ、プレースホルダー、OSごとの表示差なども考慮する必要があります。
そのため、ソフトウェア翻訳では、単に日本語として正しい訳文を作るだけでは不十分です。実際の製品画面で正しく機能し、ユーザーが迷わず操作できることまで含めて翻訳品質を考える必要があります。
「Save」はいつも「保存」ではない
ソフトウェア翻訳で難しいのは、短い単語ほど文脈によって意味が変わることです。
例えば「Save」という単語でも、
ファイルを保存する
設定内容を確定する
入力フォームの変更を反映する
お気に入りに登録する
データをクラウド上に保持する
など、使われる場面によって意味が変わります。
そのため、機械的にすべて「保存」と訳せばよいわけではありません。
「Open」も、ファイルを「開く」場合もあれば、メニューを「表示する」場合もあります。「Close」はウィンドウを「閉じる」なのか、アカウントを「解約する」なのかで意味がまったく異なります。
ソフトウェア翻訳では、文字列だけでは判断できないケースが非常に多いため、画面キャプチャ、機能説明、文字列ID、前後のUI情報などが重要になります。
翻訳者が実際の画面を見ることができれば、「このSaveは保存なのか確定なのか」「このBackは戻るなのか前の画面なのか」といった判断を正確にしやすくなります。
UIでは「正しい翻訳」より「分かりやすい翻訳」が優先されることもある
一般文書では、原文の意味を正確に伝えることが最優先です。
一方、UIでは、意味が正しいだけでなく、ユーザーが一瞬で理解できるかどうかも重要になります。
例えば、英語で短いボタン名が、日本語にすると長くなりすぎる場合があります。
英語では1語で済むものが、日本語では説明的な表現になり、ボタンから文字がはみ出したり、スマートフォン画面で改行されたりすることがあります。
そのような場合は、意味を保ちつつ、UI上で自然に見える短い表現に調整する必要があります。
これは通常の翻訳というより、ローカリゼーションに近い作業です。
変数やタグを壊さない
ソフトウェア翻訳では、文章の中に翻訳してはいけない記号やコードが含まれることがあります。
例えば、
{name}
%s
%d
{{username}}
<strong>
<br>
HTMLタグ
JSONのキー
XMLタグ
などです。
こうした部分を誤って変更すると、表示が崩れるだけでなく、場合によってはシステム自体が正しく動かなくなることがあります。
例えば、
Hello, {name}
という文字列で {name} を誤って変更してしまうと、ユーザー名が正しく挿入されなくなる可能性があります。
また、翻訳者が記号の意味を理解せず、スペースや句読点を追加しただけでエラーになるケースもあります。
そのため、IT・ソフトウェア翻訳では、語学力だけでなく、ファイル構造や変数、タグの扱いについて一定の理解があることも重要です。
IT・ソフトウェア分野を含む法人向けの翻訳・ローカリゼーションサービスに対応しています。
エラーメッセージは「読める」だけでは足りない
エラーメッセージも、ソフトウェア翻訳では重要な要素です。
例えば、
Invalid input.
を単純に「無効な入力です」と訳しても、ユーザーが何を直せばよいのか分からない場合があります。
どの項目でエラーが起きているのか、入力形式が違うのか、文字数制限を超えているのかによって、本当に必要な表現は変わります。
また、開発者向けのエラーメッセージと、一般ユーザー向けのエラーメッセージでは、求められる文章も違います。
法人で継続的な翻訳や専門分野の翻訳が必要な場合は、アシーマの法人向け翻訳・ローカリゼーションサービスもご確認いただけます。
技術的に正確であっても、一般ユーザーには難しすぎる表現になっている場合があります。
そのため、エラーメッセージでは、誰が読むのか、何をすれば解決できるのかまで考えて訳す必要があります。
用語統一はUXに直結する
ソフトウェアでは、同じ機能に対して複数の訳語が使われると、ユーザーを混乱させます。
例えば、同じ「Settings」という機能が、
設定
環境設定
オプション
各種設定
と画面ごとに変わっていたら、ユーザーは「別の機能なのか」と感じる可能性があります。
同じことは「Account」「Profile」「Dashboard」「Workspace」などにも起こります。
一般文書では多少の言い換えが自然な場合もありますが、ソフトウェアUIでは、同じ機能名は原則として同じ訳語を使うことが重要です。
そのため、プロジェクトの初期段階で、
機能名
ボタン名
メニュー名
製品名
サービス名
固有機能の名称
などを用語集として決めておくと、後の修正が大幅に減ります。
特に複数の翻訳者が参加する大型案件では、用語集なしで進めると訳語が揺れやすくなります。
文字数制限は後からではなく最初に伝える
アプリやソフトウェアでは、表示できる文字数に制限があることがあります。
特に、
スマートフォンアプリ
ナビゲーションメニュー
タブ
ボタン
ポップアップ
通知
ウィジェット
などでは、長い日本語が画面に収まらないことがあります。
翻訳が完成してから「このボタンには8文字しか入らない」と伝えられると、翻訳をやり直さなければなりません。
そのため、文字数制限がある場合は、翻訳開始前に、
最大文字数
1行か複数行か
PCとモバイルで幅が違うか
省略表示が可能か
などを共有した方が効率的です。
ソフトウェアでは画面上のテストが重要
翻訳ファイルだけを確認しても、すべての問題を見つけることはできません。
実際のソフトウェアに翻訳を反映して初めて、
ボタンから文字がはみ出している
改行位置がおかしい
文脈に合わない訳語が使われている
変数が正しく表示されない
性別や単数・複数の表現が不自然
エラーメッセージが状況に合っていない
といった問題が分かることがあります。
そのため、可能であれば、翻訳後にテスト環境やステージング環境で画面確認を行うことが理想です。
これはLQA（Linguistic Quality Assurance）や言語QAと呼ばれる工程の一つです。
更新が前提の案件として設計する
SaaSやアプリは、一度公開して終わりではありません。
新機能が追加され、画面が変わり、既存機能の名称が変更されることもあります。
そのたびにゼロから翻訳していると、過去と違う訳語が使われたり、同じ文章を何度も翻訳したりして、コストも品質も安定しません。
そこで重要になるのが、
用語集
翻訳メモリ
既訳データ
差分翻訳
バージョン管理
です。
例えば、今回のアップデートで変更された文字列が100件だけなら、アプリ全体を翻訳し直す必要はありません。変更箇所だけを抽出し、既存翻訳との整合性を確認しながら更新する方が効率的です。
長期運用するソフトウェアでは、初回翻訳よりも、その後の更新フローをどう設計するかの方が重要になることもあります。
翻訳会社に渡すと助かる資料
ソフトウェア翻訳を依頼するときは、原文ファイルだけではなく、できるだけ多くのコンテキストを共有すると品質が上がります。
特に役立つのは次のような情報です。
画面キャプチャ
文字列がどこで使われるか分かるため、文脈判断がしやすくなります。
機能説明
ボタンやメニューが何をする機能なのか分かれば、訳語を選びやすくなります。
用語集
製品名、機能名、固有表現を統一できます。
文字数制限
UIからはみ出さない表現を最初から検討できます。
変数やタグの仕様
翻訳してはいけない部分を明確にできます。
既存の英語版や他言語版
過去の表現やブランドトーンを確認できます。
テスト環境
実際の画面で文脈や表示崩れを確認できます。
対象ユーザーの情報
一般ユーザー向けなのか、技術者向けなのかによって表現を変えられます。
原稿だけを渡すより、翻訳者が完成した製品をイメージできる情報をどこまで渡せるかが、ソフトウェア翻訳では非常に重要です。
ソフトウェア翻訳は「完成画面で使えるか」がゴール
ソフトウェア翻訳では、訳文だけを読んで自然かどうかを判断しても十分ではありません。
最終的に重要なのは、実際の製品画面に入れたときに、その翻訳がユーザーの操作を助けているかどうかです。
意味が正しくても、ボタンから文字がはみ出していれば使いにくい。用語が画面ごとに違えばユーザーは迷う。エラーメッセージが分かりにくければ問題を解決できません。
そのため、ソフトウェア翻訳では、翻訳、用語管理、UI確認、テスト、アップデート後の差分管理までを一つの流れとして考える必要があります。
特にSaaSやアプリのように継続的に更新される製品では、「一度きれいに翻訳すること」より、「更新されても品質が崩れない仕組みを作ること」の方が重要です。
ソフトウェア翻訳の品質は、訳文単体ではなく、ユーザーがその製品を自然に使えるかどうかで判断すべきです。
アプリ・SaaS・UI翻訳をご検討の場合は、アシーマの法人向け翻訳・ローカリゼーションサービスをご覧ください。
関連する記事：マニュアル翻訳を依頼する際のポイント ／ 翻訳とローカリゼーションの違い
コメント