Организация Javascript i18n файлов для модульного приложения

Question

Я добавляю поддержку i18n в относительно новое приложение. Это модульное приложение. На данный момент у нас будет только английский (и, возможно, Pig Latin для тестирования), но я хочу убедиться, что мы не будем стрелять в ногу. У меня есть две идеи организации файлов перевода:

1. Один большой список переводов с каждой строкой, используемой в любом модуле. Это вызовет некоторое противоречие для глобального файла. Этот файл будет больше, и я задаюсь вопросом о времени загрузки.

2. Каждый модуль имеет свои собственные файлы переводов. Это приведет к некоторому дублированию для строк, которые происходят в нескольких модулях. И нам придется консолидировать файлы, если мы когда-нибудь отправим их для перевода.

Мы используем Javascript, плюс Backbone.js, Require.js, Aura и т.д., и мы планируем использовать i18next.

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

Answer 1

Имея файл в модуле, вы будете повторять себя. Вам придется перевести «Ошибка произошла» десять раз, если эта строка используется в десяти модулях. Мое предложение объединить все переводы в один большой файл JSON, что структурированная, как это:

{ 
    "common": { 
    "welcome": "welcome", 
    ... 
    }, 
    "module1": { 
    "loaded": "module1 is loaded" 
    .... 
    } 
} 

Вы будете иметь модуль конкретные переводы, завернутые в нем собственного объекта и общих строк в объекте.

Боковое примечание: вы можете узнать у Джона Ресига из своего blog post о i18n в JavaScript.

Answer 2

Пошел через этот вопрос & думал, что дам альтернативный взгляд на это.

фон

Создание одного массивного файла перевода в порядке, кроме случаев, когда вы:

1. Разработка сайта уровня предприятия/системы, а также;
2. Работа в большой команде.

Я работаю над угловым приложением более года, требуя большой команды разработчиков, и представляет собой довольно крупную систему.

Когда система становится массовым и у вас есть большая команда с вами, один файл языка не лучший вариант, потому что:

1. В зависимости от сроков ваших разработчиков Skillset &, добавление новых строк в уже большой языковой файл порождает лень, а мышление «О, я просто поставлю его в этом разделе здесь и рефакторинг позже». Это приводит к ненужным дублированиям, если одно и то же мышление используется для поиска элемента, который уже существует.
2. В большом файле и большой заметке команды, если два человека работают над одним файлом и возникают конфликты, разрешение конфликтов может привести к ошибкам и времени отпусков.
3. Меньшие файлы могут быть ленивыми, если ваш фреймворк/tech поддерживает его. Зачем загружать языковые файлы для подсистем, которые вы не можете использовать?

Резюме & Рекомендации

Мои рекомендации, основанные на моем опыте следующим образом:

Делайте то, что лучше всего подходит для вашего проекта, это временные рамки, и это потребности. Чтобы сэкономить время в долгосрочной перспективе, если вы работаете в большой системе, начните с отдельных файлов. Получите стандарт с самого начала и придерживайтесь его, чтобы сэкономить время.