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

最終更新日: 3月 23, 2020 1:39午後

ローカリゼーションと翻訳はほとんどの場合同じものだとみなされますが、実際はどちらが欠けてもうまくいきません。それぞれに共通する部分はありますが、ソフトウェア ローカリゼーション プロセスではより複雑なアプローチが必要になってきます。特定の地域や市場に向けて製品やコンテンツをアレンジするには、グラフィックやレイアウト、フォーマットなどあらゆるものを現地に適した形で調整する必要があります。対象市場の法的要件とデータ コンプライアンスに準拠し、現地で広く使われているデバイスやテクノロジーの傾向を考慮に入れることは言うまでもありません。

扱いが難しい文化的な要素をすべて考慮に入れようとすると、些細とも思える要素を簡単に見落としてしまいます。しかし、より多くのユーザーに受け入れてもらえる完璧な製品を届けるにはそうした些細な要素が重要な役割を果たします。では、最初は何から始めればよいのでしょうか? ここからは、ソフトウェア ローカリゼーションで重要となるベスト プラクティスと、注意すべき落とし穴について紹介していきます。

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

Do approach localization as a strategy.

最も重要なのは、全体的な目標におけるソフトウェア ローカリゼーションの役割を明確にすることです。細心の注意を払って要件分析とデザインを行うことで、ローカリゼーションで起こりがちな問題を回避できます。また、対象市場、言語、そしてこれらに特有の問題についてすべての関係者と合意を取り付けておくことが重要です。

グローバル規模で成功を収めるには、ソフトウェア ローカリゼーション プロセスをタスクではなく戦略として捉える必要があります。ビジネス チャンスを掴むためのグローバル展開に再エンジニアリングは必要はありません。

ローカリゼーションを行うことを前提にソフトウェアをデザインする。

Don’t forget to design with localization in mind.

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

  • 翻訳対象ファイルにおける原文バグの再現
  • 回避可能な翻訳エラー
  • 機能や表示、単語の省略、不必要な翻訳、本来翻訳が必要な個所の未翻訳など、ソフトウェア ローカリゼーションで起こりがちなエラー

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

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

Do build a library of internationalized objects.

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

  • ユーザー インターフェイス デザイン要素
  • 並べ替え機能と検索機能
  • マルチバイト文字のサポート (アジア言語向け)
  • 双方向言語と右から左に流れる言語のサポート (アラビア語とヘブライ語)
  • 住所、数値、日付、通貨のフォーマット

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

Don’t make source text too long.

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

  • 文章は短くまとめる
  • 可能な限り標準的な英語の語順に従う
  • 複数の名詞が連続するフレーズ (名詞文字列) を使わない
  • 類義語は使わず、一つのコンセプトは 1 つの用語で表現する
  • 頭字語は避ける (追加の翻訳が必要になり、派生的な意味を持たせることができなくなります)

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

訳文が原文より長くなることを考慮に入れる。

Do plan for text expansion.

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

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

適切なアイコンを使う。

Don’t misuse icons.

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

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

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

Do use UTF-8 encoding.

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

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

Don’t hardcode text or punctuation.

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

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

ローカリゼーションの専門家に相談する。

Do consult with a localization expert.

優れた LSP であれば、Android や iOS、Windows 開発用のローカリゼーション チェックリストを提供するだけでなく、その実績や専門知識に基づいたインサイトと洗練されたプロセスを通じて、時間やコストの削減、差し戻し作業の回避につなげることができます。ソフトウェアのローカリゼーションを開始する前に LSP とのコミュニケーションを介してあらゆる疑問を払拭することで、信頼のある協力関係を築くことができます。LSP に対する質問をまとめておきましょう。

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

期待に副うだけでなく、それ以上の成果を目指す。

Don’t just meet expectations—exceed them.

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

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

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