When translating software, it is particularly important to pay attention to native language usages. Many linguistic services call this type of service localization or “L10n“. Mobile and Web-based programs represent some of the newest and most innovative software. However, in order to compete globally, software vendors need to internationalize products. After all, writing up a beautiful piece of code that is optimized for native English speaking users, automatically removes over 50 percent of the software market from your potential customer base. Those for whom English is a second language have difficulty using software without a native language option. Localization is a necessary part of optimizing the User Experience. The “side effect” of doing so, is maximizing profits.
Why is Localization Important vs. Basic Text Translation?
Localization takes into account colloquial terminology. Translation is often very literal. In fact, with “machine translation”, the results are so literal as to be unusable in many instances. In one example, when a company tried to use machine translation for a restaurant sign, the result was an error message. Not speaking the target language, the text for the error became the company’s translation. Even traditional translation returns results that confuse locals. For example, when translating “Like father, like son,” to Chinese, a translator might go literal, however, the more correct phrase would re-translate from Chinese as “Tigers do not breed dogs.” An expert translator who specializes in software localization will use the most correct translation and not a literal transliteration from language to language. A good example of how important that can be, even within the same language, is using ‘flat’ rather than ‘apartment’ when marketing real estate management software in the UK. That one word change can make the difference between a first page result on a search engine and a tenth page result.
Offer Software in Customers’ Native Languages for Optimum Sales
Maximizing sale potential is all about providing a user-friendly software package that offers value to the customer. If developers do not make the product available in the customers’ native language, they are unlikely to buy. Even skilled English speakers have trouble reading the language fluently, particularly if their native language uses a different alphabet. Customers want easy to use and intuitive products. Software localization is a necessary step to achieve that. If developers don’t rise to challenge, they stand to lose out on a huge percentage of the market. English may make up 70 percent of the software market today, but with “developing nations” increasing their Internet penetration every day, that is likely to change in the next years. Go native and deliver that great product your customers deserve.
The I18n ruby gem comes with backend support for resource files (more specifically .yml files). Additionally, it also provides simple approach to exchange the backend implementation using different gem/plugin depending on your requirements. Let’s examine an example where all translations are stored within database.
Using Database backend for Ruby I18n API
You can easily use your database for storing all the translations with the help of i18n_backend_database (https://github.com/dylanz/i18n_backend_database) plugin. This plugin will store all your translations in the database instead of YAML files and provides a caching mechanism, so that the database doesn’t get hit for every translation. When you tag items using i18n.t() within the code base, all of untranslated items will be noted as well as added into the database. You can translate untranslated textual content through an administrator panel provided by plugin.
Update 2011-02-01
Please note that this plugin is not yet ready for Rails 3 (see comments). Here are the steps to use this plugin for Rails 2.x:
Add this lines in config/initializers/i18n.rb
In config/routes.rb register admin panel routes
Now, rails application can translate all the code from the database. All non-user generated text provided by the application needs to be wrapped in a call to I18n.t().
Interpolation is handled by passing in key/value pairs as a value to an interpolation tag ( {{ }} ).
Translating Routes with translate_routes Gem
The Ruby gem translate_routes helps you to translate URLs to any number of different languages, even for an already working application. This gem works with Rails 3.x. and also with other Rails versions like 2.1.x, 2.2.x and 2.3.x. The Ruby gem translate_routes is working good with all type of routing definitions, which includes RESTful as well as named routes. You don’t have to change your existing routing code, helpers, and so on; links work as expected – even in your tests.
Add translate_routes to your Gemfile:
And let bundle do the rest: bundle install
1) Let’s say you have this in your routes.rb file:
You can see the available routes with the ‘rake routes’ task:
5) Include this filter in your ApplicationController:
Now your application recognizes the different routes and sets the I18n.locale value in your controllers. But what about the routes generation? As you can see in the previous rake routes output, the contact_es_es_path and contact_en_us_path routing helpers have been generated and are available in your controllers and views. Additionally, a contact_path helper has been generated, which generates the routes according to the current request’s locale.
This means that if you use named routes, you don’t need to modify your application links because the routing helpers are automatically adapted to the current locale.
6) What about tests?
Of course, functional and integration testing involves some requests. The plugin includes some code to add a default locale parameter so they can remain untouched. Append it to your test_helper and it will be applied.
The Ruby gem Globalize2 was very popular in Rails community because it provides full-fledged internationalization solutions for Ruby on Rails application. You can use most of the features/tools independently and also you can combine them with other libraries or plugins.
The Feature/Tools for this gem are listed below.
Model translations – This functionality transparently translates ActiveRecord data
Locale LoadPath – This gem load translation data from standard locations enforcing conventions that suite your needs
Locale Fallbacks – This feature make sure your translation lookups fall back transparently through a path of alternative locales that make sense for any given locale in your application
Translation value objects – You can access useful meta data information on the translations returned from your backend and/or translated models
Conclusion
The I18n API comes with plenty of features and yet hides the complexity behind a simple to use API. With this gem, a Ruby on Rails application has a great built-in support for multiple languages. As the diversity of users is growing and more and more users speak different languages, a good localization and internationalizationsupport is necessary for every serious Web Framework. If your application has a more specific need, have a look at the various plugins and extensions available. Rails has also a great documentation, and of course there is an Internationalization section, I18n Wiki.
Whenever we hear about Internationalization of web application, the first word that comes to our mind is “Translation“. There are three ways to translate software:
Do it Yourself
Pay Someone for doing Translation
Ask your Users
No matter what, making the software ‘Internationalization ready’ is the developer’s job. No static strings, dates in the code and so forth; every text must be put in resource files and the code decides which text to use. Luckily Ruby on Rails provides a simple ruby gem called “I18n” (internationalization) that does exactly that.
Definition of Internationalization & Localization :
First of all let’s check the definition of Internationalization & Localization. According to Wikipedia,
i18n – “Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.” This means, the “Internationalization” functionality translates all string and other locale specific information ( like date and currency formats) from your application in desire language to end user.
l10n – “Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text.” This means, the “Localization” functionality gives translations in local-specific language and other localized formats for local specific information.
How i18n mechanism works in Rails :
All the languages are different from each other in many ways (For example pluralization rules). It is very difficult for any tools/software to provide a general solution for language translation. To solve this problem I18n API provides two features in Ruby on Rails.
Give support for English and other similar languages out of the box
Provide a user-friendly and adjustable functions for supporting other languages
This means in Ruby on Rails every static string has been internationalized and you can “over-ride” these defaults with “localization” of the application.
There are two parts of Ruby I18n gem which are:
The public I18n API – provides a Ruby module with public methods to characterize the work of the library
A default backend – which executes these public methods
The Public I18n API comes with two most important methods which are:
translate # This public method do translations of the text
localize # This public method localize Date and Time objects to local formats as per settings
These method have aliases #t and #l respectively, so you can use them like this:
Setup/Configuration about the i18n mechanism
You can easily setup ruby I18n gem with few simple steps and use in your application for I18n support. Ruby on Rails application set up reasonable defaults in all .rb and .yml files in config folder. If you want to change the settings, you can easily change them according to your need.
To check the defaults for I18n module you have to check config/locales directory, which is default path for translation.
You will get one file named en.yml which default locale and contains these translation strings:
English is default locale in I18n library. So, if your application is not set in different locale, :en will translate all the static text changes.
So, when you check this on console the output shows like following :
Some other available locales which are supported by rails 3 are:
The easiest method to set your own locales to override the default locale is to change config/application.rb file in Rails 3. (You can apply same settings to config/environment.rb in Rails 2). Add this line to get German language as default locale:
The first line of code tells the location of translation file to the I18n library. The second line of code will set the default locale to :de other than :en.
Using the I18n module
Put these lines in config/locale/de.yml.
Let’s check now whether this settings translate “hello” into “German” locale or not.
Using the I18n with interpolation
Most of the time you want to use various variables with your translations. That’s why I18n API also provide interpolation feature.
Using the I18n with pluralization
In English there are only one singular and one plural form for a given string, e.g. “1 friend” and “2 friends”. The best thing is I18n API also provides a flexible pluralization feature in Rails applications.
We must note that an interpolation variable named :count plays key role in translation and pluralization.
The algorithm for pluralization is:
I.e. here 1 denotes singular and 0 denotes plural. So as specified using conditional operator, if count == 1, it will consider it as singular form otherwise its plural.
That’s it for Part I. In Part II we will check other features of I18n like
Localization of Times/Dates
Using views for translation
Translating ActiveModel errors
Organization of resource files
Setting the locale (from domain, parameter or client) and of course storing it in the database when the user is logged in
Not speaking the target language, the text for the error became the company’s translation. Even traditional translation returns results that confuse locals. For example, when translating “Like father, like son,” to Chinese, a translator might go literal, however, the more correct phrase would re-translate from Chinese as “Tigers do not breed dogs.” An expert translator who specializes in software localization will use the most correct translation and not a literal transliteration from language to language. A good example of how important that can be, even within the same language, is using ‘flat’ rather than ‘apartment’ when marketing real estate management software in the UK. That one word change can make the difference between a first page result on a search engine and a tenth page result.
