2016-08-12 4 views
0

webappで国際化(ドイツ語、英語)を実装する必要があります。 私は、最も一般的なアプローチは、言語ごとに異なるファイルで翻訳を構築することであることを参照してください。json i18n:lang:{string}と文字列:{lang}

de.json fr.json

とちょうどプログラム的にデータストアを切り替えます。

これは、このようなデータ構造に相当します。

i18n: 
{ 
    de: { 
     hello: "Hallo", 
     save: "Speichern, 
     ... 
    }, 
    en: { 
     hello: "hello", 
     save: "save", 
     ... 
    } 
} 

このアプローチは、簡単に別の翻訳者に翻訳ファイルを配ることを可能にすると、単にアプリに新しい翻訳ファイルを追加します。 しかし、私はキーを同期させておく必要があることを嫌っています。私。新しいキーワード(「削除」など)を追加しても、その瞬間にすべての翻訳が行われていない場合は、すべてのjsonファイルを更新する必要があるため、後で翻訳を行うのを忘れてしまいます。

従って私は次のような構造は、この問題を回避するかもしれないと思った:

i18n:{ 
    hello: { 
     de: "Hallo", 
     en: "hello" 
    }, 
    save: { 
     de: "Speichern", 
     en: "Save" 
    } 
} 

このアプローチの欠点は何ですか?誰もが最初の方法を使うのはなぜですか?

+0

私が最初に仮定するのは、(単語の数)オブジェクトではなく、現在のロケールに基づいて1つのオブジェクトだけを走査するということです。 ほとんどの場合、別々の言語は実際には異なるJSONファイルに格納され、ペイロードを小さくします。ロケールを知っているときは、問題の言語だけを1つのjsonですべて呼び出す必要はありません。 – user3821538

答えて

0

TL; DR:パフォーマンス。

第1に、論理データ構造はツリーではなくマトリックスです。各アプローチは永続性において同等です。

第2に、i18nはほとんど実行時に読み取り専用のデータ構造です。最初のアプローチでは、ロケールに1つの言語だけが必要なときに読み込みが速くなります。一度にたくさんのキーが必要になるためです。

第3に、実行時にキーを追加/変更する必要がある場合、これは読書よりも簡単なケースであり、おそらく1つずつ操作します。それぞれのアプローチは同じです。