我正在创建一个应用程序，其中产品将由我的客户创建（类似于电子商务网站），所以我显然需要存储在数据库中的翻译描述，我不能强迫我的客户学习git / yml。
我有两个关于如何正确本地化描述（以及最终产品名称）并将它们存储在数据库中的想法，但如果有一个我应该使用的众所周知的方法，我会很高兴知道它。
第一个想法对我来说似乎是最合乎逻辑的，但我想让它“透明”给我，我不想在任何地方写连接，所以关于如何实现这个的一些建议，如果它是正确的，将不胜感激。
创意1：
创建一个数据库表products（可以将name和description字段设置为默认的语言环境语言），然后创建一个products_translations表，其中包含以这种方式构造的表： / p>
products_translations
- id
- locale
- product_id
- name
- description
例如：product_translation: { id: 1, locale: 'en', product_id: 3, name: 'toy', description: 'play' }
但我想访问翻译而无需在任何地方写入大量的IF。因此，如果我编写product.name，它应该根据当前的语言环境返回en或它。
奖金：有没有可以帮助我实现这一目标的宝石？
创意2：另一个想法是建立一个包含name_locale1，name_it等的表格，但我不喜欢这种做法，因为会污染我的模型有田野的物品，我会有一张巨大的桌子。
但是，通过这种方式，我可以避免加入该对象的每个查询。
如果有一个我不了解的更多方法（数据库模式或类似方法），那也没关系，我没有被迫严格只考虑这两个想法，但我必须在两者之间做出选择我真的不知道哪个更好。
重要提示：我希望将翻译保存在yml文件中，动态内容除外，这显然需要在数据库中进行翻译。
答案 0 :(得分：3)
我同意PinnyM的看法，第一种方法比两者更好，但我强烈建议您实施Globalize3，其中大部分结构决策都是针对您进行的（并且由Fuchs先生自己，并没有减少）。另外，使用rails帮助程序，你只需在模型实例上调用类似product.name的内容，gem就会知道如何在正确的语言环境中显示它，真棒！
答案 1 :(得分：2)
第一种方法是推荐的方法。正如你所推测的那样，第二种方法并不是那么干净，并且需要在编码端进行更多的工作而没有真正的收益，因为你仍然必须加入这个怪物桌。相反，第一种方法最多需要一次连接，而第二种方法需要连接每个属性，您可能需要添加本地化支持。
您只需在所有产品调用上附加范围，例如：
scope :for_locale, lambda{|locale| joins(:product_translations).
where(product_translations: {locale: locale || 'en'}) }
并传入会话区域设置（或存储它的任何位置）。