ruby-on-rails – 用于数据库表的Rails 3 I18n

发布时间：2020-12-17 03:13:06 所属栏目：百科来源：网络整理

导读：我正在寻找有关使用国际化的最佳实践的一些提示和建议.我一直在四处寻找,但我对我读到的内容并不满意.我读过的大部分文章都集中在使用I18n的yml文件,这在我的情况下是行不通的. 我目前有几个带英文文本的数据库表.其中一些表的文本字段长度只有几句,有些则是

我正在寻找有关使用国际化的最佳实践的一些提示和建议.我一直在四处寻找,但我对我读到的内容并不满意.我读过的大部分文章都集中在使用I18n的yml文件,这在我的情况下是行不通的.

我目前有几个带英文文本的数据库表.其中一些表的文本字段长度只有几句,有些则是6段文本.我想用西班牙语这些字段.

我目前正在考虑的方法是使用I18n-active记录gem并拥有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内容时.应用程序将在原始表中查询密钥,然后查询转换表.另一个问题是转换表将是庞大的并且具有大量行,因为它将存储应用程序的所有翻译(从章节标题[几个单词]到整个文本页面的所有内容).

任何信息表示赞赏.谢谢

解决方法

在db中存储翻译并不是一个太糟糕的解决方案.不要害怕大表 – 数据库是为此而制作的！只需确保正确配置索引并尽可能缓存.

另一个更快,可能更好的解决方案是使用Redis作为I18n的后端.见http://guides.rubyonrails.org/i18n.html#using-different-backends和http://railscasts.com/episodes/256-i18n-backends.

无论你在哪里存储翻译,都没有必要尝试自己管理插值,因为I18n库处理得非常好(除非你做的是真正定制的东西,就是这样).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!