Ruby on Rails I18n: разработчик — разрабатывает, клиент — заполняет. Об остальном позаботится сервис

в 13:28, , рубрики: i18n, ruby, ruby on rails, метки: , ,

Управление интернационализацией в Rails при помощи сторонних сервисов

Одним из самых моих любимых компонентов Rails является организация интернационализации и локализации при помощи класса I18n и файлов-словарей ( еn.yml, ru.yml и т.д. ). Но если брать не «сферический проект в вакууме», а реальное приложение с группой разработчиков и кучей веток в репозитории — то иногда голова пухнет разрешать конфликты при объединении разных веток/версий которые так или иначе возникают в файлах локалей. Как быть? Тут-то нам напомощь и приходят различные сторонние сервисы со своими гемами.

99Translations

Первым сервисом управления интернационализациями с которым я познакомился был 99Translations, который предоставлял возможность загружать особенный файл локали 'master.yml' на сервер ( файл должен был содержать только ключи ) и там парсился и добавлял ключи в остальные установленные локали. Далее на дашборд выводилась информация о новых ключах для которых требуется перевод. После полного ( или частичного ) заполнения словарей их можно было забрать с сервера и спокойно закоммитить в репозиторий.

Почему я говорю в прошедшем времени? Потому как этот сервис канет в лету 31 Марта 2012 года и нецелессобразно использовать его в реальных проектах. Здесь он приведен исключительно в качестве примера.

Плюсы:
— Простота и понятность использования с точки зрения программы, ничего лишнего.
— 1 файл-хранитель ключей: никаких конфликтов, твердая уверенность в наличии интернационализации на страницах приложения для всех локалей ( читай, никаких 'translation missing' сообщений ) при условии, что вы добавили его в master.yml.

Минусы:
— Нельзя одновременно вводить переводы через веб-интерфейс для нескольких локалей
— Тем не менее, перегруженный веб-интерфейс ( мне показался слегка излишним, с наличием кучи ненужных вкладок ).

LocaleApp

LocaleApp сразу привлек мое внимание своей «свежестью» ( пока находится на стадии беты ) и Rails-ориентированностью. Заглянув на дашбоард и проведя там немного времени, я понял, что интерфейс является интуитивно-понятным, а возможности заполнения сразу нескольких локалей одновременно делает жизнь переводчика/клиента намного проще (как следствие — улучшает самочуствие и настроение разработчика).

Дальше — интереснее: когда приложение запущенно в режиме разработки — гем, предоставляемый сервисом, автоматически запрашивает локали с сервера ( делает это он на каждом запросе, что в определенной степени замедляет приложение ) и отслеживает отсутствующие ключи в процессе рендеринга. Если таковые будут найдены — он позаботится о том, чтобы они были добавлены в словари. Удобно, не правда ли? Ну и зайдя на дашборд, можно увидеть, насколько заполненна каждая локаль и что следует добавить.

Плюсы:
— Возможность заполнения нескольких локалей одновременно.
— Автоматическое запрос последних интернационализаций при каждом запросе.
— Автоматическое добавление ненайденных ключей в файлы локализаций.
— Приятный глазу интерфейс.
— Отличный старт-ап: добавив новую локаль в проект через веб-интерфейс, Вы получаете все стандартные ключи ( названия месяцев, дней, форматы дат и времени и многое другое ) уже переведенными.
— Free-to-play бета: есть возможность попробовать и понять, а надо ли оно нам.

Минусы:
— Бэкграунд-процессы порядком раздражают разработчика и замедляют приложение (но, к счастью, они легко отключаются — см. документацию гема).
— Иногда неверно работают запросы отсутствующих переводов со scope'ми: I18n.t( 'key', :scope => :some_scope) и он автоматически добавляет их в неверное пространство имен ( 'key' будет добавлен как глобальный ключ ). Ну, бета есть бета. Надеемся, это починят.
— Из-за того, что можно загружать любой файл-словарь на сервер — иногда начинают «воскрешаться» давно удаленные ключи. Поэтому, лучше делать это через веб-интерфейс.

P.S. Главный плюс подобных сервисов — это то, что все ветки и все разработчики имеют одинаковые файлы локалей и при объединении веток/версий можно сконцентрироваться на сравнении программного кода, а не на особенностях перевода на тот или иной язык (хотя кому-то это может показаться минусом). Так же, немаловажным
является тот факт, что Вы держите переводчиков подальше от репозиториев и исходников, ну а они, в свою очередь, являются повелителями локалей.

Update: убрал сокращения.

Автор: abrukish

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js