一度でも何らかの形でUI翻訳に関わった事のある方なら、その特殊性や難しさを実感したことがあるかもしれません。「UI翻訳の不満と悩み」と題して、前編と後編の2本立てでUI翻訳の課題をご紹介します。前編​​​​​の今回は、これまで一般的であったUI翻訳の方法をみながら、翻訳依頼者が感じる不満、そして翻訳者が感じる悩みをそれぞれ見ていきます。

次回に続く後編では、それら各課題に対して川村インターナショナルが提案するベストプラクティスをご紹介します。

これまでのUI翻訳

これまでのUI翻訳では、大体はこのような流れが一般的ではないかと思います。
※すでにツールを導入されている場合や、フローが出来上がっている場合は除きます。

例えば、エクセルで翻訳を行う場合、翻訳依頼者は品質の高い翻訳を提供してもらうために、翻訳作業前に大量の参考資料を用意する必要があります。ソフトウェアへのアクセス権、翻訳済みUIリスト、場合によっては大量のスクリーンショットを取る必要もあるかもしれません。

逆に、翻訳者はよい翻訳のためにしつこく参考資料を求めていかなければいけません。不幸な事に、まったく参考資料が支給されずに翻訳を進めなければならないという事もあります。そして翻訳された後、システムに実装された状態での表示（見え方）チェックとQA（品質保証）を経て、何か翻訳に関する課題が生じた場合は依頼者、翻訳者間でのやり取りが生じます。

つまりUIの翻訳というのは、翻訳の前後工程で様々な作業と労力を必要とします。当然、依頼者、翻訳者の負担も大きくなりがちです。

依頼者が感じる3つの不満

ではUI翻訳の際にどのような不満が生じうるのか、具体的に3つの例を挙げ、翻訳依頼者の視点で見ていきます。

• 不満①　翻訳の品質に問題がある
• 不満②　翻訳者や翻訳会社とのやり取りの効率が悪い
• 不満③　アジャイル開発への対応が難しい

不満①　翻訳の品質に問題がある

そもそも「誤訳」、「訳抜け」や「タイポ」はもってのほかですが、UI翻訳の品質に問題がある例として、以下があります。

例1：「Eメールを入力」というテキストが長いため、枠にかぶってしまっています。

例2：黄色ハイライトされているテキストが画面内に収まっておらず、途中で切れてしまっています。

翻訳エラーといっても様々なエラーがあります。これらの一つ一つをどうやって解決するかという個別のアプローチはもちろんですが、根本的な原因を解決することが肝要です。

不満②　翻訳者や翻訳会社とのやり取りの効率が悪い

必ずしも、翻訳者や翻訳会社に開発言語や開発環境に精通した人がいるとは限りません。（社内で専門の翻訳者がいる場合は除きます。）

これらは翻訳品質の問題とも深く関連しますが、そもそもUI翻訳というのは何か問題が起こると、どうしてもやりとりが多くなってしまいます。さらに、翻訳依頼先がアプリケーションの開発に対する知識やノウハウを持っていなければ、無駄なやりとりが発生してしまいます。その結果、全体的な効率を落としてしまうという悪循環になります。

不満③　アジャイル開発への対応が難しい

近年ではアジャイル開発を採用する企業が増えてきましたが、翻訳の際にこれにうまく対応できないという問題が生じています。アジャイル開発は、小さなサイクルで計画から設計・開発・テストまでの工程を繰り返すことができます 。

一方で、翻訳プロセスの視点では、翻訳対象テキスト自体は少量になるものの、短納期での対応が求められます。これにより、短納期であればあるほど翻訳者側の対応はどうしても限られたものになってしまいます。

以下に記載しているのはそれらが原因で生じる不満のほんの一例です。

これらを解決するためには、翻訳ツールやシステムなどを上手く活用し、アジャイル開発に即した形で翻訳を行う必要があります。

翻訳者が感じる3つの悩み

ここまで翻訳依頼者が感じる課題や不満を説明してきました。一方で、翻訳をする側にも悩みがあります。

• 悩み①　画面が見えない
• 悩み②　レポートする手段がない
• 悩み③　選択肢が少ない

これらは特にUIの翻訳において翻訳者を悩ませる課題です。

悩み①　画面が見えない

UI翻訳が難しい一番の理由は、実際のアプリケーション画面が見えないことです。

依頼者からアプリケーションへのアクセス権限が与えられて、実際の画面を見ながら翻訳できるケースも稀にあります。しかし、仮にできたとしても入力長の制限がわからないですし、該当のテキストの場所を特定するのは大変です。

また、メッセージなのかボタンなのかの区別ができないと、「ですます調」なのか「体言止め」なのかといった文体が判断できず、適切に訳し分けできません。

翻訳者が翻訳する際に、実際の画面を見ながら、どのくらいの入力長なら入力可能なのかを確認しながら作業できるような環境が必要です。

悩み②　レポートする手段がない

特にアジャイル開発では、短納期で対応するために複数の翻訳者が投入されるプロジェクトも珍しくありません。

そのため、翻訳中に原文の不備などを発見した場合は適宜対応が必要です。その時点で依頼者に確認し、一旦プロジェクトに参加している翻訳者全員にその状況を共有した方が後々の作業を効率化できることがあります。

ただ、どうしてもこういったケースでは、スケジュールの都合で納品時の申し送りなど一括で処理されてしまいがちです。

悩みの③　選択肢が少ない

UIの翻訳においては、納期や予算はもちろんですが、翻訳会社と翻訳者がそれぞれ制約のある中で対応することが求められます。

レアケースかもしれませんが、例えば、UIを各国語に翻訳する際、社内レビュアーとして、各国語のネイティブが用意できているケース。「下訳さえもらえれば、あとはネイティブがいかようにも修正します」といった依頼の際に、依頼を受ける翻訳会社は適切な方法を提案できるか、という事です。それがサービスレベルでの提案なのか、ツール面での提案なのかは様々なケースがありますが、選択肢を多く持っていれば、様々なケースに柔軟に対応できます。

また、社内で翻訳を請け負う翻訳者の場合、セキュリティの問題で使用できるツールが制限されることもあり得ますし、業務委託で翻訳を行っているケースなどは、そもそも依頼者とのコミュニケーションが効率よくできないこともあり得ます。

重要なのは、依頼者のご要望や状況に応じた適切な対応ができるかどうか、また適切な方法をご提案するための手段を多く持ち合わせているかどうか、という事です。

まとめ

いかがでしたでしょうか。

UI翻訳はどうして難しいのか、手間がかかるのかを翻訳依頼者/翻訳者のそれぞれの視点から見てきました。次回、後編では落としどころの見つけにくいこれらの課題について、川村インターナショナルが提案するベストプラクティスをご紹介します。

関連記事

• UI翻訳はなぜ厄介なのか？翻訳会社が提案する新たなソリューション
• UIテキストを正しく翻訳する方法-パート1：IDベースのローカリゼーション
• UIテキストを正しく翻訳する方法-パート2：視覚的コンテキスト