i18n / Интернационализация

[aeifn]

Представляется логичным перенести языковую составляющую в мастер ветку, тем самым избавиться от необходимости синхронизировать ветку en с мастером.

Зачатки такого подхода наблюдаются, например, здесь:

И здесь:

Как вариант, можно подставлять перевод на этапе сборки.

[mkgrgis]

Что если хранить такие вещи в статической ветке Монги с разметкой согласно ISO 639 ?
about_title_text: { ..., eng:"About", rus: "О проекте" ... }
Для начала хорошо бы вынести в JSON файл или файлы, где рядом вести ряды на доступных языках в одинаковом порядке по латинскому алфавиту языковых кодов.
Другой вариант - доверится средствам ОС и работать с gettext через пакет. Только преимуществ простоты редактирования в таком случае нет.

[paul-k-pastvu]

На самом деле, не нужно вообще так уж держаться за эти строки и пытаться что-то организовать у себя.
Гораздо лучше всё вынести в языковые .po файлы и поднять любую систему перевода (хоть вот MediaWiki с расширением перевода). Или подключиться к https://translatewiki.net или https://www.transifex.com/ - что во всех смыслах было бы эффективнее.

[mkgrgis]

лучше всё вынести в языковые .po файлы

Так это и есть gettext вариант в чистом виде, см. В таком случае пакета не избежать.

[aeifn]

лучше всё вынести в языковые .po файлы

Так это и есть gettext вариант в чистом виде, см. В таком случае пакета не избежать.

Gettext представляется отличным выбором, и внедрить его технически совсем не трудно. Но потребуется кропотливая работа по аккуратной замене сообщений на соответствующие функции и подготовке языковых файлов.
Предлагаю подключить пакет и попробовать перевести отдельную небольшую часть приложения для пробы.

[aeifn]

Лучше использовать этот пакет: https://www.npmjs.com/package/node-gettext
Он более популярен и поддерживается

[anvaruk]

... Но потребуется кропотливая работа по аккуратной замене сообщений на соответствующие функции и подготовке языковых файлов.

я могу заняться если инструкцию дадите

[mkgrgis]

@anvaruk сначала нужно попробовать просто добиться в изолированной node js работы пакета с переводом и перевести 1-2 сообщения через создание файлов .po на 2-3 языка. Если получтся, то @aeifn должен определить какие вызовы с формированеим надписей подлежат первоочередной замене на вызовы getText. А там только .po дополняй и наращивай.

[aeifn]

Доступность функции gettext в шаблонах можно обеспечить отсюда:

pastvu/app.js

Lines 92 to 98 in c47487f

	// Set an object which properties will be available from all pug-templates as global variables
	Object.assign(app.locals, {
	pretty: false, // Adds whitespace to the resulting html to make it easier for a human to read
	compileDebug: false, // Include the function source in the compiled template for better error messages
	debug: false, // If set to true, the tokens and function body is logged to stdoutl (in development).
	config,
	});

[kabalin]

Лучше использовать этот пакет: https://www.npmjs.com/package/node-gettext
Он более популярен и поддерживается

На что нужно обратить внимание:

• Как формировать JSON для использования на бэкэнде - компилировать отдельной задачей в grunt (и включать в сборку) или компилировать при каждом запуске приложения?
• Как передавать JSON c набором строк клиенту - через вебсервис подгружать для выбранной локали или компилировать отдельной задачей в grunt и включать в сборку в поддиректорию в public? Вероятно делать это при сборке оптимальный вариант (как считает @aeifn), для разработчика альтернативный способ компиляции будет ручной запуск команды grunt po2json.
• Со стороны клиента у помимо js, еще есть шаблоны:
  • В шаблонах есть статический текст (типа такого), его нужно как-то преобразовывать.
  • В шаблонах есть knockout, где текст является частью data-bind (типа такого), здесь нужен отдельный обработчик для knockout (этот для примера, и еще один для i18next, там можно подчерпнуть идеи как встроить gettext в knockout).

Чтобы с чего-то начать, шаги могут быть следующими:

1. Взять какой-то один шаблон.
2. Создать po файл со всеми строками из шаблона (в дириктории ./locales ?).
3. Прикрутить парсер к Gruntfile (см https://github.com/mikeedwards/po2json и https://www.npmjs.com/package/grunt-po2json)
4. Сгенерировать json с текстом из po файла.
5. В шаблоне получить текст из json используя node-gettext и i18n / Интернационализация #257 (comment)

[yuriy-zhilovets2]

Стандартный механизм использования gettext такой:

1. Все строки в коде заменяются вызовом функции _
   _("Это строка")

2. Отдельный парсер, запускаемый при изменения в коде, находит эти строки и переносит в каталог строк (отдельный файл)

3. В специальном редакторе найденные строки переводятся на поддерживаемые языки и сохраняются в файле .po

4. Редактор компилирует этот файл в формат .mo, файл подкладывается в дерево

5. Функция _ во время работы читает строки из файла .mo

Тонкости:

1. Строки могут быть не только в коде .js, но и в других местах. Соответственно, нужен отдельный парсер и механизм вызова
2. Файлы .mo получаются довольно большого размера, поэтому имеет смысл разделить строки в серверном и в клиентском коде, и в браузер грузить только один файл для клиентских строк

Я могу взяться за перевод строк, но нужно определиться:

1. Какой пакет будет использоваться
2. Где еще могут находиться строки (например, в сообщениях об ошибках)

Последовательность действий:

1. Начать со строк в коде, отметить их через _
2. Собрать каталог, проверить, что строки транслируются правильно
3. Добавить английский перевод и код переключения на него
4. Разобраться с остальными строками

[aeifn]

• Строки могут быть не только в коде .js, но и в других местах. Соответственно, нужен отдельный парсер и механизм вызова

По идее, все строки должны быть в js-коде.

• Файлы .mo получаются довольно большого размера, поэтому имеет смысл разделить строки в серверном и в клиентском коде, и в браузер грузить только один файл для клиентских строк

Возможно, лучше просто собирать несколько версий фронта на разных языках (строки будут подставляться на этапе сборки).

[kabalin]

Возможно, лучше просто собирать несколько версий фронта на разных языках (строки будут подставляться на этапе сборки).

Конечно, на самом деле по-другому и не получится, шаблон компилируется на этапе сборки, языковые переменные в шаблоне будут преобразованы в текст.

[aeifn]

Предлагаю использовать этот фреймворк: https://github.com/i18next/i18next

[kabalin]

Предлагаю использовать этот фреймворк: https://github.com/i18next/i18next

Идея хорошая, но как я понимаю он заточен под runtime, у нас строки еще и на стороне сервера есть и в клиенте в нескольких вариантах (js, шаблоны). Шаблон компилируется при сборке, там динамически строки менять не получится (если только их не будет подставлять JS библиотека при показе), в общем есть вопросы. Мне кажется встраивание языка на этапе компиляции и отдельные инстансы приложения для разных языков - более понятный вариант.

Отдельно скажу, что я так же не уверен насчет po/mo файлов и gettext. Хороший пример реализации перевода в Docusaurus, там в качестве фреймворка используется formatjs, в качестве формата файлов перевода Chrome.i18n который имеет дополнительное поле description (помогает переводчику) и интеграцию с сервисом Crowdin обеспечивающим интерфейс для переводчика (бесплатно для open source проектов). Мне кажется нужно что-то похожее делать с удобным форматированием и на основе стандартов (у i18next как я понял свой стандарт форматирования для множественного числа, даты, вставки переменных и т.д., а formatjs использует ICU Message syntax поддерживаемый и другими фрейвоками, i18n-node в частности).

В общем вопрос требует изучения.

[klimashkin]

Согласен, использую formatjs c ICU/CLDR c 2014 года на других проектах.
Это Unocode стандарт для формата строк