【问题标题】:Hook into Rails' I18n连接到 Rails 的 I18n
【发布时间】:2024-01-07 21:20:01
【问题描述】:

我编写了一个小库来保存模型属性中的翻译内容。您所要做的就是将以下内容添加到模型中:

class Page < ActiveRecord::Base
  i18n_attributes :title, :content
end

按照惯例,数据被写入真实属性 i18n_title 和 i18n_content 作为散列(或 Postgres 的 hstore 散列)。还有一些 getter 和 setter 让你可以访问“本地化的虚拟属性”:

page = Page.new
page.title_en = 'Hello'
page.title_es = 'Hola'
page.i18n_title   # => { en: "Hello", es: "Hola" }
I18n.locale = :es
page.title        # => "Hola"
page.title_en     # => "Hello"

您也可以在表单中使用这些虚拟属性,但有一个缺点:表单构建器使用 I18n 来获取标签并转换属性验证错误。如果您在表单中使用title_en,它当然会查找诸如activerecord.attributes.page.title_en 之类的键。

locales/en.yml等文件中的每个available_locale复制相同的翻译会非常麻烦:

activerecord:
  attributes:
    page:
      title_en: "Title"
      title_es: "Title"
      ...

我想做的是在 Rails 在启动过程中加载所有语言环境后执行一些代码,然后克隆这些键的翻译。有没有办法做到这一点?也许是在从 YAML 文件加载翻译后调用的钩子? (当我的库加载时,翻译尚未加载。)

或者您是否看到了解决此问题的另一种方法? (我试过给 I18n.translate 取别名,但我担心这可能会在未来引起很大的麻烦。)

感谢您的提示!

【问题讨论】:

  • 我已经放弃了这种方法,所以这个问题不再相关 - 至少对我来说不是。

标签: ruby-on-rails activerecord ruby-on-rails-3.2 i18n-gem


【解决方案1】:

虽然你放弃了这种方法,但请让我分享一下我的想法:

我认为将其他语言环境字符串添加到特定本地化的翻译文件中并没有什么用处。因为config/locales/$locale.yml 通常以(至少在我的情况下)以

开头
$locale:
  ...

英文本地化文件中不需要activerecord.attributes.page.title_es。我只是把它放在es.yml 作为activerecord.attributes.page.title

我的意思是:这不是单独的本地化文件的全部目的吗? (或者从开发人员/翻译人员的角度来看:我应该在哪个文件中搜索.title_esen.ymles.yml 或两者兼而有之?)

【讨论】:

    最近更新 更多