ソフトウェア ローカリゼーション プロセスにおける推奨事項と注意事項トップ 10

グローバル オーディエンスへの対応という点で、ローカリゼーションと翻訳は同じものだとみなされがちですが、実際はどちらのプロセスが欠けてもうまくいきません。それぞれに共通する部分もありますが、ソフトウェア ローカリゼーション プロセスではより複雑なアプローチが必要になってきます。その複雑さを理解することが、新規市場の開拓での成功につながります。

ソフトウェア ローカリゼーションとは

ソフトウェア ローカリゼーションは、特定の国や地域の文化、言語、法的要件に合わせてさまざまな要素を変更するプロセスです。つまり、テキストベースの要素を翻訳するだけでなく、グラフィック、レイアウト、フォーマットなども適宜調整します。現地の法的要件とデータ コンプライアンスに準拠し、現地で広く使われているデバイスやテクノロジーの傾向を考慮することは言うまでもありません。

扱いが難しい要素をすべて考慮しようとすると、些細に思える要素を簡単に見落としてしまいます。しかし、そうした些細な要素が、より多くのユーザーに受け入れてもらえる完璧な製品を届ける上で重要な役割を果たしています。では、最初は何から始めればよいのでしょうか。

ここからは、ソフトウェア ローカリゼーションで重要となるベスト プラクティスと注意すべき落とし穴のトップ 10 についてご紹介していきます。

1. ローカリゼーションを戦略として捉える

最も重要なのは、全体的な目標におけるソフトウェア ローカリゼーションの役割を明確にすることです。ソフトウェア ローカリゼーションのあらゆる段階をタスクではなく、戦略として捉える必要があります。

• 事前作業 -- 計画と準備


• 調査 -- 目的と要件


• コンテンツの確認、分析と転送


• 提案


• プロジェクト開始


• 翻訳とローカリゼーション


• レビューと品質管理


• ファイルの納品、本番稼働とフォローアップ

細心の注意を払って要件分析と設計を行うことで、ローカリゼーションで起こりがちな問題を回避できます。また、対象市場、言語、そしてこれらに特有の問題について、すべての関係者と合意を取り付けておくことが重要です。ビジネス チャンスを掴むためのグローバル展開をしっかりと計画しておけば、再エンジニアリングの必要はありません。

2. ローカリゼーションを行うことを前提にソフトウェアを設計する

ローカライズしやすい設計にすることで、スケジュールの遅れやコスト超過を回避することができます。ソース コードとソフトウェアの構造に注意することで次の問題を回避できます。

• 翻訳対象ファイルにおける原文バグの再現


• 回避可能な翻訳エラー


• 機能や表示、単語の省略、不必要な翻訳、本来翻訳が必要な個所の未翻訳など、ソフトウェア ローカリゼーションで起こりがちなエラー

アドバイス: テンプレートを使ってブランドのイメージに一貫性を持たせましょう。ローカリゼーションを開始できる状態であることを確認するには、何度もテストを繰り返しましょう。ダミー ローカリゼーション (QA テストの一種) は、リスクを軽減する上で非常に有用なプロセスです。このプロセスでは、特殊文字や文字列の長さに起因するユーザー インターフェイス (UI) のレイアウトの問題など、起こり得る翻訳上の問題を明らかにすることができます。

3. インターナショナライズ済みオブジェクトのライブラリを構築する

ローカリゼーションのスムーズな進行を可能にするのがインターナショナリゼーションです。インターナショナライズされたオブジェクトのライブラリを構築することで、複数言語にソフトウェア アプリケーションをローカライズする手法を確立し、差し戻し作業を回避します。このライブラリには次が含まれます。

• ユーザー インターフェイス デザイン要素


• 並べ替え機能と検索機能


• マルチバイト文字のサポート (アジア言語向け)


• 双方向言語と右から左に流れる言語のサポート (アラビア語とヘブライ語)


• 住所、数値、日付、通貨のフォーマット

4. 原文テキストはできるだけコンパクトにまとめる

文章構造や単数と複数のルール、ある事柄を表すのに必要な単語数は言語ごとに異なります。翻訳の問題を最小限に抑え、明確で簡潔な原文コンテンツにするための条件は次のとおりです。

• 文章は簡潔にする


• 可能な限り、元の言語 (例: 英語) の標準的な語順を使用する


• 複数の名詞が連続するフレーズ (名詞文字列) は分割する


• 類義語を避け、一つのコンセプトを 1 つの用語で表現する


• コンテンツにユーモアを入れない


• 日付、時刻、単位系を明確にする


• 文中の語句の関係性を明確にするために、適切な関係代名詞を含める (英語の場合は「that」や「which」など)


• 能動態を使う


• 句動詞は一語の動詞に置き換える


• 頭字語を使わない (追加の翻訳が必要になり、派生的な意味を持たせることができなくなります)


• 慣用句はすべて削除する

アドバイス: 頭字語を避けるだけでなく、名詞を動詞化して使わないようにします。つまり、同じテキストを別の話の流れで再利用しないようにするということです。たとえば、英語には一つの単語で名詞にも動詞にもなるものが数多くあります。「file」、「share」、「design」などです。あるテキストを名詞で使うか動詞で使うかを決めたら、最後までそのルールに従いましょう。

5. 訳文が原文より長くなる可能性を考慮する

英語: BUY NOW
フランス語: ACHETER MAINTENANT
ドイツ語: JETZT KAUFEN
イタリア語: ACQUISTA ORA
スペイン語: COMPRAR AHORA

英語には 100 万個以上の単語があるとされているのに対して、他の大半の言語の単語数は 50 万にも届きません。つまり、英語から他の言語に翻訳する場合、訳文が元の英語より長くなったり短くなったりすることがあります。たとえば、「Have a nice day!」をドイツ語に翻訳すると「Ich wünsche Ihnen einen schönen Tag!」となり、長さが 125％ 増加します。英語からアジア言語に翻訳する場合は、逆に元の英語より訳文が短くなる傾向にあります。

全般的には、訳文は原文よりも少なくとも 30 ～ 35% 長くなると想定して、そのためのスペースを確保しておきましょう。繰り返しになりますが、原文テキストはなるべく短くして、フォーマットと単語・語句の選択に関する他のベスト プラクティスも考慮してください。

6. 適切なアイコンを使う

ソフトウェア ローカリゼーションのベスト プラクティスで取り上げるのは、当然ながら単語・語句の選択や文章の構成だけではありません。文化が違えば、視覚的な要素の受け取られ方も変わってきます。文字がないアイコンには、翻訳の負荷を低くしてコストを抑えられるというメリットがありますが、アイコンや記号、シンボルの中には、国や地域によって受け取られ方が違うものがあることに注意しましょう。

たとえば、米国で使用されているスタイルの郵便受けは、他の文化圏で必ずしも通用するわけではありません。手や足、動物、その他のシンボルの画像が予想外の意味で受け取られたり、不快感を与えたりしていないかを調査し、結果によっては使用を避けてください。

7. UTF-8 のエンコードを使う

最新テクノロジーの大半では、UTF-8 という Unicode で最も広く使われているフォーマットがデフォルトになっています。UTF-8 は、情報処理の専門家として有名なケン ランディ博士によって考案された「世界初のインテリジェントな文字エンコーディング」です。大半の大手ハードウェア企業とソフトウェア アプリケーション企業が Unicode をサポートしており、XML や Java、Javascript などの標準的な言語で必須となっています。UTF-8 を使うことで、あらゆる言語、特にアジアの主要言語 (中国語、日本語、韓国語、ベトナム語) への展開が容易になるとともに、翻訳の精度も上がります。

8. テキストや句読点をハードコード化しない

ローカリゼーションの準備が整ったら、ハードコード テキスト (ソース コードに埋め込まれたテキスト) を翻訳用に抽出する必要があります。言語サービス プロバイダー (LSP) は構文解析を実行して翻訳対象のテキストを特定することができますが、設計段階でハードコード テキストが最小限になるようにしておきましょう。タイトルや製品名、エラー メッセージなどについてはハードコードの代わりに専用のリソース ファイルを用意し、リソースのコメント機能も活用して、翻訳エラーをできるだけ回避するようにしましょう。

アドバイス: 文字列のサイズを減らすために、ハードコード化した単語やフレーズの順序を含むプレースホルダーを連結させて文字列を構成したいと思うかもしれませんが、言語によっては語順や文法が異なるため、この方法では誤訳や内容にそぐわない不適切な翻訳が多発する原因となります。この問題を回避するには、何よりもこの方法を使わないことです。

9. ローカリゼーション サービスの専門家に相談する

プロジェクト開始前に、ソフトウェアのローカリゼーション サービス パートナーにできるだけ多くの情報を提供して、信頼のある協力関係を築きましょう。

• 近い将来、海外展開する計画がありますか。


• 主要な顧客はどのような層ですか。


• プロジェクトで必要な言語の数はいくつですか。


• 社内にローカリゼーション チームがありますか。そのチームはこのプロジェクトの窓口になりますか。


• 翻訳プロバイダーに何を求めますか。 スピード、品質、コスト、専門家へのアクセスですか。

優れた LSP であれば、Android や iOS、Windows 開発用のローカリゼーション チェックリストを提供するだけでなく、その実績や専門知識に基づいたインサイトと洗練されたプロセスを通じて、時間やコストの削減、差し戻し作業の回避につなげることができます。

アドバイス: LSP に翻訳禁止 (DNT: Do Not Translate) リストを提供して、不必要な翻訳や必要な個所の未翻訳が発生しないようにしましょう。いずれのケースでも、プログラムの重要な機能に関連する文字列が正しく翻訳されていない場合は、コードの機能に影響を及ぼす可能性があります。

10. 期待に応えるだけでなく、それ以上の成果を目指す

最後になりますが、些細な点にも注意を払ってください。非常にシンプルなモバイル アプリから、複雑なマルチユーザー システムまで、多言語ソフトウェアの売り上げと普及のカギとなるのはローカリゼーションです。

「グローカリゼーション」または現地/世界中の顧客層の行動にパレートの法則 (80:20 の法則) を適用して、自社の取り組みを評価しましょう。現地市場を完全に理解し、文化固有のデリケートな部分を設計と開発に組み込むことで、ユーザーの期待に応えるだけでなく、ユーザー エクスペリエンスを大幅に高めることが可能になります。グローバル展開を最初から意識してソフトウェア開発を行うことで、グローバル市場における大きなビジネス チャンスの扉を開くことができます。

ソフトウェア ローカリゼーションの詳細については、ライオンブリッジの営業担当者までお問い合わせください。