I18n - Internationalization

Resources:

• http://guides.rubyonrails.org/i18n.html
• https://github.com/svenfuchs/rails-i18n

At what point & how should i18n be integrated

To put all your app’s strings into i18n .yml files is actually mostly a good idea. It’s not that much more effort and it makes it easier for the client to change wording and can also improve the stability of tests. So it even makes sense for single language applications.

However, you should be very careful about introducing locales. Every new locale introduces new complexity (language switching, fallback rules, etc.) and we should try to stay with as few locales as possbile (ideally only one), for as long as possible. Don’t just create another locale from the start “because we will need it at some point anyway”.

Also, don’t introduce more than one locale per language, e.g. en_GB, en_US. Unless the client has super important reasons, this is usually not worth the extra effort/complexity at least in the beginning. Try to stick with Rails’ simple 2-letter locales: en, de, fr, …

How to pick good i18n string keys

1) Use the activerecord. namespaced keys for **all model names, attributes and errors!**

en:
  activerecord:
    models:
      user: Dude
    attributes:
      user:
        login: "Handle"
    errors:

For more information see: http://guides.rubyonrails.org/i18n.html#translations-for-active-record-models

2) Use “lazy-lookup” based on the current view/partial scope

http://guides.rubyonrails.org/i18n.html#lazy-lookup

This makes your view code cleaner and it’s pretty clear which i18n key belongs to which part of the app. The only downside of this approach is that you might need to move around keys, when you refactor your views. But this is only a problem when you have a lot of locales and are using WTI (because you loose translations, when the key changes).