ローカリゼーション対応システムを設計する方法

グローバリゼーションのこの時代において、ソフトウェア開発者を含む企業は常に新しい市場への拡大に関心を持っています。これは多くの場合、製品をさまざまな領域にローカライズすることを意味します。この記事では、ローカリゼーション用、特に複数の言語でコンテンツを管理するためのデータモデルを設計するためのいくつかのアプローチについて説明します。

ローカリゼーションとは

ローカリゼーションは、製品をさまざまな市場に適応させるプロセスです。これは、製品販売の面で最大の市場シェアを達成するための重要な要素です。ローカリゼーションが正しく行われると、ユーザーは製品が自分の言語、文化、ニーズに合わせて作成されたと感じるでしょう。

英語が一般的な第一言語ではない場所では、調査により、ソフトウェア製品には現地の言語が非常に好まれることが証明されています。このMediaPostの記事には、海外での販売に関して、英語以外の言語の必要性に関する興味深い数字がいくつか含まれています。

ローカライズしないと何を失う可能性がありますか？

非ローカリゼーションの不幸な例を考えてみましょう。顧客の便宜のために、eコマースポータルでは、顧客は個々の購入を4つのグループにまとめることができました。残念ながら、日本語の「4」という単語の発音は、「死」を意味する単語のように聞こえます。日本人は通常、この番号に関連するすべてのものを避けます。これは、この番号が不運であると考えられているためです。言うまでもなく、これらの製品の販売は日本市場ではうまくいきませんでした。

したがって、上記の質問に答えて、ターゲット市場を慎重に計画しないと、多くを失う可能性があります。

ローカリゼーションとしてのコンテンツ翻訳

ローカリゼーションについて考えるとき、コンテンツの翻訳が最初に頭に浮かぶことがよくあります。 2番目の考えは、「翻訳されたコンテンツを複数の言語で保存するには、堅牢で効率的なデータベースモデルが必要です」です。

多言語のeコマースアプリケーションのデータモデルを設計するように依頼されたとします。 product_nameのようなテキストフィールドを保存する必要がありますさまざまな言語での製品の説明。 customer これらすべての言語の表。

コンテンツの翻訳を念頭に置いてデータモデルを設計する方法を理解するために、これら2つの表を使用してさまざまなアプローチを検討します。これらのアプローチにはそれぞれ長所と短所があります。以下に示すアプローチは、データモデル内の他のテーブルに拡張できます。もちろん、選択する正確なアプローチは、独自の要件に基づきます。

アプローチ1–対象フィールドごとに個別の言語列を追加する

これは、開発の観点から最も単純なアプローチです。フィールドごとに1つの言語列を追加することで実装できます。

長所

実装は非常に簡単です。
基になるデータを任意の言語でフェッチするSQLの記述に複雑さはありません。フランス語で特定の注文の製品と顧客の詳細を取得するクエリを作成するとします。コードは次のようになります：
```
Select p.product_name_FR, p.description_FR, p.price, 
       c.name_FR, c.address_FR, c.contact_name 
from order_line o, product p, customer c
	Where o.product_id = p.id and o.customer_id = c.id
	And id = ;
```

短所

スケーラビリティはありません。新しい言語が追加されるたびに、テーブル全体に数十の列を追加する必要があります。
特に多くのフィールドで複数の言語が必要な場合は、時間がかかる可能性があります。
開発者は、既存のすべての言語を管理するために、以下に示すクエリを作成することになります。したがって、新しい言語が導入されたときに、アプリケーション内のすべてのSQLを変更する必要があります。（注： @in_language アプリケーションの現在の言語を示します。このパラメータはアプリのフロントエンドから取得され、バックエンドはレコードを取得しています。）
```
SELECT CASE @in_language 
              WHEN ‘FR’ THEN p.product_name_FR
              WHEN ‘DE’ THEN p.product_name_DE
              DEFAULT THEN p.product_name_EN,
           p.price,
          CASE @in_language 
              WHEN ‘FR’ THEN c.name_FR
              WHEN ‘DE’ THEN c.name_DE
              DEFAULT THEN c.name_EN,
          c.contact_name
FROM order_line o, product p, customer c
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND id = ;
```

アプローチ2–翻訳されたテキスト用に別のテーブルを作成する

このアプローチでは、翻訳されたテキストを保存するために別のテーブルが使用されます。以下の例では、このテーブルをtranslation 。言語ごとに1つの列が含まれています。フィールド値から該当するすべての言語に変換された値は、レコードとして保存されます。実際の翻訳されたテキストを基になるテーブルに保存する代わりに、translation テーブル。この実装により、既存のデータモデルにあまり多くの変更を加えることなく、翻訳されたテキストの共通リポジトリを作成できます。

長所

ローカリゼーションを既存のデータモデルに実装する場合は、良いアプローチです。
translation 新しい言語が導入されたときに必要な変更は、テーブルだけです。
元のテキストがテーブル間で同じである場合、冗長な翻訳テキストはありません。例：顧客名と製品名が同じであるとします。この場合、1つのレコードのみが変換テーブルに挿入され、同じレコードが両方のcustomer およびproduct テーブル。

短所

それでもデータモデルを変更する必要があります。
テーブルに不要なNULLが含まれている可能性があります。サポートされている1つの言語にのみ1,000のフィールドが必要な場合、1,000のレコードが作成され、多くのNULLが作成されます。

結合の数が増えると、SQLの記述の複雑さが増します。そして、translation テーブルの場合、取得時間が遅くなります。

言語管理の問題ステートメントのSQLをもう一度書きましょう：

SELECT CASE @in_language 
              WHEN ‘FR’ THEN tp.text_FR
              WHEN ‘DE’ THEN tp.text_DE
              DEFAULT THEN p.product_name_EN,
           p.price,
          CASE @in_language 
              WHEN ‘FR’ THEN tc.text_FR
              WHEN ‘DE’ THEN tc.text_DE
              DEFAULT THEN c.name_EN,
          c.contact_name
FROM order_line o, product p, customer c, translation tp, translation tc
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND p.name_translation_id = tp.id
	AND c.name_translation_id = tc.id
	AND id = ;

変換テーブルアプローチのバリエーション

翻訳されたテキストを取得するときのパフォーマンスを向上させるために、translation テーブルを複数のテーブルに。ドメインに基づいてレコードをグループ化できます。つまり、customer 、product 、など。

アプローチ3–各言語の行を含む翻訳テーブル

この実装は2番目のアプローチと非常に似ていますが、翻訳されたテキストの値を列ではなく行に格納します。ここでは、translation テーブルIDは、翻訳された言語のフィールド値に対して同じままです。複合主キー{id 、language_id }は変換テーブルに格納され、同じtranslation_idを格納します複数のlanguage_idに対する各フィールド。

長所

この実装により、開発者はデータ取得SQLを非常に簡単に作成できます。
このモデルのOEMを作成するのも簡単です。
新しい言語を追加するときに、データモデルを変更する必要はありません。新しい言語のレコードを挿入するだけです。
一連のフィールドが言語に適用できない場合、不要なメモリ消費はありません。

データ取得SQLの複雑さが軽減されます。以下の例を見てください：

SELECT tp.text,
        p.price,
       tc.text,
        c.contact_name
FROM order_line o, product p, customer c, translation tp, 
     translation tc, language l
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND p.name_translation_id = tp.id
	AND c.name_translation_id = tc.id
             AND tp.language_id = l.id
             AND tc.language_id = l.id
             AND l.name = @in_language
	AND id = ;

短所

翻訳されたデータを取得するには、比較的多数の結合が必要です。
やがて、膨大な数のレコードがtranslation テーブル。翻訳テーブルは1つしかないため、翻訳されたすべてのテキストがそのテーブルにダンプされます。翻訳するフィールドが数百万あり、アプリケーションが多数の言語をサポートしている場合、1つのテーブルに翻訳を問い合わせるのは時間のかかる作業になります。ただし、2番目のアプローチの結論で指摘したように、言語または主題分野に基づいて翻訳テーブルを分割することができます。

アプローチ2と3を組み合わせるとどうなりますか？

具体的には、アプローチ2のバリエーションであるtranslation テーブル–テーブル内の行を使用するという考えで。 translation アプローチ2バリアントで行ったように、ドメインに基づいて複数のテーブルを作成することによってテーブルを作成します。ドメインベースの変換テーブルにかなりの数のレコードがある場合は、個々のフィールドに基づいてテーブルをさらに分割できます。

アプローチ＃4 –翻訳されたフィールドと翻訳されていないフィールドのエンティティレイヤーの作成

このソリューションでは、1つ以上の翻訳済みフィールドを含むエンティティテーブルが2つのレイヤーに分割されます。1つは翻訳済みフィールド用で、もう1つは非翻訳済みフィールド用です。このようにして、それぞれに個別のレイヤーを作成します。

長所

変換されていないフィールドのみが関係している場合は、変換テーブルを結合する必要はありません。したがって、変換されていないフィールドのパフォーマンスが向上します。
翻訳されたテキストを取得するために必要な結合の数は比較的少なくなります。
OEMを作成するのは簡単です。
翻訳されたテキストを取得するためのSQLは単純です。
これは、エンティティ間で複数の言語を組み込むための実証済みのアプローチです。

ポイントを示すために、翻訳されたテキストを取得するサンプルクエリを次に示します。

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = ;

ローカリゼーション–コンテンツ翻訳を超えて

ローカリゼーションとは、アプリケーションのコンテンツを別の言語に翻訳することだけではありません。注意が必要な文化的および機能的パラメータもあります。たとえば、日付の値は、北米では「MM / DD / YYYY」としてフォーマットされていますが、アジアのほとんどでは「DD / MM/YYYY」と記述されています。

別の例は、アプリケーションヘッダーに名前を表示することと関係があります。米国では、誰かを名で呼ぶことは容認できるか、あるいは好まれます。この文化では、顧客がログインするとすぐに顧客の名がヘッダーに表示されます。ただし、日本では逆になります。名で誰かを呼び出すことは失礼であるか、むしろ侮辱的です。ローカリゼーションはこれを考慮に入れ、アプリケーションの日本人オーディエンスにファーストネームを使用しないようにします。

ローカリゼーションパラメータは、アプリケーションのバックエンドに保存する必要がある場合があります。これは、ローカリゼーションに関するプログラムロジックを設計する必要がある場合に非常に当てはまります。おそらく、そのようなすべてのパラメーターを文化的および機能的なカテゴリーに分類し、それらを中心にデータモデルを構築することができます。

ローカリゼーションについてもう1つ考えます

グローバルブランドがローカル市場に浸透する場合、ローカリゼーションが必要です。アプリケーションをローカライズするには、全体像を見てください。ローカリゼーションは、技術的に完璧なパフォーマンス以上のものです。それはまた、地元の文化、行動、さらには考え方や生き方を習得することを意味します。

アプリケーションをローカルに適応させるために他に何ができるでしょうか？コメントであなたの考えを教えてください。