Internationalization is an important topic for many corporations that have a multi-national client base. It allows for easy translation capabilities and helps to protect the future of the application against code debt. However, even if you are not providing translations for your application you can still use internationalization to dry up your content. Let's get started.
What is internationalization?
Internationalization or (I18n from now on), helps to provide translatable text files in the form of yaml inside the
config/locales/ folder. To start your rails application will most likely have something like
en.yml. This allows you to create key value pairs to be used for the English language. The power with I18n is the keys specified can then be matched to another language file as long as the key name corresponds appropriately.
Note: I18n is an abbreviation for internationalization as well as the class name in Ruby.
For example you could have a Russian translation file of
ru.yml with a matching key that provides the russian translation as the key. Here it is in code format (Please forgive my Russian translation as I don't speak Russian and had to use Google translate)
Now anytime a locale change is detected by the Rails app it will switch internationalization files. You can simulate this action in the browser by using a querystring with the locale filename like this
Why should I use this if I don't plan on translating anything?
I'm glad you asked that. While using I18n for a site that doesn't require a translation seems like extra work at first it does lead to some good coding practices with keeping your application DRY. First lets talk about how you use I18n before I show you the benefits of it.
You can utilize your translation files by using the following methods:
I18n.t('key.name.goes.here') for Models and
t('the.period.represents.the.colon.from.the.yml.file') for Controllers and Views.
Simplified: By placing these methods in your code you are essentially telling Rails, "Please print the value associated with this key based on my current locale".
The benefit on small applications
Take a look at the following controller code.
(Sample property of RailsApps)
So what's wrong here?
There is a lot of duplication in the code. For the purpose of this article just focus on the fact that the line
:alert => "Access Denied." appears four times.
Note: There are many other optimizations that could be accomplished including moving duplicate logic into a single method.
Now multiply that across even a small app and you might have something like 20 instances of the exact same text. What happens if the client wants you to change "Access Denied" to "I'm sorry dave, but I'm afraid I can't do that". You better be ready to do a project wide find and replace on your code because you are going to need to change it 20 times!
However, by using I18n we can significantly cut down on our code debt and future proof your application. Now the above code of
:alert => "Access Denied" will become
:alert => t('user.alert.access_denied'). Here is what the en.yml file looks like
Now when the client request comes in you can simply change your en.yml file to this.
Viola, you just changed 20 different instances of the exact same content from a single location. Bravo!
The only downside to this method is that you need to type a little more code to display the content. However, even though
"Access Denied" is less typing than
t('user.alert.access_denied') by using I18n to dry out your code, it will allow you to have a singularly defined location for content. I don't know about you but changing code in one place vs 20 is a big time saver.
- I18n provides a single location to update content. This reduces code debt.
- The code is slighly longer
:alert => "Access Denied"vs.
:alert => t('users.alert.access_denied')
- Models use
- Controllers and Views use
- Internationalization files are stored in
Join the conversation