你如何在Rails中构建i18n yaml文件？

Question

我开始在Rails中填充一个en yaml文件,我已经可以告诉它在太久之前会变得混乱和失控.是否存在保持此文件有序的约定？

到目前为止,我有这样的结构:

language:
  resource:
    pages: # index, show, new, edit
      page html elements: # h1, title
  activerecord:
    attributes:
      model:
        property:

现在我有以下我想要适应这个结构的东西,但我不确定如何:

1. 导航
2. 按钮文本(保存更改,创建帐户等)
3. 来自控制器闪存的错误消息
4. 如何添加多字键.我使用空格还是下划线？例如,t(".update button"))或t(".update_button")

区域设置文件结构是否有约定？

Answer 1

我发现最好的整体策略是稍微重现文件结构,以便给定任何翻译,我可以立即找到它的调用位置.这给了我一些翻译的背景.

大多数应用程序翻译都可以在视图中找到,因此我通常会使用最大的顶级命名空间views.

我为控制器名称和操作名称或部分正在使用ex创建子命名空间:

• views.users.index.title
• views.articles._sidebar.header

这两个示例都应该明确我们正在翻译的应用程序的哪个部分以及要查找的文件.

你提到导航和按钮,如果它们是通用的,那么它们views.application就像它们的视图对应物一样属于命名空间:

• views.application._main_nav.links.about_us - 我们应用主要导航部分中的链接
• views.application.buttons.save
• views.application.buttons.create - 我有一堆这些按钮可以在需要时使用

Flash消息是从控制器生成的,因此它们的顶级命名空间是...... controllers!:)

我们对视图应用与我们相同的逻辑:

• controllers.users.create.flash.success|alert|notice

再次,如果你想提供像"操作成功"这样的通用flash消息,你会写这样的东西:

• controllers.application.create.flash.notice

最后,键可以是任何有效的YAML,但请坚持使用句点.作为分隔符和_单词之间的下划线作为惯例.

现在唯一需要解决的问题是将rails的翻译放入自己的命名空间以清理我们的顶层:)

Answer 2

我知道答案已被接受,但这个问题为我提供了一些思考的东西,我想我会为Rails i18n yml文件分享另一个结构供您考虑/批评.

鉴于我想

1. 保持默认的应用程序结构,以便我可以使用像t('.some_translation')我的视图中的简写"懒惰"查找,
2. 避免尽可能多的字符串重复,特别是使用不仅相同的单词,但也有相同的上下文/含义,
3. 只需更改一次密钥就可以反映出它引用的所有地方,

对于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中是否存在锚定引用的其他问题,或者可能只是整个"词典"概念？或者只是完全删除默认后端并用Redis或其他东西替换它更好？

Answer 3

您的问题不容易回答,并且该主题没有太多可用的材料.我发现最好的资源是:

• Rails样式指南,国际化部分
• I18n wiki中有很多资源,但我没有找到一些可以回答你问题的资源.

所以我将在这里直接尝试:

• 导航

  我认为你的意思是导航元素,如面包屑,标签,......你必须为它们定义视图,然后坚持规则将所有视图元素移动到目录中的单独文件中views(参见规则的样式指南).

• 按钮文本(保存更改,创建帐户等)

  查看元素,也可以进入相同的文件.如果在不同视图中使用相同的按钮,请定义公共文件,然后使用该文件.

• 来自控制器闪存的错误消息

  我会使用与视图相同的规则.定义一个单独的目录,包括控制器的文件.

• 如何添加多字键.我使用空格还是下划线？例如,t(".更新按钮"))或t(".update_button")

  我个人更愿意使用.update_button,而不是.update button因为它更明确地表明这是一个关键.

Answer 4

在我提出这个问题差不多两年后,我想分享一些见解.我认为最佳结构是根据MVC角色(模型,视图,控制器)命名空间.这使语言环境文件保持整洁,并防止命名空间冲突(例如,范围en.users可以表示视图或控制器).

en:
  controllers:
    users:
      show:
        welcome_flash: "Welcome back!"
  mailers:
    users_mailer:
      welcome_email:
        subject: "Good of you to join us"
  views:
    users:
      show:
        notice: "Oh no!

但是使用像这样的整洁命名空间会破坏Rails中的延迟查找功能.如果你使用懒惰的查找,Rails会自动插入命名空间的你,也不会包含您所创建的顶级命名空间(views,controllers,等...).

例如,t('.welcome_flash')解决范围en.users.show.由于用户没有明确定义,因此很糟糕.它是什么？控制器？一个看法？别的什么？

为了解决这个问题,我创建了gem I18nLazyLookup.它允许您使用自己的自定义命名空间进行延迟查找.

t您可以使用t_scoped('welcome_flash'),而不是使用,这将自动解析范围en.controllers.users.show.它也适用于视图和邮件程序,您可以按自己喜欢的方式自定义命名空间.

Answer 5

直接编辑yaml文件会导致文件混乱和不可读.
此外,如果有一天您希望非开发人员添加新语言,那么您很难提供对翻译人员的访问权限.

我建议使用localeapp,它生成一个yaml文件.
但是,您可以在Web界面中轻松查看和管理您的翻译.
并创建额外的翻译访问权限.