言語(Language)のデジタル変革(DX)には、デジタルデータの変換や入出力を支援する柔軟なソリューションが不可欠です。本連載（計4回）では、多言語化を必要とするさまざまなシーンにおいて、LDX hubを活用して効率をアップさせるポイントを解説します。今回のテーマは、UIの翻訳です。 

過去の記事

・（第一回）：数千ページを超えるPDFファイルを 効率よく機械翻訳するコツ 
・（第二回）：OpenAIとの連携によるLDX hubの可能性
 

目次

まず、本稿の主役の一つ、Rigiについて紹介します。 Rigiとは、WebアプリケーションのUIを可視化することに特化したクラウドベースのプラットフォームです。

一般的に、Webアプリケーションまたはソフトウェアをローカライズするというと、画面項目（ユーザーインターフェイス、UI）の翻訳を思い浮かべるのではないでしょうか。しかし、ローカライズの対象には多くの場合、オンラインヘルプ、トレーニング教材、マーケティング資料、仕様説明書など多様な要素が含まれており、UI テキストは通常、翻訳対象テキスト全体のわずか5%前後しか発生しません。

その一方で、翻訳量がごくわずかであるからといって、その特徴を理解せずにUIの翻訳を開始してしまうと、見えないコスト（ソフトウェアローカリゼーションの隠れたコスト）や翻訳者が感じる課題（UI翻訳の不満と悩み～依頼者/翻訳者それぞれの視点から）を軽視してしまうだけでなく、安易に機械翻訳を利用してしまい、ユーザーからの大きなクレームへとつながってしまうことがあります。

たとえば、UIテキストをExcelファイルにエクスポートして翻訳を行う場合、翻訳者の目線では、以下のような課題が頻発しています。
 

• 画面内や前後の画面のUIテキストとの整合性を確保することが難しい
• レイアウトや入力長などの制約に合わせて翻訳することができない
• テキストがどこでどのように使われるのか確証がない（ボタン、メッセージなど）
• 上記のような情報不足により問い合わせや申し送りが増える
   

 簡潔に言えば、コンテクスト（背景や場面）がわからないため正しく訳せないことが課題となっています。結果として、翻訳されたテキストを実際のUI画面で表示したときに、以下のような想定外の問題が発生します。 
 

• 表示領域に対して訳文が長すぎるため、すべてのメッセージが表示されていない
• 同じ単語に対して複数の訳語が用いられており、UIテキストが統一されていない
• 翻訳そのものは正しいが、画面に適していない（メッセージテキストが対話調に訳されていない等）
   

 翻訳する側にとっては限られた情報の中で最大限努力した結果だとしても、翻訳を依頼している側から見ればこれらは誤った訳文であり、修正する手間が発生します。

一般的に、翻訳に起因する問題が判明するのは翻訳後の画面テスト（言語テスト）時になってしまうため、修正のやり取りの多くは後工程になって発生します。また、UIテキストをExcelファイルにエクスポートして翻訳会社に発注している場合などは、修正対象のテキストがどの画面にあるのかわからないこともあり、照合作業にさらに手間がかかります。

こうしたケースにRigiを使用すると、画面を見ながら翻訳ができる上、UIテキストの翻訳に必要な機能が充実しているため、問題は一気に解決します。
 

次に、本ブログの主題であるLDX hubとの連携について説明します。LDX hubは、言語サービスの課題を解決するのに役立つ豊富なサービスおよびアプリケーションとのAPI連携機能と、それらを組み合わせたプロセスの自動化機能を提供しています。

サービスおよびアプリケーションを自由に組み合わせて連携させることができ、現在は2000通り以上の組み合わせで自動化が可能です。1つのドキュメントの入力を起点に、さまざまな変換･加工処理と機械翻訳を連鎖させて、ニーズに応じた多種多様な出力を得ることができます。RigiもLDX hubとAPI連携をしており、LDX hubの機械翻訳機能をUIテキスト翻訳に利用できます。

では、大前提として、UIテキストのローカリゼーションに機械翻訳を活用できるのでしょうか。UIテキストはボタンやプルダウンテキストなどの短い文字列であることが多いため、その翻訳は、適切な単語を当て込むような文字列の置き換えであることがほとんどです。一見、こうした置き換え作業は機械の方が得意なように見えますが、単語の訳には複数の可能性があり、機械では前後関係や背景情報、文脈を理解できないため、適切な訳語を充てられるとは限りません。

また、UIテキストの中でも、ボタン名には名詞句や体言止めのシンプルな翻訳が求められますが（「検索」「エラー」など）が、メッセージは対話調の訳語にしなければなりません（「検索してください」「エラーが発生しました」など）。機械翻訳ではこうした訳し分けもうまく処理してくれるとは限らないため、結局人による確認作業が発生します。

それでも翻訳のプロセスだけではなく、ローカリゼーションの全プロセスを眺めてみると、機械翻訳が役に立つ場面はあります。特に、ソフトウェアテストの工程では、ダミーテキストを入力して検証作業を効率化することができます。

ソフトウェア開発に関連するテストには様々なものがあります。開発工程ごとのテストや機能テスト、負荷や限界値を検証する性能テストもありますが、この中で、UIを確認しながら行うテストは、主に機能テストやユーザビリティテストです。意味を持たない「XXXXXX」などの文字列を入れてテストを実施することも可能ですが、現地の言葉が入っている方が、ユーザビリティの評価には役立ちます。たとえば、文字の大きさや文字列の長さ、記載内容の視認性を確認する目的であれば、機械翻訳で十分です。

また、プロトタイピング手法を何度も繰り返すようなソフトウェア開発では、何度もテストを繰り返すことになるため、低コストかつ時間もかからない機械翻訳を使うことには妥当性があります。

 Rigiを使用すると、機械翻訳を適用したテスト画面を瞬時に表示することができるため、翻訳プロセスの前にユーザビリティテストや機能テストを実施することが可能です。これらのテストでは、UI画面の設計変更などを伴うことがあり、上流工程に立ち戻ることがあります。こうしたリスクを考慮すると、翻訳プロセスとは別に実施できると手戻りの時間を短縮できます。

約1000行程度のUI テキストを３言語に翻訳するプロジェクトを想定してみましょう。多言語への翻訳の場合、単一の言語のプロジェクトの場合より、管理のコストはその分上昇し、修正にかかる手間も増大します。Rigiを使用すると多言語プロジェクトもシステム内で一元管理できるため、プロジェクト管理や修正にかかる手間は削減できます。

このほかにもRigiと機械翻訳を併用することでリリースまでの期間を短縮できるコツがありますので、以下で説明します。

図1

一般的には、翻訳後のテキストを画面に表示させてテストを実施するため、テスト工程の前に翻訳工程が発生します。ところが、Rigiを活用すると機械翻訳後のテキストをダミーテキストとしてテスト画面に表示した状態で確認することができるため、先にUIの視認性やユーザビリティのテスト、および機能面でのテストを実施することができます。これにより、UI画面の設計変更が発生した場合に、再度翻訳の依頼をかけるロスが発生しなくなります（図1の”７”の工程を削減できる）。

翻訳工程が終わった後にテストは必要になりますが、機能やユーザビリティの問題ではなく、翻訳やテキストに関する問題になるため、言語テストの工程でカバーすることができます（図2の”７”の工程）。

図2
 

機械翻訳そのままの出力ではUIテキストの翻訳は完了できません。すでに述べたとおり、機械では前後関係や背景情報、文脈を理解できないため、適切な訳語を充てられるとは限らないからです。判断は、人間の得意分野です。画面を見ながら機械翻訳の出力結果を修正（ポストエディット）することで、最初から人手で翻訳する場合と比較して、コストと時間を低減できる場合があります。

前述したとおり、Rigiを使用すると、テスト画面を表示しながら翻訳したり機械翻訳を確認したりできるため、最終的な翻訳の質が向上し、後工程での修正の数が劇的に減ります。

また、システム内でクエリのやり取りができるため、不明事項のやり取りを簡略化できるだけでなく、原文の修正を開発元に依頼しなくてはいけない場合もシステム内で一元管理でき、対象箇所がどこにあるかを検索する時間も大幅に削減できます。
 

Rigiの大きな強みの一つに、スクリーンショットの一括取得があります。修正が必要な箇所を発見した場合に、一言語分のスクリーンショットを取得すると、その他の対象言語のスクリーンショットを一括で取得することができます。

画面がわかれば、Rigi上でその対象箇所を検索して修正することが容易なため、修正の指示はスクリーンショットのやり取りで完結します。
 

Rigiは、UIテキストの翻訳に特化しているため、IDベースでUIテキストを管理しています。IDベースで管理することにより、並行して開発が発生しているときにも、修正や追加された行がどこであるかを瞬時に検出することができ、差分の管理も効率よく行うことができます。図示していたローカリゼーションのプロセスは、ウォーターフォール型の開発を想定していますが、アジャイル開発でこそ効果を発揮できるのがRigiの強みです。

このように、Rigiと機械翻訳を活用すると、ローカリゼーションにかかる合計作業時間が約20％（もしくはそれ以上）の短縮が見込めます。翻訳工程でのエラーが削減して、修正やコメントのやり取りも効率化できると、全関係者にメリットがあります。UIテキストのローカリゼーションにかかる時間を短縮したい方は、是非お試しください。

ブログ後半では、LDX hub を使用したRigiへの機械翻訳の適用フローについてガイダンスを記載しています。参考にしてください。

LDX hubでは、たとえば以下のような機械翻訳プロバイダを選択することができます。LDX hubを使用すれば、それぞれの機械翻訳エンジンとのAPIコネクタを開発する必要がないので、便利です。

• みんなの自動翻訳@KI 
• Google Cloud Translation Advanced
• Microsoft Translator
• Amazon Translate
• DeepL
• IBM Watson Language Translator 
• SAP Translation Hub
• SYSTRAN Translate
• ModernMT

＜手順＞

1. システム全体の設定として機械翻訳サービスの設定を行います(この設定は、SUBSCRIBER以上の権限を持つアカウントのみが行うことができます)。画面右上のプロフィールアイコンから「サーバー設定」をクリックします。

2. 「サーバー設定」画面で以下を設定します。

• MTプロバイダ：使用するMTサービス
• MTプロファイル：設定したMTプロバイダをもとにしたMT設定プロファイル
   

3. 「MTプロバイダ」メニューから「MTプロバイダの追加」をクリックし、認証情報などを入力してMTプロバイダを設定します。

4. 「MTプロファイル」画面で「プロファイルの追加」をクリックし、MTプロファイルに言語や使用するサービスを設定します。

5. 機械翻訳を使用する言語を追加します。

6. 追加した言語に、それぞれ利用する機械翻訳プロバイダとサービスを選択します。以上で設定は完了です。

MTプロファイルを複数設定しておくと、同じ言語でも翻訳対象のプロジェクトによって異なる機械翻訳サービスを利用する場合に機械翻訳サービスを使い分けることができます
 

7. 次に、プロジェクト内で機械翻訳の設定を行います。

8. 「テキスト」メニューの「概要」で、機械翻訳を適用したい言語にチェックを入れ、画面上の機械翻訳アイコンをクリックします。

適用される機械翻訳プロファイルおよび設定内容が表示されるので、間違いが無いかを確認し、「翻訳」ボタンをクリックします。

機械翻訳は、ステータスが「Untranslated」の文字列にのみ適用され、翻訳後はステータスが自動的に「Translated」へと変化します。機械翻訳を適用したくない文字列がある場合は、事前にステータスを「Translated」以降にしておくことで、機械翻訳の対象外とすることができます。

関連記事

• OpenAIとの連携によるLDX hubの可能性
• 数千ページを超えるPDFファイルを効率よく機械翻訳するコツ
• ソフトウェアローカリゼーション：成功のための4つのヒント