例如，Rails 3 中的服务条款文档国际化的最佳做法是什么？我可以想到两个选择：
<li><%= I18n.t :tos_paragraph_1 %></li><li><%= I18n.t :tos_paragraph_2 %></li>这些似乎都不是一个好的解决方案。有什么想法吗？
【问题讨论】：
标签： ruby-on-rails ruby-on-rails-3 internationalization translation
有一些解决方案，但如果我是为生产项目执行此操作，我可能会执行以下操作：
config/locales/terms/ 中为您翻译的服务条款创建文件，将它们命名为terms.en.html，将en 替换为每个翻译的语言环境，将html 替换为文件的格式（例如，您可以使用Haml、Markdown等）。创建以下辅助方法（将它们放在app/helpers/application_helper.rb 以在任何地方使用它们，但您可以将它们放在您需要/想要的任何辅助文件中）：
def localized_document_for(document, locale)
raise ArgumentError.new('nil is not a valid document') if document.nil?
raise I18n::InvalidLocale.new('nil is not a valid locale') if locale.nil?
localized_document = path_for_localized_document(document, locale)
raise MissingTranslationData unless File.exists?(localized_document)
# If you're using Markdown, etc. replace with code to parse/format your document
File.open(localized_document).readlines.join
end
def path_for_localized_document(document, locale)
"#{Rails.root}/config/locales/#{document}/#{document}.#{locale.to_s}.html"
end
现在，在您看来，您可以随时使用localized_document_for('terms', I18n.locale) 获取用户语言的服务条款内容。现在您用于获取文档的代码是 DRY（您可以通过在 config/locales 中创建另一个目录并更改 document 参数的值来轻松获取其他文档），并且您的翻译文档存储在它们自己的目录中并且可以轻松编辑（并且不依赖于 YAML，这对于将单个文档存储在文件中没有任何价值）。
请注意，如果您想以“Rails 3 方式”执行此操作，您可以使用I18n::Backend::Chain（请参阅https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/chain.rb），并传入I18n::Backend::Simple.new 以及根据需要读取文件的自定义后端，但对于一次性交易，我相信帮手们工作得很好。
【讨论】：
为每种语言创建一个分部肯定是多余的。
Rails 方式是您建议的第二种选择，每种语言都有一个 .yml。
该文档提供了很好的示例，可让您根据每个页面组织 yml。因此，您有所有变量的快捷方式。
【讨论】：