Rails 3 I18n для таблиц базы данных

Question

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

В настоящее время у меня есть несколько таблиц базы данных с текстом на английском языке. В некоторых из этих таблиц есть текстовые поля длиной в несколько предложений, а в некоторых - более 6 абзацев текста. Я хотел бы также иметь эти поля на испанском языке.

Подход, который я сейчас рассматриваю, заключается в использовании камня записей I18n-active и наличии 1 таблицы переводов, которую приложение будет использовать для всех переводов в приложении

 class CreateTranslations < ActiveRecord::Migration
    def self.up
      create_table :translations do |t|
        t.string :locale
        t.string :key
        t.text   :value
        t.text   :interpolations
        t.boolean :is_proc, :default => false

        t.timestamps
      end
    end

    def self.down
      drop_table :translations
    end
  end

Это лучший способ продолжить?

С одной стороны, все переводы будут хорошо храниться в одной таблице. С другой стороны, каждый раз, когда пользователь запрашивает базу данных для содержимого I18n. Приложение запросит исходную таблицу на предмет ключа, а затем также запросит таблицу переводов. Другая проблема заключается в том, что таблица перевода будет массивной и будет содержать огромное количество строк, поскольку в ней будут храниться все переводы для приложения (от заголовка раздела [несколько слов] до целых страниц текста.

Любая информация приветствуется. Спасибо

Answer 1

Хранение переводов в БД не является плохим решением. Не бойтесь больших таблиц - для этого созданы базы данных! Просто убедитесь, что ваши индексы настроены правильно и кэшируйте все, что можете.

Другое, более быстрое и, возможно, лучшее решение - использовать Redis в качестве бэкэнда для I18n. См http://guides.rubyonrails.org/i18n.html#using-different-backends и http://railscasts.com/episodes/256-i18n-backends.

Везде, где вы храните переводы, нет необходимости пытаться самостоятельно управлять интерполяциями, поскольку библиотека I18n справляется с этим довольно хорошо (если вы не делаете что-то действительно нестандартное, то есть).

Answer 2

Единственное преимущество, которое вам придется хранить в базе данных, - это если вы притворяетесь, что редактируете ее на лету. Так что, если это было ваше намерение, предложение пустяков - это путь. Но если вы не думаете об этом, простой YML сделает перевод интерфейса, имен таблиц, имен полей и т. Д.

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

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