Skipping the Basics…
Anyone wanting to develop a truly internationalized application needs to address translating the text of the app into the supported languages. Fortunately for you Rails devs out there, the framework provides an easy mechanism for managing and performing those translations, I18n.translate or shortly I18n.t being the forefront. I am just going to mention the basics here and then move right on to some of the more fun features of Rails translations that every Rails ninja needs to know.
So we all know how to do basic translations:
Now some things you may not know about.
When you do translations you don’t have to try to hack together interpolated strings using
ActiveSupport#pluralize. Pluralizations are baked right in.
As a general rule, I avoid putting HTML markup in a translation string. HTML markup should be in the view where it belongs. However, despite my best efforts, sometimes it is unavoidable - which is okay in certain situations. Furthermore, sometimes the variables passed into a translation will contain HTML markup. The default strategy in this situation that I have seen is to use
html_safe. While this does the job, it adds unnecessary method calls when the HTML safe-ification can be handled directly by I18n using the
Though you do receive the added benefit of avoiding unnecessary
html_safe calls, the real winner here it that by being explicit in the locale file, you tell any other developers looking at it which strings are expected to have HTML. Easy win for visibility and communication.
Watch Out for yes/no!
This is a weird one. I am actually not sure why this happens, and would appreciate if anyone can shed some light on the underlying reason for this. If you try to use the key “yes” or “no,” I18n.t will not be able to find it.
Only solution I know is just to not use “yes” or “no” as keys, which is not ideal if you are adding a translation for those exact words.
Literal Naming FTW
It can be quite tempting to use semantic keys in your locale YML files. I see things like “title,” “introduction-1,” or “header-text.” While this will work fine, I prefer to use literal keys that reflect the actual content of the translation (in the default locale) so my views are easier to read for myself and other developers.
That’s all for now! Most of this plus everything else you wanted to know about i18n can be found in the Rails Guides.
Bye! Adios! Adieu! Aloha!