2014-02-11 3 views
0

Я в процессе создания механизма перевода на основе добровольцев для нового сайта, созданного в Rails 4.0. Поскольку он основан на добровольцах, всегда существует вероятность, что пользователь может ввести перевод, который другие не согласны с ним, случайно удалить перевод и т. Д. В таком случае я хотел бы дать пользователям возможность вернуться к предыдущему переводу ,Версии для Rails i18n переводы

Я немного искал, но еще не нашел решения, кроме написания собственного I18n-бэкэнд. Существует ли более простой способ хранения предыдущих версий переводов?

В настоящее время я использую Sven Fuchs' Active Record как бэкэнд, однако я серьезно подумываю о переключении из-за возможных проблем с производительностью позже в будущем.

ответ

1

У нас был очень успешный опыт использования Globalize (GitHub страница: https://github.com/globalize/globalize), так и для управления версиями части мы не пробовал, но Globalize имеет поддержку, что в отдельно камень GitHub страницы: (https://github.com/globalize/globalize-versioning)

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

Update:

Вы можете использовать глобализацию динамически переводить взгляды (check tutorial), но я наткнулся на GitHub проект под названием ийэ. Я думаю, что это соответствует вашим потребностям лучше всего (страница github: https://github.com/firmafon/iye)

+0

Спасибо, но мне кажется, что глобализация только сохраняет переведенный текст для моделей, а не для статического содержимого сайта (материал, который по умолчанию хранится в файлах YAML). – Godwin

+0

@Godwin, так что вы пытаетесь перевести представления? а не сайт, прямо! – Nimir

+0

извините, все еще опираясь на основы для Rails. Да. – Godwin

0

Я использовал помощь Нимира, чтобы найти это решение. Подобно Globalize Versioning, вы можете добавить Paper Trail поддержку для Active Record 's Translation класс, однако есть несколько подводных камней для этого метода в настоящее время.

Прежде всего, необходимо включить драгоценные камни в вашем Gemfile:

gem "i18n-active_record" 
gem "paper_trail" 

Затем вы должны убедиться, что ваша модель Translation класс наследует от I18N Active Record :: Перевод и вызов и вызывает has_paper_trail:

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

Этого действительно должно быть достаточно, однако метод store_translations в I18n Active Record не обновляет существующие записи. Вместо этого каждый раз, когда добавляется запись, все записи с заданным ключом удаляются и создается новая запись. Это вызывает путаницу для Paper Trail, поскольку она полагается на идентификатор.

Чтобы обойти эту проблему, я создал свой собственный store_translation метод, который будет обновлять записи, если они существуют:

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 

Примечание Я также включил I18n.backend.reload!, это потому, что я бегу Memoize переводам кэша, но кажется, что ему нужно сообщить, чтобы он обновлялся всякий раз, когда запись обновляется.

Теперь я могу просто позвонить:

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

в магазин новый перевод и обеспечить нам вести учет старой и кто сделал изменения.

Смежные вопросы