Question

globalize3 gem的github页面https://github.com/svenfuchs/globalize3清楚地概述了如何使用您希望多次翻译的字符串和文本属性来准备模型的迁移。例如：

 class CreatePosts < ActiveRecord::Migration
   def up
     create_table :posts do |t|
     t.timestamps
   end
   Post.create_translation_table! :title => :string, :text => :text
 end
 def down
   drop_table :posts
   Post.drop_translation_table!
 end
 end

如果我有某些不需要翻译的属性，例如保存user_id或其他整数值属性，该怎么办？我是否将它们作为Post.create_translation_table的一部分写在下面！声明，或将它们留在create_table：posts部分？

EG是正确的：

 def up
    create_table :posts do |t|
      #put it here as t.integer :user_id?
    end
    Post.create_translation_table! :title => string, :text => :text #user_id dec here?
 end

谢谢！

Answer 1

快速回答：是的，您可以像处理任何其他activerecord模型中的属性一样处理未翻译的属性，因此：

create_table :posts do |t|
  t.integer :user_id
end

是对的。

create_translation_table正在做的是创建一个名为post_translations的单独的表，它将存储已翻译属性的各个翻译以及特定翻译的区域设置和ID posts表中的父记录。

如果在运行迁移后查看schema.rb，您将看到两个表，其中一个表带有user_id（以及始终需要的时间戳）：

create_table "posts", :force => true do |t|
  t.integer  "user_id"
  t.datetime "created_at",                 :null => false
  t.datetime "updated_at",                 :null => false
end

和另一个翻译属性翻译表，这是您在迁移中调用create_translation_table创建的：

create_table "post_translations", :force => true do |t|
  t.integer  "post_id"
  t.string   "locale"
  t.string   "title"
  # any other translated attributes would appear here
  t.datetime "created_at",  :null => false
  t.datetime "updated_at",  :null => false
end

您可能会问，为什么globalize3会创建一个单独的表？为什么不把它们放在与父记录相同的表格中（在表格中，比如title_en，title_es等）？还有其他翻译宝石可以做到这一点，例如traco。但问题是，如果您将翻译放在父记录中，那么您必须事先指定您将支持的语言环境，因为您需要在每个语言环境中为该属性创建列。如果添加新的语言环境，则必须迁移数据库以支持它们。

另一方面，使用globalize3解决方案，您无需事先确定要支持的语言环境，因为转换表中的每个翻译记录都附加了一个语言环境 - 您无论如何“难以”代码“支持的语言环境。这是处理问题的一种非常优雅的方式，也是globalize3普及的基础，但它在开始时可能有点令人困惑，因为gem必须做一些技巧才能使它像一样属性附加到模型（Post），而它们实际上附加到另一个类Post::Translation。

无论如何，这比你要求的要多，但有用的东西要知道。

globalize3翻译gem：如何处理不需要翻译的属性（写作迁移）？

1 个答案: