1

Let offers be a folder in app/views. The locale is:

en:
  offers:
    index:
      ...
    new:
      ...

i.e. I follow the Rails convention so that I can use t('.something') in views.

The problem is that I store global translations like this:

en:
  a_global_key: A Global Translation

So when I want to translate offers I would like to add:

en:
  offers: Offers

But this generates a collision with the previously defined view namespace.

I know I can avoid this by simply using a namespace like globalfor global translations. Then I would always have to write t(global.a_global_key) instead of the more concise t('a_global_key).

Is there a Rails way to structure locales that prevents collision between global translations and view namespaces?

It would be great to be able to write something like the following invalid YAML:

en:
  offers: Offers
    index:
      ...
    new:
      ...
collimarco
  • 34,231
  • 36
  • 108
  • 142
  • 1
    There's an argument to be made for using an explicit namespaced i18n architecture, rather than a cryptic one. This post's most popular answer describes a i18n architecture that is logical and maintainable: http://stackoverflow.com/questions/10282857/how-do-you-structure-i18n-yaml-files-in-rails?rq=1 – Elvn Jun 06 '15 at 15:26

0 Answers0