0

我正在使用 Ruby on Rails v3.2.2 和Globalize3 v0.2.0 gem。目前我正在使用 Globalize3 将国家、地区和城市名称翻译成两种语言，但我计划用它来将我的应用程序国际化为更多语言（理想情况下，全部）。因此，我正在使用翻译数据填充数据库，但对此我有一些疑问：我是否应该使用所有country_translations国际化名称填充我的,region_translations和city_translations数据库表（即使某些名称可能与默认名称相同 - 在这个如果国际化名称为零或重复）？也就是说，在翻译表中，我应该为每个我的应用程序支持的语言环境（在我目前的情况下，两个语言环境）以及每个国家、地区和城市？

这样做，在支持所有语言的“理想”场景中，提到的表（主要是与地区和城市相关的表）将非常大，并且可能性能较低。另一方面，它确保 Globalize3 能够正常工作，因为在某些情况下似乎不存在国际化记录（我避免解释我的具体情况，因为它“很难”做，也许它会需要一本书来解释）gem没有正确地回退到当前的语言环境。

我应该如何进行？

4

1 回答 1

0

我建议您确实预先填充翻译。我一直在做一个项目，其中内容的语言是初步已知的（其中 5 个），并且客户想要 5 个选项卡用于在管理后端填充翻译（当他们编辑包含翻译的对象时）。

但是，如果您没有预先填充翻译，则不会发生这种情况。在我看来，这种情况下的数据库空间或速度不是问题；您将需要 100,000 多个对象，每个对象都有多个翻译，以在默认 MySQL 安装上引入甚至是轻微的滞后。

假设您使用 ActiveAdmin，您将执行以下操作：

# app/admin/your_models.rb
...
controller do
  def create
     ...
     YOUR_LANGUAGE_CODES.each do |lang|
       @your_model.translations.build(:locale => lang, :text => YOUR_DEFAULT_I18N_TEXT)
     end
  end
end

因此，当您在后台创建带有翻译的新对象时，您还将自动为其创建所有必要的翻译。当然，为了进行适当的清理，不要忘记在包含模型中包含它：

has_many :translations, :dependent => :destroy

...因此，当您销毁对象时，翻译会随之而来。

...或者，您可以只获取循环代码并将其包含在您用来创建包含翻译的对象的任何其他控制器方法中。

我没有完全理解你有点分层的翻译模型，但我相信我已经说明了我的观点。您应该能够对此进行扩展以满足您的特定需求。

于 2012-11-07T21:26:12.127 回答