ruby-on-railsinternationalizationactiveadminglobalize3

How to keep UI and Content Localisation separate in ActiveAdmin


We need to start delivering dynamic content in multiple languages with our different apps.

There are two types of localisation that should be considered: UI localisation and Content localisation. UI localisation is the language the interface is delivered in (static text) while Content localisation is the language content is viewed/edited (Rails model)

We basically have 3 type of apps

  1. Mobile apps - hits an API endpoints for CRUD operations
  2. Client Web app - built with backbone.js so also using API endpoints for CRUD operations via backbone models/collections
  3. Admin web app - built using activeadmin (https://github.com/activeadmin/activeadmin)

I should note we are using Rails 3.2, ActiveAdmin 0.6.6 (upgrading needed but not priority :))

To localise the content, we are looking the globalize gem (https://github.com/globalize/globalize)

There doesn't seem to be any issues using globalize when interfacing with the API endpoints. We can use the Accept-Language header and set the I18n.locale property in a before_filter and everything seems to work fine. This means the Mobile apps and Client Web app should be covered.

For ActiveAdmin, this becomes a bit more difficult. For the ActiveAdmin app, we would like to deliver the UI static text in the user's preferred language while allowing them to switch between languages for the content.

The globalize gem leverages the I18n.locale property to determine which locale to update/read for the content translations. Since ActiveAdmin is not using AJAX, setting I18n.locale will also affect the UI static text.

At the moment, this is not a big deal as we only have one locale for the UI (config/locales only contain en yml files). This means we can use the method described at https://github.com/activeadmin/activeadmin/wiki/Specifying-locale and set the I18n.locale property to update the correct dynamic content, via globalize, while the UI interface will continue to be delivered in English

However, thinking to the future, where we potentially add additional languages for the UI, I'm looking for ideas of how to keep the UI locale and the content locale separate. Other languages, such as Java and C#, do this with different properties on their I18n equivalent library but Rails doesn't seem to embrace this

Thoughts?

Thanks in advance


Solution

  • after further investigation, I ended up using activeadmin-globalize gem. Initially, I didn't think it was compatible with the globalize gem based on the documentation but it is