Any advantages to expanded nested scope keys (vs path-like) in YAML i18n translation files in Rails

Question

Note: I'm not a RoR developer, so if there is anything inaccurate in the question please correct me.

RoR has its own i18n library. This library (optionally) uses YAML format for the localization files. In these localization files, key-value pairs are used where the value is the translation provided, but these key-value pairs can be within a scope (namespace), here are exapmles:

One example from here - http://guides.rubyonrails.org/i18n.html

pt:   
  foo:
    bar: baz

... the top level key is the locale. :foo is a namespace key and :bar is the key for the translation “baz”.

And another exapmle from here - http://ruby-on-rails-tutorials.blogspot.com/2010/11/i18n-in-rails3.html

en:
  contact:
    prices:
      show_price: "%{price_dollar}$"
      quote: "Coordinator: & quot;Crucifixion?& quot? & lt;br /& gt; Mr. Cheeky: & quot;Er, no, freedom actually.& quot;"

  attributes:
    created_at: "Created at"
    updated_at: "Updated at"

  helpers:
    submit:
      contact:
        create: "Order"
        update: "Modify"
    label:
      contact:
        name: "Your name"
        company_name: "Company name"
        phone: "Phone number"
        email: "E-mail"
        comment: "Comment"

Please check the pointers for better explanation.

An alternative style one can think of is to flatten the scope attributes: for example, in the last quote we can say:

helpers.label.contact.company_name: "Company name"

I believe that the nested style can be very confusing when editing large or deeply nested localization files. And indeed I found a couple of places where this issue is raised:

accessing I18n translations yamls - a thread complaining about this same issue on the rails-i18n group.

The reason of doing it was complications I met with working on huge piece of data in nested yml files. Having few thousands keys in few translations files, was making me furious when I needed rename translation keys, move them to another namespace etc. and had to scroll a lot, looking and wondering what is namespace of the key. Also, resolving merge conflicts, checking for missing translations in other locale files are much easier, when you have and see full key.

And here: https://github.com/henrik/vim-yaml-flattener someone has written a Vim plugin to flatten the file back and forth to overcome the issue.

My question is: what exactly are the advantages of having the nested style. Is there any issues with the flat style that made the developers go with the nested style despite the drawbacks?

Henrik N Henrik N · Accepted Answer · 2012-11-27T19:47:17

I wrote the YAML flattener plugin for Vim.

The main reason for the nested format, to me, is that it's conventional, so any tools or services we may want to use are likely to use that format.

I suppose there is some risk of making typos as you start repeating yourself, and renaming things means renaming them in multiple places – but they're also harder to find to rename, and your editor likely has good tools to rename in batch.

I could come up with more reasons (shorter lines, smaller files, less noisy diffs) but I don't think they're very important.

It's a good question. I'm considering using the flat format most of the time and only converting if I need to use an external tool.

Any advantages to expanded nested scope keys (vs path-like) in YAML i18n translation files in Rails

2 Answers