json i18n：lang：{string}與string：{lang}

我必須用webapp實現國際化（德語，英語）。我看到的最常見的方法是構建每種語言在不同的文件翻譯：json i18n：lang：{string}與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" 
    } 
}

什麼是這種方法的弊端？爲什麼每個人都使用第一種方法？

來源

2016-08-12 Chris

我的第一個假設是，你只會遍歷1個對象，基於當前的語言環境，而不是（字數）對象。在大多數情況下，單獨的語言實際上存儲在不同的JSON文件中以減少有效負載。當你知道語言環境時，不需要在一個JSON中引入每種語言，只需要引入一個語言。 – user3821538

TL; DR：表現。

首先，邏輯數據結構是矩陣，而不是樹。所以每種方法在持續性上都是相同的。其次，i18n在運行時幾乎是只讀數據結構。第一種方法使得它的讀取速度很快，因爲當給定語言環境時只需要一個lang，並且您可能一次需要很多密鑰。第三，如果你需要在運行時添加/修改鍵，它是一個相關的偶然情況，而不是閱讀，你可能會一個一個地操作，每種方法都是一樣的。

來源

2017-07-17 05:26:23 marstone

json i18n：lang：{string}與string：{lang}

回答

相關問題