Как разделить пользовательский интерфейс и локализацию контента в ActiveAdmin - PullRequest
0 голосов
/ 07 сентября 2018

Мы должны начать поставлять динамический контент на нескольких языках с нашими различными приложениями.

Существует два типа локализации, которые следует учитывать: локализация пользовательского интерфейса и локализация контента. Локализация пользовательского интерфейса - это язык, на котором поставляется интерфейс (статический текст), а локализация контента - это язык, на котором контент просматривается / редактируется (модель Rails)

У нас в основном 3 типа приложений

  1. Мобильные приложения - доступ к конечным точкам API для операций CRUD
  2. Клиентское веб-приложение - построено с использованием backbone.js, а также с использованием конечных точек API для операций CRUD через базовые модели / коллекции
  3. Веб-приложение администратора - построено с использованием activeadmin (https://github.com/activeadmin/activeadmin)

Следует отметить, что мы используем Rails 3.2, ActiveAdmin 0.6.6 (обновление необходимо, но не приоритетно:))

Чтобы локализовать контент, мы ищем гем глобализации (https://github.com/globalize/globalize)

Кажется, нет никаких проблем с использованием globalize при взаимодействии с конечными точками API. Мы можем использовать заголовок Accept-Language и установить свойство I18n.locale в before_filter, и все, кажется, работает нормально. Это означает, что мобильные приложения и клиентские веб-приложения должны быть защищены.

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

Камень globalize использует свойство I18n.locale, чтобы определить, какую локаль обновлять / читать для переводов контента. Поскольку ActiveAdmin не использует AJAX, установка I18n.locale также повлияет на статический текст пользовательского интерфейса.

На данный момент это не так уж важно, поскольку у нас есть только одна локаль для пользовательского интерфейса (config / locales содержат только файлы en yml). Это означает, что мы можем использовать метод, описанный в https://github.com/activeadmin/activeadmin/wiki/Specifying-locale, и установить свойство I18n.locale для обновления правильного динамического содержимого с помощью globalize, в то время как интерфейс пользовательского интерфейса будет по-прежнему доставляться на английском языке

Однако, думая о будущем, где мы потенциально можем добавить дополнительные языки для пользовательского интерфейса, я ищу идеи о том, как сохранить языковой стандарт пользовательского интерфейса и языковой стандарт содержимого отдельно. Другие языки, такие как Java и C #, делают это с другими свойствами в своей эквивалентной библиотеке I18n, но Rails, похоже, не принимает это

Мысли

Заранее спасибо

1 Ответ

0 голосов
/ 16 сентября 2018

после дальнейших исследований я использовал activeadmin-globalize gem. Изначально я не думал, что он совместим с гемом globalize, основываясь на документации, но это

...