CSC/ECE 517 Fall 2013/ch1 1w18 bs

Internationalization in Rails

Introduction

In general when we start a conversation, the first default language of communication we use is English, but if the other person is not familiar with English we try and translate our dialogue in a language that the person is familiar with. Similarly whenever we write a program or a document we write it in English by default. But what if someone who is not familiar with English wants to read your program or code? The simple solution is that we translate program or code into a language that the person is familiar with. And for this, we use a term called internationalization.

Internationalization is a way by which we can view an application in various languages without actually making changes to the code of the application. This saves us a lot of time and effort, as we don’t have to write or edit the same code or document in all the copies.

Internationalization has an acronym, rather more of a numeronym ,which is i18n where the number 18 represents the number of letters between the first and last letters in the word internationalization.

Aspects to consider in Internationalization

Now when we are to change our application according to a particular language or a region , we need to keep in mind numerous points that are important, implicit, particular or sensitive to that language or region. Like for example when we take a language into consideration for which our application needs to be translated, we need to consider the spoken and written aspects of that language. Also, there might be a case when we have the same language but it differs from one region to other. For this we need to keep in mind the typical change in the use of words, grammar and symbol for each region that uses the same language. Our application must also provide support for the varied writing conventions that differ from a language to another language or from one region to another.

Below are the examples of the points we need to keep in mind while we provide internationalization to our application :

• Language :

Here the i18n support to an application needs to provide the character encoding keeping in mind the following points:

1. The written language differs. For example most of the languages like English, French, German follow a script that can have inputs from a standard keyboard. But there are other languages like Hindi, Marathi, Sanskrit that follow a script called Devnagri and this cannot be directly typed in from a standard keyboard. So if we have to provide support for these languages we need to support the translation of the characters used in these scripts.
2. The way we write also differs and needs to included in our i18n support. For example most of the languages follow a left-right direction while writing but some languages like Urdu tend to follow a right-left direction.
3. The numbering symbols also vary from language to language. So when we display or accept any text with numbers, we must have i18n to support this mapping.
4. The languages also differ in the use of grammar and structure of the sentences.For example the grammar rules and structure formation in English is way different than the one followed by another language like Sanskrit.

• Culture and Writing Conventions:

Even if the language with the same characters and grammar is used, the use of the language , the symbols , the way of writing and many other things change with change in the region.

Following are some of the examples:

1. There are some cultures that have some regulations about having a middle name as father’s name but other cultures don’t necessary include the middle name.
2. There might be cases when there are different names or terminologies used in different cultures for the same purpose. For example, to identify a citizen uniquely US has the system of SSN while India is in the process of implementing this by using the term as Aadhar number.
3. Another example of difference in the writing convention can be taken as that of a postal code. Some countries have 6 digit postal codes while others have 5.
4. There is a difference in the use of many other things like the currency(like INR,dollars,Euro) used, the symbols(€,$,₹) used , the units in which the weights , temperature are measured. Another example could be the use of lakhs , crores for mentioning any financial figures in some countries while others use millions, billions.
5. There could also be a difference in the formats used for a same thing. For example the format of writing dates and times vary from one region to another.

• We also have to be careful that we cover all the sensitive topics and issues particular to a language or region.

Similarly there are many other factors that we need to take care of when we support internationalization for a particular language in a particular region.

Internationalization in Rails

Internationalization support was extended from Rails version 2.2. So in order to internationalize a rails application, it has to be migrated :to Rails 2.2 or above. Every static string in the Rails framework — e.g. Active Record validation messages, time and date formats — have :been internationalized.

Following needs to be done in order to internationalize a rails application:

1. Ensure support for internationalization by migrating to appropriate version of rails if needed.
2. Tell rails where to find the appropriate translations files
3. Tell rails how to switch locales

YAML (.yml) or plain Ruby (.rb) files are used for storing translations.

History

Ruby 2.2	Internationalization support was extended from this version of Rails.
Ruby 2.3	Additional feature for Localized Views was added in this version. The view files were rendered with an extension of the locale name.I18n#available_locales and I18n::SimpleBackend#available_locales is available to retrieve an array of available locales.
Ruby 3.0	Some additional features were added to the I18n gem for speed improvements like default translations for attributes,automatic pull for translations on form submit, etc.
Ruby 3.1	I18n namespace lookup support removed.

Ways to configure Internationalization in Rails

We can set up a rails application to support internationalization in a number of ways. Below are the various ways to configure our rails application for internationalization.

1. Configure the I18n module:
   Rails adds all .rb and .yml files from the config/locales directory to your translations load path, automatically. This is the default setting provided by the I18n gem. In order to override this setting we have to make changes in the application.rb files that have instructions on how to add locales from another directory and how to set a different default locale.
2. Custom I18n Configuration Setup:
   Optionally, the above code can be placed anywhere in the application preferably in initializers.
3. Setting and passing locale:
   The above two steps help setup a default locale throughout the application. But in case we have to provide our application in different languages, we can setup the application default locale in the application.rb and then set the locale using the application-controller.rb before_action. We can then pass the locale we want as a query param for example http://study.com/books?locale=es
4. Setting the locale from the domain name:
   Similar to option 3 but instead of passing the locale as a query param, the locale is a part of the domain name itself. Example http://study.es

You can implement it like this in your ApplicationController before_action

1. Setting the locale from the URL params:
   
   1. This can be a tedious task as we have to pass the locale on each request.
   2. Rails provides us an alternative for "centralizing dynamic decisions about the URLs" in its ApplicationController#default_url_options and helper methods are dependent on it (by implementing/overriding this method). This will now automatically include the locale param in the query string
   3. We can also set the locale in the URL route. For example -http://study.com/es/books .This is achievable by using over-riding default_url_options. You just have to set up your routes with scoping option in routes.rb.
2. Setting the locale from client supplied information:
   This can be done in 3 ways
   1. Using the default locale of the client browser
   2. Using client location to select the locale
   3. Saving the users choice of locale as a part of user profile

Internationalizing Rails application

After your application is prepared for internationalization, we need to use the feature in our application.

This can be done in the following ways:

1.Adding Translations:
In order to internationalize rails code, replace the strings with calls to the ‘t’ helper.
For example:

class HelloWorld
def sayHello
puts t(:hello_world)
end
end
or
<%=t :hello_world %>
The helper method t also catches missing translations and displays appropriate error message.

# config/locales/en.yml
en:
hello_world: Hello world!

# config/locales/es.yml
es:
hello_world: hola mundo

2.Passing variables to translation:
You can use variables in the translation messages and pass their values from the view.

en:
portal: "Mypack"
university:
ncsu:
description: ! 'NCSU student information is accessed on %{portal_name}’

t('.description', portal_name: t(‘portal’))

3.Adding date/ time formats:

OK! Now let's add a timestamp to the view, so we can demo the date/time localization feature as well. To localize the time format you pass the Time object to I18n.l or (preferably) use ‘l’ helper. You can pick a format by passing the :format option — by default the :default format is used.

In the view file:

<%= l Time.now, format: :short %>

In the yml file:

es:
 time:
   formats:
     short: " Son las %H"

4. Inflection rules for locales other than english Rails 4.0 provides a feature to define inflection rules (singularization and pluralization) in config/initializers/inflections.rb.

5. Localized views For static websites available in different languages or for large static content, localized views is a useful feature. This feature enables having separate view file for different locales. For example for default locale we can have show.html.erb file while for Spanish we can have show.es.html.erb. Thus we don’t need to maintain long .yml files for each supported locale for long static pages.