你如何在 Rails 中构建 i18n yaml 文件? [英] How do you structure i18n yaml files in Rails?

查看:21
本文介绍了你如何在 Rails 中构建 i18n yaml 文件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我开始在 Rails 中填充一个 en yaml 文件,我已经知道它会在不久之后变得混乱和失控.是否有组织此文件的约定?

到目前为止我有这个结构:

语言:资源:页数:# 索引、显示、新建、编辑页面 html 元素:# h1,标题活动记录:属性:模型:财产:

现在我想将以下内容融入这个结构,但我不确定如何:

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

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

解决方案

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

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

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

  • 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 的翻译转换到它自己的命名空间中以清理我们的顶层 :)

I started populating an en yaml file in Rails and I can already tell it will get messy and out of hand before too long. Is there a convention to keeping this file organized?

So far I have this structure:

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

Now I have the following things that I want to fit into this structure but I'm unsure how to:

  1. Navigation
  2. Button text (save changes, create account, etc)
  3. Error messages from controller flash
  4. How to add multi-word keys. Do I use a space or an underscore? For exmaple, t(".update button")) or t(".update_button")

Is there a convention to locale file structure?

解决方案

I've found that the best overall strategy is to somewhat reproduce the file structure so that given any translation, I can immediately find where it was called from. This gives me some kind of context for making the translation.

The majority of application translations are found in views, so my biggest top level namespace is usually views.

I create sub namespaces for the controller name and the action name or partial being used ex :

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

Both of these examples should make it obvious what part of my app we're translating and which file to look in to find it.

You mention navigation and buttons, if they are to be generic, then they belong in the views.application namespace just as do their view counterparts :

  • views.application._main_nav.links.about_us - a link in our app's main navigation partial
  • views.application.buttons.save
  • views.application.buttons.create - I have a bunch of these buttons ready to be used when needed

Flash messages are generated from the controller, so their top level namespace is... controllers! :)

We apply the same logic as we do to views :

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

Again if you wanted to provide generic flash messages like "Operation successful", you would write something like this :

  • controllers.application.create.flash.notice

Finally, keys can be anything that is valid YAML, but please stick to using periods . as separators and underscores _ between words as a matter of convention.

The only thing left to sort out now, is getting rails' translations into its own namespace to clean up our top level :)

这篇关于你如何在 Rails 中构建 i18n yaml 文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆