52

我开始在 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")

语言环境文件结构是否有约定？

4

6 回答 6

63

我发现最好的总体策略是在某种程度上重现文件结构，以便在给定任何翻译后，我可以立即找到调用它的位置。这给了我一些翻译的背景。

大多数应用程序翻译都在视图中找到，所以我最大的顶级命名空间通常是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 的翻译转换到它自己的命名空间中，以清理我们的顶层 :)

于 2012-04-28T14:20:55.110 回答
51

我知道答案已经被接受，但是这个问题为我提供了一些思考的食物，我想我会分享 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或其他东西替换它会更好？

于 2012-06-18T20:00:02.483 回答
9

您的问题不容易回答，并且关于该主题的可用材料不多。我发现最好的资源是：

所以我直接在这里试一试：

  • 导航

    我认为您的意思是导航元素，例如面包屑，选项卡，...您必须为它们定义视图，然后遵守规则以将所有视图元素移动到目录中的单独文件中views（请参阅规则的样式指南）。

  • 按钮文本（保存更改、创建帐户等）

    查看元素，也进入相同的文件。如果您在不同的视图中使用相同的按钮，请定义一个通用文件，然后使用它。

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

    我会使用与视图相同的规则。定义一个单独的目录，在其中包含控制器的文件。

  • 如何添加多字键。我使用空格还是下划线？例如，t(".update button")) 或 t(".update_button")

    我个人更喜欢使用.update_button, not .update button，因为它更明确地表明这是一个键。

于 2012-04-28T10:35:03.247 回答
9

我问这个问题已经快两年了，我想分享一些见解。我相信最佳结构是根据它们的 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您可以使用,而不是 using ，t_scoped('welcome_flash')这会自动将范围解析为en.controllers.users.show. 它也适用于视图和邮件程序，您可以按照自己喜欢的方式自定义命名空间。

于 2015-01-28T10:58:51.190 回答
6

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

我建议使用localeapp，它会生成一个 yaml 文件。
但允许您在 Web 界面中轻松查看和管理您的翻译。
并为翻译人员创建额外的访问权限。

于 2012-04-23T16:53:39.067 回答
0

战斗结束几年后，但这是一个（有点完全）不同的答案。

首先，我不喜欢t('.xxx')基于文件结构的默认命名空间的标准样式。我也不太喜欢根据 DOM 结构对翻译进行分类。虽然这对于非常结构化的翻译来说是一种很好的方法，但它通常是重复的，而且不是很直观。

我宁愿将我的翻译重新组合成更有用的类别，以便让我的翻译更容易，因为他们可以处理具体的主题，而不是一些奇怪的风格（有些翻译甚至不知道 MVC 是什么意思）

所以我的翻译文件的结构是这样的

fr:
  theme1:
    theme11:
      translationxxx: blabla
  theme2:
    translationyyy: blabla

根据需要，“主题”可以是模型、更抽象的上下文等，这对译者来说是最直观的。

因为每次在我的视图中编写范围都会很麻烦，所以我在助手中添加了一些方便的方法来获得基于堆栈的翻译上下文。

  • 我通过调用t_scope([new_scope]和pop_t
  • 我覆盖了t帮助器以使用堆栈的最后一个范围

该答案中提供了翻译范围方法的代码

于 2016-03-14T22:08:18.173 回答