这个StackOverflow 问题让我思考了什么是 Rails i18n 文件的良好结构，所以我想我会分享另一个重构 Rails i18n yml 文件的结构供您考虑/批评。
鉴于我想
- 保留默认的应用程序结构，这样我就可以像
t('.some_translation')在我的视图中一样使用速记“惰性”查找，并了解应用程序中使用翻译的位置， - 避免尽可能多的字符串重复，特别是使用不仅相同而且具有相同上下文/含义的单词，
- 只需更改一次密钥，即可在所引用的任何地方反映出来，
对于看起来像这样的config/locales/en.yml文件：
activerecord:
attributes:
user:
email: Email
name: Name
password: Password
password_confirmation: Confirmation
models:
user: User
users:
fields:
email: Email
name: Name
password: Password
confirmation: Confirmation
sessions:
new:
email: Email
password: Password
我可以看到有很多重复，并且“电子邮件”和“密码”等词的上下文是明确的，并且在它们各自的视图中具有相同的含义。如果我决定将“电子邮件”更改为“电子邮件”，则必须全部更改它们会有点烦人，所以我想重构字符串以引用某种字典。那么，如何将字典哈希添加到文件顶部，并带有一些&锚点，如下所示：
dictionary:
email: &email Email
name: &name Name
password: &password Password
confirmation: &confirmation Confirmation
activerecord:
attributes:
user:
email: *email
name: *name
password: *password
password_confirmation: *confirmation
models:
user: User
users:
fields:
email: *email
name: *name
password: *password
confirmation: *confirmation
sessions:
new:
email: *email
password: *password
您仍然可以继续使用静态字符串（例如上面的“用户”），但是只要您在视图中获得多个完全相同的单词/短语的实例，您就可以将其重构到字典中。如果基础语言中的键的字典翻译对目标语言没有意义，那么只需将目标语言中的引用值更改为静态字符串或将其作为额外条目添加到目标语言的字典中。我敢肯定，如果每种语言的字典变得太大且笨拙，可以将它们重构到另一个文件中（只要它在翻译文件的顶部重新导入，以便参考工作）。
这种构建 i18n yaml 文件的方式似乎适用于我尝试过的一些本地测试应用程序。我希望精彩的Localeapp将来能为这种锚定/引用提供支持。但是无论如何，所有这些字典讨论都不可能是一个原创的想法，那么 YAML 中的锚引用是否还有其他问题，或者可能只是整个“字典”概念？或者，如果您有超出 Rails 默认 i18n 约定的需求，是否完全删除默认后端并将其替换为Redis或其他东西会更好？
编辑：
我想尝试解决在下面的评论中提到的 tigrish 的工作流程示例，而不是作为他的答案下方的另一条评论。如果我似乎没有得到所提出的观点或者我只是天真，请原谅我：
第 1 点：ActiveRecord 模型有一个通用的“名称”属性，它们都只是指向名称的通用字典：
dictionary:
name: &name Name
activerecord:
attributes:
name: *name
user:
name: *name
product:
name: *name
第 2 点：只需要更改用户模型的名称。其他名称保持不变。
选项 1：在后端保持模型字段名称相同，只需更改它指向的前端翻译。
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
选项 2：也更改用户模型字段名称。这将需要更改代码中对该键的任何引用，以及change_table/rename_column迁移。
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
full_name: *full_name
product:
name: *name
选项 3：如果您想非常彻底，请将“名称”中包含的信息重构为单独的数据库/Activemodel 字段，这需要新的字典条目和迁移。您可以决定您希望如何显示“全名”：
dictionary:
name: &name Name
name_prefix: &name_prefix Prefix
first_name: &first_name First
middle_name: &middle_name Middle
last_name: &last_name Last
name_suffix: &name_suffix Suffix
activerecord:
attributes:
name: *name
user:
name_prefix: *name_prefix
first_name: *first_name
middle_name: *middle_name
last_name: *last_name
name_suffix: *name_suffix
product:
name: *name
第 3 点：任何人出于任何原因都需要更改翻译，在这种情况下是营销。我将从第 2 点选项 1 的示例继续
选项1：模型字段名称相同，只需更改前端翻译。
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *funky_name
选项 2：出于某种原因，“Funky name”也迫切需要保存到数据库中。username如果没有人反对（或者funky_name由于某种原因营销坚持），我们就称它为。
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
username: *funky_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *name
funky_name: *funky_name
是的，所以我承认我对自己在做什么一无所知，但是，我愿意被公开拒绝，以了解为什么这种在 Haml 中使用 i18n 的方式在 Rails 应用程序中是一个坏主意。难以阅读？维护噩梦？如果我使用（我认为是）该语言的一个特性，它真的被认为是“破解文件格式”吗？
再次感谢 tigrish 驱使我完成这一切。