Rails I18n – Seven Best Practices That You Should Know About

Rails Internationalization (I18n) - Seven Best Practices That You Should Know About
available_locales() returns an array with symbols, so here we convert them to strings and then
check whether the requested language code was found inside. You can read more on this
technique at our ​Setting and Managing Locales in Rails I18n​ article.
Utilize Localized Views
Some developers tend to place all translations inside the YAML files regardless of their length
and complexity. In some cases, however, that’s not really convenient. Suppose you have a page
that looks totally different depending on the chosen language. Of course, you ​might do
something like this:
1
2
3
4
5
Then you would have to define these keys, but the corresponding messages are too large:
1
2
3
welcome: 'Welcome!'
special_offer: 'Here is our cool special offer! And then more text here...'
about: 'Long text goes here.... and more text... even more...'
Alternatively, you may take advantage of ​HTML translations but that’s not going to help a lot –
you still have long messages that are hard to maintain.
What you can do instead, is stick with the ​localized views that allows you to store totally
different content for each locale. They are employed by simply prefixing your views with the
locale’s code, for example ​about.ru.html.erb and ​about.en.html.erb​. Rails will render the proper
view automatically depending on the value returned by the ​I18n.locale()​ method.
phraseapp.com | sales@phraseapp.com | +49-40-357-187-76 | twitter.com/phraseapp | facebook.com/phraseapp | linkedin.com/company/phraseapp