UIテキストを正しく翻訳する方法-パート2：視覚的コンテキスト

ローカリゼーションUIテキストに関する前回のブログ記事（UIテキストを正しく翻訳する方法-パート1:IDベースのローカリゼーション）では、IDベースのローカリゼーション環境を使用することが重要な鍵となることを説明しました。一般的なソフトウェアプロジェクトでは、多くのターゲット言語に対して定期的な更新が発生し、これらは小規模であることがほとんどです。IDベースのコンセプトは、固有のIDまたはソーステキスト、あるいはその両方が変更されないかぎり、更新プロセスの間も既存の翻訳が維持されることを保証するものです。これにより、翻訳者は新しい文字列と変更された文字列に集中することができます。プロジェクトマネージャが、他の文字列が影響を受けるのではないかと心配する必要はありません。

ローカリゼーションプロジェクトの準備が完了したら、プロジェクトマネージャは翻訳者にジョブを「送信」します。ジョブは、物理的なファイルとして送信される場合と、オンラインの翻訳エディター上のタスクとして配信される場合があります。翻訳者が翻訳エディターで翻訳タスクを開くと、ソーステキストとその翻訳が表形式で表示されます。翻訳環境では、選択したテキストに関する追加情報（ソフトウェアの文字列IDや翻訳者が入力したコメントなど）が表示されます。 翻訳メモリ（TM）および機械翻訳（MT）との連携により、未翻訳のテキストに対する翻訳の候補が提示されます。

SDL Trados Studioの翻訳エディター画面

UIテキストは短く、あいまいで、変数を含む場合や、長さが制限されている場合があります。エディターで表示される順序がランダムな順序となることもあります。コンテキストが明確でないと、翻訳者が正しい翻訳を行うことは非常に困難です。

クエリーで問い合わせるべきか否か

多くの場合、翻訳者は、翻訳対象の特定のテキストに関する詳細を翻訳プロジェクトのマネージャに問い合わせます。そして、プロジェクトマネージャが開発者に情報提供を依頼することもあります。当社のあるお客様は、クエリーの対応に平均で約2時間の工数がかかると打ち明けてくれました。これは、翻訳される言語が少ない小規模なアプリケーションでは許容されますが、ターゲット言語が多い大規模なアプリケーションでは莫大なコストと遅延が発生する可能性があります。

翻訳者は翻訳したワード数に応じて報酬を得ることが一般的です。特定の用語がどのように使われているかを研究するための金銭的なインセンティブはありません。その結果、クエリーの数は少なくなります。そして、他の関係者（稼働中のアプリケーションをテストする言語テスターなど）が後工程で検出するエラーが増えることになります。

クエリーが発生すると、生産性が低下する上にコストもかかりますが、翻訳者からのクエリーが十分でないと後工程で問題を解決するための作業が増えることになります。問題が検出されるタイミングが遅くなるほど、修正のためのコストは増加します。

コンテキストタイプ

基本的には、翻訳者が正しい翻訳を行うために役立つあらゆる情報がコンテキストです。たとえば、説明文やスクリーンショットもコンテキストです。開発者が特定のソーステキストについて説明文を提供している場合もありますが、通常、翻訳者にとっては十分な情報ではありません。

翻訳者がエディターでテキストを選択すると、エディター上の現在の翻訳を含むプレビューが表示され、選択したテキストが強調表示されていることが理想的であると言えます。テキストを変更するとプレビューが自動的に更新されます。

SDL Trados StudioのRigi拡張では、ソフトウェア翻訳者向けにインタラクティブなHTMLプレビューを提供しています。

当社のあるお客様によると、このコンテキストによって翻訳者からのクエリーが半減したケースがあるそうです。

コンテキストを作成する方法

アプリケーションでどのテキストが使用されるか、また、これらのテキストがソフトウェアアプリケーションのユーザインタフェースでどのように表示されるかは、通常、ソフトウェアの開発部門が把握しています。

ソフトウェアアプリケーションの各テキストには固有の文字列識別子（ID）があります。これらの文字列IDごとにプレビューできる環境が理想であり、そのためのさまざまなアプローチがあります。たとえば、開発者がスクリーンショットをキャプチャし、これを（手動で）文字列IDと関連付けることができます。これにより、翻訳ツールで翻訳者向けにスクリーンショットの情報を表示することができます。ただし、このアプローチには重大な欠点があります。なにより、プレビューが静的であり（つまり、インタラクティブではなく）、翻訳者はユーザインタフェース上で翻訳がどのように見えるのかを知ることができません。さらに大きな問題は、開発者によるプレビューの作成とメンテナンスにかかる工数です。UIの画面が変更される場合は特に問題で、アプリケーションの拡張とともに作業量は増加します。

エラーメッセージのようなテキストタイプの多くはUIで表示しづらいことがあります。そのような場合は、コンテキストに関するコメントを提供する方法が最も簡単です。

もう1つの課題はUIテキストに含まれる変数です。たとえば、’{0} plays.’というソーステキストの変数{0}が、アプリケーションの実行時に氏名で置換されるとします。この情報がないと、翻訳者は文字列を正しく翻訳することができません。

翻訳者向けのコンテキストは、開発プロセスから独立している必要があります。また、アプリケーションが動作しない場合でもアクセスできる状態でなければなりません。そのため、アプリケーションからプレビューをキャプチャして保存する方法が必要になります。

自動化

ほとんどの場合、開発者は自動化されたテスト環境を構築し、スクリプトによってアプリケーションを実行します。これらのテストでは、アプリケーションのほとんどのページにアクセスします。このプロセスの間にコンテキスト情報をキャプチャして、UIに表示される文字列を正確に把握できるような一連のプレビューを取得することが理想的であると言えます。このプロセスを拡張しても、既存のスクリプトには影響しません。また、テストのスピードを大幅に低下させることもありません。

UIテキストを翻訳するための適切なツール

これらのツールは、少なくともUIテキストの視覚的ローカリゼーションをサポートするものでなければなりません。翻訳者がテキストを選択すると、現在の翻訳を含むインタラクティブなプレビューがすぐに表示される環境です。プレビューに含まれる変数は、プレビューが作成された時点の値で置換されます。
このようなインタラクティブなプレビューでは、翻訳者もテキストを選択できるようにしなければなりません。プレビューで別の問題を見つけた場合に、インタラクティブなプレビューでそのテキストを選択する必要があるためです。これにより翻訳エディターで該当する文字列が選択され、すぐに修正することができます。

ある言語をゼロから翻訳するようなプロジェクトでは、稼働中のWebアプリケーションのインタラクティブな翻訳プレビューが有用なケースもあります。その場合、事前にプレビューをキャプチャする必要がないため、翻訳者はすぐに作業を開始することができます。このアプローチの欠点は、翻訳者がアプリケーションを操作する方法を把握し、特定の画面や機能にアクセスする権限を持っている必要があることです。このようなアプローチは、社内翻訳者の場合には適しているかもしれませんが、通常、開発者は、翻訳者が稼動中のアプリケーションにアクセスすることは好ましくないと考えています。