json i18n: lang: {string} vs. string: {lang}

Question

Мне нужно реализовать интернационализацию (немецкий, английский) с помощью webapp. я вижу, что наиболее распространенный подход к структуре переводов в разных файлах на языке:

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" 
    } 
} 

Каковы недостатки этого подхода? Почему каждый использует первый метод?

Answer 1

TL; DR: производительность.

Во-первых, логическая структура данных - это матрица, а не дерево. поэтому каждый подход эквивалентен по стойкости.

Во-вторых, i18n является почти структурой данных только для чтения во время выполнения. первый подход заставляет его быстро читать, потому что, когда языку задан только один язык, вам, вероятно, потребуется много ключей за один раз.

3-й, если вам нужно добавить/изменить ключи во время выполнения, это случайный случай, чем читать, и вы, вероятно, будете работать один за другим, каждый из них будет таким же.