UIテキストを正しく翻訳する方法-パート1：IDベースのローカリゼーション

著者は、ローカリゼーションの専門知識を持つコンサルタントおよびソリューションアーキテクトとして、多種多様な市場に適した品質と納期を実現しながらローカリゼーション製品をリリースする支援しています。ローカライズの対象には、オンラインヘルプ、トレーニング教材、マーケティング資料、使用説明、ラベル、UI （ユーザインターフェース）テキストなどが含まれます。

ソフトウェアの UI テキストは、翻訳対象のテキストの中ではほんの一部に過ぎず、通常はわずか5%前後にしかなりません。全体から見れば、ごくわずかなボリュームしか発生しないため、ほとんどの企業は、マニュアル文書のような長い文書を翻訳する際に使用する翻訳管理ツールをUIの翻訳にも使用しています。 残念ながら、翻訳支援ツールはUIテキストを正しくローカライズするための重要なコンセプトを欠いており、その１つはIDベースのローカリゼーションです。

翻訳支援ツールの代わりにソフトウェアのローカリゼーションツールを使用すると、開発者は、アプリケーションのソーステキストに更新が発生した際に、翻訳ジョブをより速く、適切な形で準備することができるようになります。 本稿では、翻訳メモリ（TM）を使用したアプローチとIDベースのアプローチの違いについて説明します。

翻訳メモリの場合

トレーニングマニュアルが5言語に翻訳され、すべてのセグメントが翻訳メモリに格納されているとします。マニュアルの著者が新しい章を追加し、ソーステキストを変更しました。修正されたドキュメントは翻訳する必要があります。

翻訳者に依頼を送信する前に、翻訳メモリを使用して事前に翻訳できる個所を変換します。 このプロセスでは、ドキュメントを文単位で分割し、既存の翻訳に類似するものがないかを照らし合わせます。

ある文とその前後の文がそれぞれ同じテキストであれば、いわゆる「ICE（in-context exact）マッチ あるいは101％マッチ」として検出され、前後関係も正しく読み取れるため翻訳メモリに存在する翻訳をそのまま問題なく使用できます。一方で、原文とその前後のセグメントが異なる場合には、翻訳文に対するペナルティが付与されます。ペナルティが付与された文は、いわゆる「あいまい一致」という扱いになり、たとえば、文字列が「87％」同じであることを数値で示したりします。

翻訳会社は、UIテキストを翻訳する際にも文字列をあいまい一致または完全新規のいずれかに分類して見積書を提出します。このやり方では、お客様はすでに翻訳されたコンテンツと同じテキストには支払をする必要がありません。そのため、大企業は通常、翻訳ジョブを自社で管理しており、翻訳メモリを用意しています。

このアプローチは、長文テキストのようにソーステキストがあまり変化しない場合にはうまくいくことが多いのですが、著者がソースドキュメントで変更した箇所を表示したり、他の翻訳者が過去に行った変更を確認したりすることはできません。また、文書とUIの間で使用される用語の整合性を確保する必要があります。 そのため、翻訳メモリと一緒に用語管理システムが使用されることがしばしばあります。

原文のテキストをベースにして「翻訳メモリ」を適用する際に発生する一番の問題点は、たとえテキストが同一であっても、正しい訳の候補が必ずしも選択されているわけではないということです。そのため、翻訳者の作業依頼を行う前後の工程で品質を保証する手順が必要になります。

IDベースの場合

UIテキストは、長文と比べて基本的に異なる特性を持ちます。テキストはリソースファイル（json、properties、resxなど）に格納されます。

各テキストには文字列識別子（ID）があります。ソフトウェアアプリケーションは、IDを参照してUIテキストを表示するため、IDはソフトウェアアプリケーションのライフサイクル内で変更されることがありません。

各ターゲット言語/ロケールに対して、それぞれ別のリソースファイルが存在します。アプリケーションの実行時には、選択した言語とロケールに応じた適切なリソースファイルから、IDに基づいてテキストを取得します。

仮に、開発者がリソースファイルの文字列の順序を変更したり、新しい文字列を挿入したりしても、IDをベースにしているため、既存の翻訳には影響がありません。

翻訳メモリを使用してUIテキストを翻訳する

翻訳メモリを使用してUIテキストを翻訳すると、多くのファジーマッチが生成されてしまいます。一部の翻訳メモリでは、文字列IDを変換して格納できますが、同じ文字列IDに複数の翻訳が存在する場合、古い翻訳メモリが選択されてしまうことがあります。これは単に信頼性が低いだけでなく、大規模なプロジェクトでは問題が大きくなります。

異なるアプリケーションで複数回同じ (短文の)ソーステキストが発生した場合、問題が発生します。たとえば、当社のお客様の中には、「application」という用語を使用して、「software application （ソフトウェアアプリケーション）」、「job application（求人申込み）」、「apply setting（設定を適用）」などの異なる意味を持たせているケースがありました。翻訳メモリをベースにした場合は、文字列識別子を無視してしまうため、アプリケーションを更新するたびに間違った翻訳が適用されてしまい、修正作業が大量に発生してしまうことがあります。

翻訳メモリツールを使用してIDをベースにしたUIテキストを翻訳すると、ローカリゼーションのプロセスの各関係者に、直接・間接を問わず影響を与えます。 たとえば、開発者、テスター、プロジェクトマネージャ、言語テスター、マーケティング担当者、組織のリーダーなどがそれに含まれますが、何よりも重要なのは顧客です。エンドカスタマーである顧客企業にコスト増や、品質課題、市場投入の遅れなどの不利益が発生することになってしまいます。

ローカリゼーションに関する内部コストのほとんどは、翻訳ジョブを送信する前段階に発生します。IDをベースにしたUIテキストなのに、翻訳メモリを使用してしまったことにより、翻訳前処理が適切に行われず、手動で翻訳を修正する必要があります。これは手間がかかる割に退屈な仕事で、エラーが発生しやすく、費用もかかります。翻訳者がこうした仕事を拒否するのを何度も目にしてきました。

適切なツールを使用してUIテキストを翻訳する

UIテキストをローカリゼーションする際のツールは、最低でもIDをベースにしている必要があります。ソフトウェアテキストには、文字列ID、ソーステキスト、そしてさまざまな言語の翻訳が含まれており、それぞれの翻訳には、ステータス（未翻訳、仮翻訳、レビュー済、翻訳済）を付与します。

多くの言語で既に翻訳され、検証されているソーステキストに開発者が変更を加えると、ステータスは「完了」から「仮翻訳」に戻されます。翻訳者は元のソーステキスト、修正されたソーステキスト、およびその文字列IDの現在の翻訳を参照することができるため、翻訳を迅速に対応できるようになります。

開発者が翻訳対象の新しいソースファイルを送信すると、プロジェクトマネージャはIDをベースにして翻訳プロジェクトファイルを更新します。変更された文字列と新しい文字列はすぐに認識されますが、ソーステキストが変更されていない文字列は対象外となります。プロジェクトマネージャは、翻訳者に新しい文字列と修正された文字列を翻訳するよう指示します。翻訳メモリがある場合は無駄にはなりません。翻訳者は翻訳作業中にそれを参照して提案訳を得ることができるからです。

IDベースのコンセプトを適用すると、プロジェクトマネージャはUI翻訳プロジェクトを正しく管理することができます。ソーステキストおよび/または文字列識別子が変更されない場合は、既存の翻訳を正しく維持することができます。翻訳者もまた、ソーステキストおよび翻訳に関する時系列の情報を得ることができるので、作業時間の節約にもなりますし、エラーの数を減らすこともできます。新規と変更された文字列だけに焦点を当てることができます。

投資対効果

間違ったツールやコンセプトの下でも翻訳はできますが、時間がかかり、品質も低下します。そして何より精神的に負担が大きくなります。翻訳メモリを使用してソフトウェアUIテキストの事前翻訳処理を行うと、社内のコストは急増します。問題の解決と、修正パッチを作成するための非効率な作業を強いられることになります。

IDをベースにしたローカリゼーションツールでは、事前翻訳処理に起因するエラーを防止し、修正作業を削減できます。どれだけのコストと時間が節約できるかは、ボリュームや、ソース文字列の総数、ターゲット言語の数、リリースごとの新規文字列および変更文字列の平均数、そして年間のリリース回数によって決まります。翻訳支援ツールを使用した場合には、生成されるエラーの数もこれらの値に比例して増えることになります。

UIテキストが少量の場合には、ソフトウェアのローカリゼーションツールの費用を正当化できないことがありますが、リリースの数、テキスト、言語が増加すれば、その投資はすぐに回収できるのです。