如何在Rails中构造i18n yaml文件?

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?

我开始在Rails中填充en yaml文件，我已经知道它很快就会变得混乱和失控。是否有保持文件组织的约定?

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:

现在我有一些我想要融入这个结构的东西，但是我不知道如何去适应:

Navigation
导航
Button text (save changes, create account, etc)
按钮文本(保存更改、创建帐户等)
Error messages from controller flash
来自控制器flash的错误消息
How to add multi-word keys. Do I use a space or an underscore? For exmaple, t(".update button")) or t(".update_button")
如何添加多字键。我使用空格还是下划线?例如,t(”。更新按钮”))或t(“.update_button”)

Is there a convention to locale file structure?

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

6 个解决方案

#1

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.users.index.title
views.articles._sidebar.header
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._main_nav.links。about - us - app主导航部分的链接
views.application.buttons.save
views.application.buttons.save
views.application.buttons.create - I have a bunch of these buttons ready to be used when needed
views.application.buttons。create——我有很多这样的按钮可以在需要的时候使用

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

Flash消息是由控制器生成的，所以它们的*名称空间是……控制器!:)

We apply the same logic as we do to views :

我们将同样的逻辑应用于观点:

controllers.users.create.flash.success|alert|notice
controllers.users.create.flash.success | |警告通知

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

同样，如果你想提供“操作成功”之类的通用flash消息，你可以这样写:

controllers.application.create.flash.notice
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.

最后，键可以是任何有效的YAML，但是请坚持使用句点。作为分隔符和下划线作为惯例。

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

现在唯一需要解决的问题是，将rails的翻译转换为它自己的名称空间来清理我们的顶层:)

#2

I know that an answer has already been accepted, but this question provided me with some food for thought and I thought I'd share another structure for Rails i18n yml files for your consideration/criticism.

我知道一个答案已经被接受了，但是这个问题给了我一些思考的食粮，我想我将分享另一个Rails i18n yml文件的结构供您考虑/批评。

Given that I would like to

考虑到我愿意。

keep the default app structure so I can use shorthand "lazy" lookups like t('.some_translation') in my views,
保留默认的应用程序结构，这样我就可以在视图中使用类似t('.some_translation')的快捷“惰性”查询，
avoid as much string repetition as possible, in particular with words that are not just the same, but also have identical contexts/meanings,
尽量避免重复使用字符串，尤其是那些不仅相同，而且上下文/意思相同的词，
only have to change a key once to have it reflected everywhere it's referenced,
只需要修改一次键就可以将它映射到它所引用的任何地方，

for a config/locales/en.yml file that looks something like this:

配置/地区/ 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

I can see that there is significant repetition, and that the context of words like "Email" and "Password" are unambiguous and have the same meaning in their respective views. It would be a bit annoying to have to go and change them all if I decide to change "Email" to "e-mail", so I'd like to refactor the strings to reference a dictionary of some sort. So, how about adding a dictionary hash to the top of the file with some & anchors like this:

我可以看到有很多重复的地方，像“Email”和“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

Whenever you get more than one instance of exactly the same word/phrase in your views, you could refactor it out to the dictionary. If the dictionary translation of a key in the base language doesn't make sense for a target language, then just change out the referenced value in the target language to a static string or add it as an extra entry to the target language's dictionary. I'm sure each language's dictionary could be refactored out into another file if they get too big and unwieldy.

当您的视图中有多个完全相同的单词/短语实例时，您可以将其重构到字典中。如果基语言中键的字典翻译对目标语言没有意义，那么只需将目标语言中的引用值更改为静态字符串，或者将其作为目标语言字典的额外条目添加到该字符串中。我确信，如果每种语言的字典太大、太笨拙，它们可以重构到另一个文件中。

This way of structuring i18n yaml files seemed to work well with some local test apps I tried it on. I'm hoping the wonderful Localeapp will provide support for this kind of anchoring/referencing in the future. But anyway, all this dictionary talk can't possibly be an original idea, so are there other issues with anchor referencing in YAML, or maybe just with the whole "dictionary" concept in general? Or is it just better to just rip out the default backend entirely and replace it with Redis or something?

这种构建i18n yaml文件的方法似乎与我尝试过的一些本地测试应用程序很好。我希望这个出色的Localeapp能够在未来为这种锚定/引用提供支持。但是无论如何，所有这些字典的讨论都不可能是一个原创的想法，那么在YAML中锚定引用还有其他的问题吗，或者可能只是整个“字典”概念的问题?还是干脆把默认的后端完全撕掉，用Redis之类的东西来替换它更好?

#3

Your question is not easy to answer, and there is not much material available on that topic. I have found the best resources are:

你的问题不容易回答，关于这个话题没有多少资料。我发现最好的资源是:

Rails Styleguide, section Internationalization
Rails格式指南,部分国际化
There are a lot of resources in the I18n wiki, but I don't have found there some that answer your questions.
在I18n的维基中有很多资源，但是我没有找到一些回答你的问题。

So I will give it a try directly here:

所以我直接在这里试一下

Navigation

导航

I think you mean here the navigation elements like breadcrumbs, tabs, ... You have to define views for them, and stick then to the rule to move all view elements in separate files in the directory views (see the styleguide for the rule).

我想你是说导航元素，比如面包屑，标签等等。您必须为它们定义视图，然后按照规则移动目录视图中不同文件中的所有视图元素(请参阅规则的styleguide)。
Button text (save changes, create account, etc)

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

View elements, go into the same files as well. If you use the same buttons in different views, define a common file, and use that then.

查看元素，也进入相同的文件。如果在不同的视图中使用相同的按钮，那么定义一个公共文件，然后使用它。
Error messages from controller flash

来自控制器flash的错误消息

I would use the same rule as for views. Define a separate directory, include there the files for the controllers.

我将使用与视图相同的规则。定义一个单独的目录，包含控制器的文件。
How to add multi-word keys. Do I use a space or an underscore? For exmaple, t(".update button")) or t(".update_button")

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

I personally would prefer to use .update_button, not .update button, because it makes more explicit that this is one key.

我个人更喜欢使用.update_button，而不是.update按钮，因为它更明确地表示这是一个键。

#4

It's almost two years after I asked this question, and I want to share some insights. I believe the optimal structure is to namespace translations according to their MVC role (models, views, controllers). This keeps the locale file tidy, and prevents namespace collisions (for example, the scope en.users can represent a view or a controller).

我问这个问题已经快两年了，我想分享一些见解。我认为最优的结构是根据它们的MVC角色(模型、视图、控制器)来命名空间转换。这样可以保持语言环境文件的整洁，并防止名称空间冲突(例如，范围en)。用户可以表示视图或控制器)。

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!

But using tidy namespaces like that breaks the lazy lookup feature in Rails. If you use lazy lookup, Rails will insert the namespace automatically for you, and it will not include the top level namespaces you created (views, controllers, etc...).

但是像这样使用整洁的名称空间会破坏Rails中的惰性查找特性。如果您使用惰性查找，Rails会自动为您插入名称空间，它不会包含您创建的*名称空间(视图、控制器等等)。

For example, the scope of t('.welcome_flash') resolves to en.users.show. Which stinks because users isn't clearly defined. What is it? A controller? A view? Something else?

例如，t('. welcom_flash ')的范围解析为em .user .show。这很糟糕，因为用户没有明确的定义。它是什么?一个控制器吗?一个视图?别的吗?

To solve this problem I created the gem I18nLazyLookup. It allows you to use lazy lookup with your own custom namespaces.

为了解决这个问题，我创建了gem I18nLazyLookup。它允许您使用自己的自定义名称空间使用惰性查找。

Instead of using t, you can use t_scoped('welcome_flash'), and that would automatically resolve the scope to en.controllers.users.show. It also works for views and mailers, and you can customise the namespace the way you like.

与使用t不同，您可以使用t_scoped(' welcom_flash ')，它将自动解析作用域到en.controllers.users.show。它也适用于视图和邮件，您可以按照自己的方式定制名称空间。

#5

Editing directly the yaml files leads to messy and unreadable files.
Moreover, it'll be difficult for you to provide access to translators if, someday, you want a non-developer to add a new language.

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

I would recommend using localeapp, which generates a single yaml file.
But allows you to easily see and manage your translations in a web interface.
And to create additional access to translators.

我推荐使用localeapp，它生成一个yaml文件。但是允许您轻松地在web界面中查看和管理您的翻译。并创建对翻译人员的额外访问。

#6

Coming several years after the battle, but here is a (somewhat totally) different answer.

在这场战役的几年后，这里有一个(有点完全不同的)答案。

To begin with, I do not like the standard t('.xxx') style with the default namespace based on the file structure. I also don't really like the categorisation of translations depending on the DOM structure. While this is a nice approach for very structured translations, it is often repetitive, and not very intuitive.

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

I'd rather regroup my translations into more useful categories, so as to make it easier for my translators, because they can work on concrete themes, rather than some weird styles (some translators do not even know what MVC means)

我宁愿将我的翻译重新分组到更有用的类别中，以便使我的翻译人员更容易，因为他们可以处理具体的主题，而不是一些奇怪的样式(有些翻译甚至不知道MVC的含义)

so my translation file is structured like this

我的翻译文件是这样构造的。

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

Depending on the needs, the "themes" can be a model, a more abstract context, etc. that is the most intuitive for the translators.

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

Because this would be a hassle to write everytime the scope in my views, I have added some convenience methods in my helpers to have a stack based translation context.

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

I push/pop translation scopes on a stack in my views by calling t_scope([new_scope] and pop_t
通过调用t_scope([new_scope])和pop_t，我在视图的堆栈上推/pop转换作用域
I override the t helper to use the last scope of the stack
我重写t helper函数以使用堆栈的最后一个范围

The code for the translation scoping methods is available in that answer

在这个答案中可以找到转换范围方法的代码

#1