CODEWITHSUNDEEP
ruby-on-railsinternationalizationyaml
Basel Shishani
Basel Shishani

Reputation: 8187

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

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:

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.

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?

Upvotes: 1

Views: 1716

Answers (2)

Henrik N
Henrik N

Reputation: 16294

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.

Upvotes: 3

user483040
user483040

Reputation:

For me, the main benefit of the layout of YAML files is that it's quite easy at a glance to see the relationships between the configuration data. I spent a few years working with Python, which defines scope with white space rather than extraneous characters like {}, etc, so the paradigm is comfortable for me.

Arguably, if you have large yaml files...thousands of keys...then it's probably time to start breaking up the files into smaller, more manageable files. When I am writing code in general and I get a file of ANY sort that is that large, I refactor mercilessly to organize things more intuitively.

Largely this is druthers, I suppose.

Upvotes: 0

Related Questions