CODEWITHSUNDEEP
ruby-on-railsruby-on-rails-4versioningrails-i18n
Godwin
Godwin

Reputation: 9937

Versioning for Rails i18n translations

I'm in the process of building a volunteer based translation engine for a new site built in Rails 4.0. Since it's volunteer based, there is always the possibility that a user may enter a translation that others do not agree with, accidentally remove a translation, etc. In such an event, I would like to give users the option to revert to a previous translation.

I did some searching around but have yet to find a solution aside from writing my own I18n backend. Is there a simpler way of storing previous versions of translations?

I'm currently using Sven Fuchs' Active Record as a backend, however I'm seriously thinking about switching due to possible performance issues later on down the road.

Upvotes: 0

Views: 739

Answers (2)

Godwin
Godwin

Reputation: 9937

I used Nimir's help to find this solution. Like Globalize Versioning, you can add Paper Trail support for the Active Record's Translation class, however there are a few pitfalls to this method currently.

First you need to include the gems in your Gemfile:

gem "i18n-active_record"
gem "paper_trail"

Then you need to make sure your Translation model class is inheriting from I18n Active Record::Translation and call and calls has_paper_trail:

class Translation < I18n::Backend::ActiveRecord::Translation
    has_paper_trail
end

This should really be enough, however the store_translations method in I18n Active Record do not update existing records. Instead, each time a record is added, all records with the given key are deleted and a new record is created. This causes confusion for Paper Trail since it relied on an id.

To get around this issue, I created my own store_translation method, which will update records if they exist:

def store_translations(locale, data, options = {})
    escape = options.fetch(:escape, true)
    I18n.backend.flatten_translations(locale, data, escape, false).each do |key, value|
        t = Translation.find_or_create_by!(locale: locale.to_s, key: key.to_s)
        t.value = value
        t.save
    end
    I18n.backend.reload!
end

Notice I also included I18n.backend.reload!, this is because I am running Memoize to cache translations but it seems that it needs to be told to recache whenever a record is updated.

Now I can simply call:

store_translations(lang, {key => key}, :escape => false)

to a store a new translation and ensure we keep a record of the old one and who made the change.

Upvotes: 0

Nimir
Nimir

Reputation: 5839

We had a very successful experience using Globalize (github page: https://github.com/globalize/globalize) and as for the versioning part we didn't try it but Globalize does have support for that in a seperate gem github page: (https://github.com/globalize/globalize-versioning)

After tens of painful gem experiences, i found that comparing gems by last update date and how frequent is new releases, bugs fixes and support is a major factor to decide which one will make your life easier and which one won't.

Update:

You can use Globalize to dynamically translate views (check tutorial) but i came across a github project called iye. I think it suits your needs best (github page: https://github.com/firmafon/iye)

Upvotes: 1

Related Questions