I18n Rails – How to organize your locales in larger projects

As our rails projects grow bigger and bigger, the i18n locale files easily get messy and will loose their structure after a while. Especially when you have multiple software developers work on the same project.

So we develped a solution for us that is easier to handle and to maintain. The starting point is from the ruby on rails guides combined with this blog post:

We separated our yml files to the folders given by the rails structure. The yml files themself are also structured that way. This is a bit more efford in the beginning, but it is very nice to maintain, because you always know, where you have to put your locales and always know where to look for them!


Each file now only handles the content of one logical controller unit. The views/surveys files now have the content for each action. We group them in the action to logical groups that always look the same. We have a title, the breadcrumbs and then we have a unit for each form.

          text: :defaults.surveys
            text: :defaults.surveys
              placeholder: 'Search surveys...'
                text: 'Search'
                label: 'Topics'
                  placeholder: ''
                label: 'Title'
                  placeholder: ''
          text: :views.defaults.search
          disable_with: :views.defaults.form.searching

The problem with a solution like that is, that you have lots of redundant data. Take breadcrumbs for example. In each views folder there are different actions that have the same breadcrumb navigation. But there is a nice feature that you can use for that:

We put all business dependend locals into the defaults or views/defaults folders and reference them with e.g. :defaults.surveys. That makes it easy to have on each page every element, that can be translated to each language, but also removes redundant translations. But if you come to a language that make it harder to translate everything with the same translation you can translate that one separately!! Which can be quite important for example for languages like chinese.

5 Replies to “I18n Rails – How to organize your locales in larger projects”

  1. I suggest taking a look at the documentation for i18n in Rails to learn more about its features and creative uses. This article is more about how to better manage your locales and really only scratches the surface of what you can do with i18n.

    1. Yes it is enough.
      The form_for helper will access the activerecord attributes scope for the given model and pull the right translation.
      You can call this translations with Model.human_attribute_name(:attribute) if you want to translate normal input tags or just use the translation elsewhere.

  2. Hi there!

    Awesome post, mate – one question: Where exactly did you find that fancy “reference-a-defined-value-by-symbolizedkey-feature” – i.e. stuff like ‘:views.defaults.search’ or “:views.defaults.form.searching” – it works, is nice and clear – but I couldn’t find it in any docs?



Leave a Reply

Your email address will not be published. Required fields are marked *