All features

Quality Checks

Term Base

Translation History

Translation Memory

Style Guide

Translation Team Management

Professional Translation

Machine Translation

Features

For managers

For translators

For developers

For designers

For enterprises

Solutions

Help Center

Blog

Case Studies

Integrations

Resources

Pricing

Demo

Book a demo

Navigation Bar

Our goal is to provide you with in-depth knowledge regarding localization.

Learn how CMS localization can boost your online presence, expand your reach, and optimize for international success with our informative article.

CMSs: industry state and how to localize them best

Newsletter Sign Up

Localization Blog

In July we published a series of articles on internationalization for PHP, this month we will focus on tutorials about internationalization for Ruby, starting out with a comprehensive tutorial on getting started with the <strong>i18n gem</strong> and various frameworks. If you missed any of the prior articles, you can have a look here: <ul> <li><a title="Permalink to PHP internationalization – i18n mechanisms tutorial" href="https://lingohub.com/blog/2013/06/php-internationalization-i18n-mechanisms-tutorial" rel="bookmark">PHP i18n mechanisms</a></li> <li><a title="PHP internationalization with gettext tutorial" href="https://lingohub.com/blog/2013/07/php-internationalization-with-gettext-tutorial" rel="bookmark">PHP i18n with gettext</a></li> <li><a title="Internationalization How To for the 5 most popular PHP frameworks" href="https://lingohub.com/blog/2013/07/internationalization-how-to-5-most-popular-php-frameworks" rel="bookmark">i18n in 5 most popular PHP frameworks</a></li> <li><a title="PHP internationalization frameworks: Laravel and FuelPHP" href="https://lingohub.com/blog/2013/07/php-internationalization-frameworks-laravel-fuelphp" rel="bookmark">i18n in Laravel and FuelPHP</a></li> </ul>

Localization and Internationalization are recurring themes in our blog posts, if you are not 100% sure what they refer to, you can find an explanation in <a href="https://lingohub.com/blog/2013/07/what-is-localization">this article</a>.

For August, we have prepared a series of articles, and to start out we will demonstrate how internationalization can be achieved in the <strong>Ruby</strong> world. Ruby is a dynamic, reflective, general-purpose <a href="http://en.wikipedia.org/wiki/Object-oriented_programming" rel="nofollow" target="\_blank">object-oriented programming</a> language that combines syntax inspired by <a href="http://www.perl.org/" rel="nofollow" target="\_blank">Perl</a> with <a href="http://www.squeak.org/Smalltalk/" rel="nofollow" target="*blank">Smalltalk</a>-like features. It was also influenced by <a href="http://en.wikipedia.org/wiki/Eiffel*(programming_language)" rel="nofollow" target="*blank">Eiffel</a> and <a href="http://en.wikipedia.org/wiki/Lisp*(programming_language)" rel="nofollow" target="*blank">Lisp</a>. Ruby was first designed and developed in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan. \[<a href="http://en.wikipedia.org/wiki/Ruby*%28programming_language%29" rel="nofollow" target="_blank">1</a>\]

The topics covered in this article are: <ul> <li><a href="#i18n-ruby" rel="nofollow" target="_blank">i18n for plain Ruby</a> & the i18n gem</li> <li><a href="#i18n-ruby-on-rails" rel="nofollow" target="_blank">i18n for Ruby on Rails</a></li> <li><a href="#i18n-sinatra" rel="nofollow" target="_blank" >i18n for Sinatra</a></li> <li><a href="#i18n-padrino" rel="nofollow" target="_blank">i18n for Padrino</a></li> </ul>

Since the emergence of web application frameworks like Ruby on Rails and DSL-s like Sinatra, Ruby has been used to reach a wide international public. Early in August 2013, there were nearly 200.000 websites world-wide using Ruby on Rails \[<a href="http://trends.builtwith.com/websitelist/Ruby-on-Rails">2</a>\] alone. There is no better way of reaching a wide international audience then in their own individual languages, and this series of articles will show you how. Let's start with the basics and then we will move on to the details.


## Internationalization for Ruby: The Ruby i18n gem

One of the most popular Ruby gems for internationalization is <a href="https://github.com/svenfuchs/i18n" rel="nofollow" target="_blank">Ruby I18n</a>. It allows translation and localization, interpolation of values to translations, pluralization, customizable transliteration to ASCII, flexible defaults, bulk lookup, lambdas as translation data, custom key/scope separator, and custom exception handlers.

The gem is split in two parts: the public API and a default backend (named Simple backend). Other backends can be used, such as Chain, ActiveRecord, KeyValue or a custom backend can be implemented.

<strong>YAML</strong> (.yml) or plain Ruby (.rb) files are used for storing translations in SimpleStore, but YAML is the preferred option among Ruby developers.

## Internationalization and the YAML resource file format

<a href="http://en.wikipedia.org/wiki/Yaml" rel="nofollow" target="_blank">YAML</a> is a human-readable data serialization format. Its syntax was designed to be easily mapped to data types common to most high-level languages (lists, associative arrays and scalars). Unlike some other formats, YAML has a <a href="http://yaml.org/spec/1.2/spec.html" rel="nofollow" target="_blank">well defined standard</a>.

Key features of YAML resource file format are: <ul> <li>the information is stored in key-value pairs delimited with colon ( : )</li> <li>keys can be (and usually are) nested (scoped)</li> <li>i18n expects the root key to correspond to the locale of the content, for example 'en-US' or 'de'</li> <li>the "leaf key" (the one that has no "children" keys) has to have some value</li> <li>values can be escaped</li> <li>correct and consistent line indentation is important for preserving the key hierarchy</li> <li>lines starting with a hash sign ( # ) preceded with any number of white-spaces are ignored by the parser (treated as a comment)</li> <li>place-holder syntax is: %{name}, where “name” can consist of multiple non-white-space characters</li> <li>UTF-8 encoding is usually used for YAML resource files</li> </ul>

Before we move on to demonstrate the I18n methods, lets first create an example yaml file that we will load and test:

[GIST](https://gist.github.com/6231162.git)


## Installation and setup


After the gem installation, change the directory to the location where the sample yaml file was saved and start the <strong>irb</strong> (<a href="http://en.wikipedia.org/wiki/Interactive_Ruby_Shell" rel="nofollow" target="_blank">interactive ruby shell</a>). The first step is requiring the library:

<pre>2.0.0p247 :001 > require 'i18n'  => true</pre>

Next, we can check the current <a title="How locales turn the Internet into a global village" href="https://lingohub.com/blog/2013/02/how-locales-turn-the-internet-into-a-global-village">locale</a>. By default, it is English.

<pre>2.0.0p247 :002 > I18n.locale  => :en</pre> Changing it to something else is easy: <pre>2.0.0p247 :003 > I18n.locale = :de  => :de</pre>

## Translation lookup

Translation lookup is done via the translate method of I18n. There is also a shorter alias available: <strong>I18n.t</strong>. Let's now try to <em>lookup</em> one of the phrases from our yaml file example:

<pre>2.0.0p247 :004 > I18n.translate :world, :scope => 'greetings.hello'  => "translation missing: en.hello.world"</pre>

The translation is missing, because we have not loaded the file. Lets load all the .yaml and .rb files in the current directory:

<pre>2.0.0p247 :005 > I18n.load_path = Dir\['./*.yml', './*.rb'\]  => \["./en.yml"\]</pre>

and then we retry accessing the English translation with the key 'world':

<pre>2.0.0p247 :006 > I18n.translate :world, :scope => 'greetings.hello'  => "Hello world!"</pre>

When we asked for this translation, we did not pass any locale, so I18n.locale was used. A locale can be explicitly passed:

<pre>2.0.0p247 :007 > I18n.translate :world, :scope => 'greetings.hello', :locale => :en  => "Hello world!"</pre>

When passing the phrase key, a symbol or a string can be used, and a scope can be an array or dot-separated. Also all combinations of these are valid, so the following calls are equivalent:

<pre>I18n.translate 'greetings.hello.world' I18n.translate 'hello.world', :scope => :greetings I18n.translate 'hello.world', :scope => 'greetings' I18n.translate :world, :scope => 'greetings.hello' I18n.translate :world, scope: \[:greetings, :hello\]</pre>

When a :default option is given, its value will be returned if the translation is missing. If the <code>:default</code> value is a symbol, it will be used as a key and translated. Multiple values can be provided as default. The first one that results in a value will be returned. For example, the following first tries to translate the key :missing and then the key :also_missing. As both do not yield a result, the string "Not here" will be returned:

<pre>2.0.0p247 :008 > I18n.translate :missing, default: \[:also_missing, 'Not here'\] => 'Not here'</pre>

Variables can be interpolated to the translation like this:

<pre>2.0.0p247 :009 > I18n.translate :user, :scope => \[:greetings, :hello\], :user => 'Ela'  => "Hello Ela!"</pre>

To look up multiple translations at once, an array of keys can be passed:

<pre>2.0.0p247 :010 > I18n.translate \[:world, :friend\], :scope => \[:greetings, :hello\]  => \["Hello World!", "Hello Friend!"\]</pre>

Also, a key can translate to a (potentially nested) hash of grouped translations: <pre>2.0.0p247 :011 > I18n.translate :hello, :scope => \[:greetings\] => {:world=>"Hello World!", :user=>"Hello %{user}", :friend=>"Hello Friend!"}</pre>

## Pluralization options in internationalization for Ruby

In English there is only one singular and one plural form for a given string, e.g. "1 message" and "2 messages". Other languages (<a href="http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html#ar" rel="nofollow" target="_blank">Arabic</a>, <a href="http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html#ja" rel="nofollow" target="_blank">Japanese</a>, <a href="http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html#ru" rel="nofollow" target="_blank">Russian</a> and many more) have different grammars that have additional or fewer <a href="http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html" rel="nofollow" target="_blank">plural forms</a>. Thus, the I18n API provides a flexible pluralization feature.

The :count interpolation variable has a special role in that it both is interpolated to the translation and used to pick a pluralization from the translations according to the pluralization rules: <pre>2.0.0p247 :012 > I18n.translate :messages, :scope => :inbox, :count => 1 => "You have one message in your inbox." 2.0.0p247 :013 > I18n.translate :messages, :scope => :inbox, :count => 39  => "You have 39 messages in your inbox."</pre>

The algorithm for pluralizations in <code>:en</code> is as simple as: entry\[count == 1 ? 0 : 1\]. The translation denoted as '<code>one'</code> is regarded as singular, the 'other' is used as plural (including the count being zero).

## Setting up date and time localization

To localize the time format, the Time object should be passed to I18n.localize. A format can be picked by passing the :format option — by default the :default format is used.

<pre>2.0.0p247 :014 > I18n.localize Time.now  => "Wed, 14 Aug 2013 13:34:49 +0200" 2.0.0p247 :015 > I18n.localize Time.now, :format => :short  => "14 Aug 13:34"</pre>

Instead of I18n.localize, a shorter alias can be used: <strong>I18n.l</strong>.


## i18n - the default internationalization solution for Ruby on Rails


I18n is the default internationalization solution for Ruby on Rails and it is localized with the use of the <a href="https://github.com/svenfuchs/rails-i18n" rel="nofollow" target="_blank">rails-i18n</a> gem.

In accordance with the RoR philosophy of <em>convention over configuration</em>, Rails applications come with some <em>reasonable defaults</em> already set.

For example, instead of doing this manually:
<pre>2.0.0p247 :001 > require 'i18n'
2\.0.0p247 :002 > I18n.locale = :en
2\.0.0p247 :003 > I18n.default_locale = :en
2\.0.0p247 :004 > I18n.load_path = Dir\['./\*.yml'\]</pre>
Rails adds all .rb and .yml files from the config/locales directory to translations load path, automatically. The I18n library will use English as a default locale (if different locale is not set, :en will be used for looking up translations).

By default, Rails expects that all the resource files are kept in config/locales. On the other hand, we prefer to keep them organized in the subdirectories that correspond to the locale names. You might find some other mode of organization better suited, for example separating the models localization from the views localization.

Let's change some settings by overriding the defaults in application.rb: <ul> <li>let's organize the resource files in the subdirectories corresponding to locales instead of storing everything in config/locales,</li> <li>set :de as the default locale and</li> <li>:en, :de and :fr as available locales</li> </ul>

<pre>config.i18n.load_path += Dir\[Rails.root.join('config/locales/\*\*/\*.{rb,yml}').to_s\] config.i18n.default_locale = :de config.i18n.available_locales = \[:en, :de, :fr\]</pre>

Rails is localized to numerous locales (meaning, all the static text originating from Rails). For a complete list of available locales and information on missing translations or pluralization, you can check <a href="https://github.com/svenfuchs/rails-i18n" target="\_blank">this page</a>.

For multilingual applications it is necessary to allow the user to change the current locale and to keep track of this choice. The chosen locale can be stored in a session or a cookie, but this practice is not recommended. The reason is, that locales should be <a href="http://www.infoq.com/articles/rest-introduction" target="\_blank">RESTful</a> - transparent and a part of the URL. For example, when a user saves or shares a link to a page that he viewed in a non default locale, visiting that link should show the page in that same locale and not fall back to the default.

The information on the current locale can be passed through: <ul> <li>URL query parameter  ( <em>http://<code>example.com</code>/?locale=sr</em> )</li> <li>URL path  ( <em>http://<code>example.com</code>/sr/</em> )</li> <li>domain name  ( <em>http://<code>example.</code>sr</em> )</li> <li>subdomain name  ( <em>http://<code>sr.example.</code>com</em> )</li> <li>client supplied information</li> </ul>

<h2>Passing the locale as a query parameter within the URL</h2>

If the locale information is passed in the URL as a query parameter, setting the locale can be done in before_action (before_filter prior to Rails 4) in the ApplicationController:

<pre>before_action :set_locale

def set_locale   I18n.locale = params\[:locale\] || I18n.default_locale end</pre>

This requires passing the locale as a URL query parameter<code></code> and adding it to all the links within the application.

Doing this manually ( for example: link_to( books_url :locale => I18n.locale ) ) is not very convenient. Fortunately, Rails comes with a helper method that can be overridden: <a href="http://api.rubyonrails.org/classes/ActionController/Base.html#M000515,%20which%20is%20useful%20precisely%20in%20this%20scenario:%20it%20enables%20us%20to%20set%20%22defaults%22%20for%20%5B%60url_for%60%5D(http://api.rubyonrails.org/classes/ActionController/Base.html#M000503" rel="nofollow" target="_blank">ApplicationController#default_url_options</a>: <pre># app/controllers/application_controller.rb def default_url_options(options={})   { :locale => I18n.locale } end</pre>

As a result, every helper method dependent to url_for (e.g. helpers for named routes like root_path or root_url, resource routes like books_path or books_url, etc.) will now automatically include the locale in the query string, like this: http: //localhost:3000/?locale=sr.

## Passing the locale as a part of the URL path
It is much nicer and cleaner to have the locale information at the beginning of the path instead of the end: <em>http:// localhost:3000/sr/</em> vs <em>http:// localhost:3000/?locale=sr</em>. This is achievable with the "over-riding default_url_options" strategy as previously demonstrated. The routes just need to be set up with the scoping option:


~~~
# config/routes.rb scope "(:locale)", locale: /en|sr/ do   resources :books end

~~~

The use of the optional path scope will allow the locale information to be omitted for the default locale without causing the Routing Error.

<h2>Passing the locale as a domain name or a subdomain</h2>

Setting the locale from the domain name or subdomain makes the locale of the current page very obvious and <strong>search engines</strong> also like this approach.

It is easy to implement it in Rails by adding a before_action to ApplicationController:
<pre>before_action :set_locale

def set_locale
\#extracting from the domain name
  I18n.locale = extract_locale_from_tld || I18n.default_locale

\#extracting from subdomain:
  #I18n.locale = extract_locale_from_subdomain || I18n.default_locale
end

def extract_locale_from_tld
  parsed_locale = request.host.split('.').last
  I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale  : nil
end

def extract_locale_from_subdomain   parsed_locale = request.subdomains.first   I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale : nil end</pre>

<h2>Setting the locale from client-supplied information</h2>

Information other than the page URL can be used to set the appropriate locale for the current user. For example, if the user has saved his preferred locale in the user profile of the web application or web service, after the log in, the current locale can be set:

<pre>I18n.locale = current_user.locale</pre>

Each HTTP request contains information that can also be used, for example the preferred language set in the browser or the geographical information inferred from the IP address.

A trivial implementation of using an Accept-Language header would be:
<pre>def set_locale
  I18n.locale = extract_locale_from_accept_language_header
end

private
def extract_locale_from_accept_language_header
  request.env\['HTTP_ACCEPT_LANGUAGE'\].scan(/^\[a-z\]{2}/).first
end</pre>
For production environments perhaps a more complex <a href="https://github.com/iain/http_accept_language" rel="nofollow" target="_blank">plugin</a> or <a href="https://github.com/rack/rack-contrib/blob/master/lib/rack/contrib/locale.rb" rel="nofollow" target="_blank">rack middleware</a> would be more suitable.

Another way of choosing the locale from client information would be to use a database for mapping the client IP to the region, such as <a href="http://www.maxmind.com/app/geolitecountry" rel="nofollow" target="_blank">GeoIP Lite Country</a>. The mechanics of the code would be very similar to the accept-language example — first the database would be queried for the user's IP, and then the preferred locale looked up for the country/region/city returned.

## Translation lookup and date/time localization with Ruby on Rails

The use of the I18n.translate and I18n.localize methods was described in detail in the previous sections on Internationalization for plain Ruby. In addition to that, Rails adds <strong>t</strong> (translate) and <strong>l</strong> (localize) helper methods to controllers and views so that spelling out I18n.t and I18n.l all the time is not necessary. These helpers will catch missing translations and wrap the resulting error message into a <span>.

<pre>#instead of I18n.translate :hello t :hello #instead of I18n.localize Time.now l Time.now</pre>

## Inflection rules for locales other than english

Rails 4.0 allows you to define <a href="http://en.wikipedia.org/wiki/Inflection" rel="nofollow" target="_blank">inflection</a> rules (such as rules for singularization and pluralization) for locales other than English. In config/initializers/inflections.rb, you can define these rules for multiple locales. The initializer contains a default example for specifying additional rules for English; follow that format for other locales as you see fit.

## Localized views in rails

If there is a view template index.html.erb present in the views directory, it is possible to put a localized variant of this template: index.de.html.erb in the same directory, and Rails will render it when the locale is set to :de. When the locale is set to the default locale, the generic index.html.erb view will be used.

This feature can be useful when working with a large amount of static content.

## Using safe HTML translations in Ruby on Rails

Keys with a '\_html' suffix and keys named 'html' are marked as HTML safe. They should be used without escaping. <pre># config/locales/en.yml en:   welcome: <b>welcome!</b>   hello_html: <b>hello!</b>   title:     html: <b>title!</b></pre> <pre># app/views/home/index.html.erb <div><%= t('welcome') %></div> <div><%= raw t('welcome') %%></div> <div><%= t('hello_html') %%></div> <div><%= t('title.html') %%></div></pre>

The output would be something like this:

<b>welcome!</b> <strong>welcome!</strong> <strong>hello!</strong> <strong>title!</strong>

<h2>Translations for Active Record Models</h2>

Methods Model.model_name.human and Model.human_attribute_name(attribute) can be used to transparently look up translations for model and attribute names. For example when the following translations are added:

<pre>en:   activerecord:     models:       user: Dude     attributes:       user:         login: "Handle"       # will translate User attribute "login" as "Handle"</pre>

The User.model_name.human will return "<a href="http://www.urbandictionary.com/define.php?term=dude" rel="nofollow" target="_blank">Dude</a>" and User.human_attribute_name("login") will return "Handle".

## Error message scopes

Active Record gives a several namespaces for placing message translations in order to provide different messages and translation for certain models, attributes, and/or validations. It also transparently takes single table inheritance into account.

For example, if there is an ActiveRecord model "User" that has the :presence validation for :name, the key for the message would be :blank. ActiveRecord will look up for this key in several namespaces, in this order: <pre>activerecord.errors.models.\[model_name\].attributes.\[attribute_name\] activerecord.errors.models.\[model_name\] activerecord.errors.messages errors.attributes.\[attribute_name\] errors.messages</pre>

If the models are using inheritance, then the messages are also looked up in the inheritance chain.

## Error message interpolation 

The translated model name, translated attribute name, and value are always available for interpolation. So, instead of the default error message "can not be blank" the attribute name could be used like this : "Please fill in your %{attribute}".

For the complete list of available interpolation variables, check <a href="http://guides.rubyonrails.org/i18n.html#error-message-interpolation" rel="nofollow" target="_blank">this link</a>.

## Translations for action mailer e-mail subjects

If a subject is not passed to the mail method, Action Mailer will try to find it in the translations. The performed lookup will use the pattern <mailer_scope>.<action_name>.subject to construct the key. <pre># user_mailer.rb class UserMailer < ActionMailer::Base   def welcome(user)     #...   end end</pre> <pre>en:   user_mailer:     welcome:       subject: "Welcome to Lingohub!"</pre>

## Internationalization for sinatra with i18n gem

<a href="http://www.sinatrarb.com/" target="\_blank">Sinatra</a> can be easily set up to use i18n gem for internationalization:

~~~
require 'i18n' require 'i18n/backend/fallbacks'

configure   I18n::Backend::Simple.send(:include, I18n::Backend::Fallbacks)   I18n.load_path, Dir\[File.join(settings.root, 'locales', '*.yml')\]   I18n.backend.load_translations end
~~~

<h2>Passing the locale</h2>

As previously described for Ruby on Rails, there are several methods of passing the locale information: <ul> <li>Specific urls:</li> </ul> <pre>before '/:locale/\*' do   I18n.locale       =       params\[:locale\]   request.path_info = '/' + params\[:splat \]\[0\] end</pre> <ul> <li>dedicated subdomain:</li> </ul> <pre>before do   if (locale = request.host.split('.')\[0\]) != 'www'     I18n.locale = locale   end end</pre> <ul> <li>browser preference (requires <a href="https://github.com/rack/rack-contrib" target="\_blank">rack-contrib</a>)</li> </ul> <pre>use Rack::Locale</pre>

When the i18n gem is required, the resource file paths set and the locale passed, the pages can be translated and localized with the I18n.t and I18n.l methods, as described earlier in the article. To avoid allways typing the module name in the method calls, a simple helpers can be defined: <pre>helpers do   def t(\*args)     I18n.t(\*args)   end

def l(\*args)     I18n.l(\*args)   end end</pre>

For rendering localized templates, <strong>find_template</strong> method needs to be extended. It needs to select the first template matching the user locale (or at least one acceptable fallback). To help in the selection process templates stored in the views directory are suffixed by the name of the locale. <pre>helpers do   def find_template(views, name, engine, &block)     I18n.fallbacks\[I18n.locale\].each { |locale|       super(views, "#{name}.#{locale}", engine, &block) }     super(views, name, engine, &block)   end end</pre>

<h2 id="i18n-padrino">Internationalization for Padrino with i18n gem</h2>

i18n gem is used as a default internationalization solution for the <a href="http://www.padrinorb.com" rel="nofollow" target="_blank">Padrino</a> framework, and by default Padrino will search for all .yml or .rb files located in app/locale. Localization is fully supported in: <ul> <li>padrino-core (date formats, time formats etc…)</li> <li>padrino-admin (admin language, orm fields, orm errors, etc…)</li> <li>padrino-helpers (currency, percentage, precision, duration etc…)</li> </ul>

So far Padrino itself has been localized to the following languages: Czech, Danish, German, English, Spanish, French, Italian, Dutch, Norwegian, Russian, Polish, Brazilian Portuguese, Turkish, Ukrainian, Traditional Chinese, Simplified Chinese, Japanese.

Translation and localization is done in a similar way as described previously.

Setting the default locale can be done in config/boot.rb:
<pre>Padrino.before_load do
I18n.locale = :en
end</pre>
i18n is simple to use and yet very powerful, it has everything that most developers need. Thanks to that, it has become the most popular internationalization solution in the Ruby world.

I18n in most cases really works practically "out of the box". It is easy to set up and use, and after that, the only thing you'll need is a <a href="https://lingohub.com" rel="nofollow" target="_blank">reliable localization service</a>.

In this article we described the basic use of the i18n gem. The next article in the Internationalization for Ruby series will demonstrate some advanced applications.

<h2>Sources</h2>

<ol> <li><a href="http://en.wikipedia.org/wiki/Ruby\_%28programming_language%29" rel="nofollow" target="_blank">Wikipedia article on Ruby</a></li> <li><a href="http://trends.builtwith.com/websitelist/Ruby-on-Rails" rel="nofollow" target="_blank">List of websites using RoR on builtwith.com</a></li> </ol>

<h2>Further reading</h2>

<ul> <li>This article uses <a href="http://guides.rubyonrails.org/i18n.html" rel="nofollow" target="_blank">Ruby on Rails Guides</a> as the main source</li> <li>Internationalization for Ruby wiki on <a href="http://ruby-i18n.org/wiki" rel="nofollow" target="_blank">ruby-i18n.org</a></li> <li><a href="http://yaml.org/spec/1.2/spec.html" rel="nofollow" target="_blank">YAML 1.2 specification</a></li> <li><a href="http://yaml.org/refcard.html" rel="nofollow" target="_blank">YAML 1.1 Reference card</a></li> <li><a href="http://en.wikipedia.org/wiki/Yaml" rel="nofollow" target="_blank">Wikipedia article on yaml</a></li> <li>Internationalization for Ruby wiki on <a href="http://ruby-i18n.org/wiki" rel="nofollow" target="_blank">ruby-i18n.org</a></li> <li><a href="https://github.com/svenfuchs/rails-i18n" target="\_blank">rails-i18n github repository</a></li> <li><a href="http://rubyonrails.org/" rel="nofollow" target="_blank">Ruby on Rails home page</a></li> <li><a href="https://github.com/rails/rails" rel="nofollow" target="_blank">Ruby on Rails github page</a></li> <li>i18n for Sinatra on <a href="http://recipes.sinatrarb.com/p/development/i18n" rel="nofollow" target="_blank">Sinatra Recipes</a></li> <li><a href="http://www.sinatrarb.com/" rel="nofollow" target="_blank">Sinatra home page</a></li> <li><a href="https://github.com/sinatra/sinatra" rel="nofollow" target="_blank"Sinatra github page</a></li> <li><a href="http://www.padrinorb.com/guides/localization" rel="nofollow" target="_blank">Padrino guide for localization</a></li> <li><a href="http://www.padrinorb.com/" rel="nofollow" target="_blank">Padrino home page</a></li> <li><a href="https://github.com/padrino/padrino-framework" rel="nofollow" target="_blank">Padrino github page</a></li> </ul>

One of the most popular Ruby gems for internationalization is Ruby I18n. We overviewed i18n for Ruby on Rails in this article. Click and find more inside.

Internationalization for Ruby - i18n gem

<a title="Internationalization for Ruby – i18n gem" href="https://lingohub.com/blog/2013/08/internationalization-for-ruby-i18n-gem">Our previous article on internationalization for Ruby</a> has covered the basic use of the <strong>i18n gem</strong> - currently one of the most popular internationalization solutions in the Ruby world. It contains all the information on setup and usage that most Ruby, Ruby on Rails, Sinatra, or Padrino developers will need. However, there is much more to this gem. This article will highlight some <strong>i18n gem advanced features</strong> in Ruby on Rails internationalization.

## Using different backends for Ruby i18n gem

I18n gem comes with the <a href="https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/simple.rb" rel="nofollow" target="_blank" >Simple backend</a> by default. It can load resource files in YAML or Ruby hashes, but can store new translations only in the memory - it is not possible to save them. This can be a problem if the translation support needs to be built into the application. Also, sometimes for one reason or another, the use of YAML or Ruby hash resource file formats is not an option.

With the i18n gem, other backends can easily be used instead of Simple backend, for example <a href="https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/key_value.rb" rel="nofollow" target="_blank">Key-Value,</a> <a href="https://github.com/svenfuchs/i18n-active_record" rel="nofollow" target="_blank">ActiveRecord,</a>or Gettext.

Backends can also be combined in the Chain backend, which can be useful when the standard translations are used with the Simple backend but custom application translations are stored in a database or other backends.

Next up, I will describe some of the optional backends that come with the gem, but if there is no backend that suits some special need, one could be made from scratch without too much effort.

<h2> Key-value backend</h2>

The store that the backend receives on initialization responds to three methods:

<ul> <li>store#[ ](key) - Used to get a value</li> <li>store#\[ \]=(key, value) - Used to set a value</li> <li>store#keys - Used to get all keys</li> </ul>

Since these stores only support strings, all values are converted to JSON before being stored, allowing it to also store booleans, hashes and arrays. However, this store does not support Procs. Symbols are just supported when loading translations from the filesystem or through explicit store translations.

To initialize the backend, a new file should be created in the /config/initializers directory:

<div><pre>#i18n_backend.rb translations = {} I18n.backend = I18n::Backend::KeyValue.new(translations)</pre></div>

An empty store is available now. New translations can be added by calling the store_translations method on the I18n.backend:

<div><pre>I18n.backend.store_translations(locale, { key => value }, :escape => false)</pre></div>

Translations hash can be accessed through the store:

<div><pre>translations = I18n.backend.store</pre></div>

Key-Value backend is all set now, but since the values are being stored in a Ruby Hash, they will be lost after the web server is restarted. To avoid that, a persistent key-value store should be used, for example <a href="http://redis.io/" rel="nofollow" target="_blank">Redis</a>.

Installing Redis from repository and starting the server:

<div><pre>$ apt-get install redis $ redis-server</pre></div>

The redis gem should be added to the Gemfile ( gem 'redis' ) and bundle command run. Now, instead of a blank hash, a new Redis object should be passed to the backend initializer:

<div> <pre># /config/initializers/i18n_backend.rb I18n.backend = I18n::Backend::KeyValue.new(Redis.new)</pre> </div>

Detailed instruction on setting the Key-Value backend with Redis can be seen in <a href="http://railscasts.com/episodes/256-i18n-backends" rel="nofollow" target="_blank">this railcast</a>.

<h2>ActiveRecord i18n backend</h2>

Support for the ActiveRecord i18n backend has been extracted to a gem of its own: <a href="https://github.com/svenfuchs/i18n-active_record" rel="nofollow" target="_blank">i18n-active_record</a>. To install the gem, this should be put in the Gemfile prior to bundling:

<div><pre>gem 'i18n-active_record', :git => 'git://github.com/svenfuchs/i18n-active_record.git', :require => 'i18n/active_record'</pre></div>

Next, an active record model named <code>Translation</code> should be created. The purpose of the model is for managing translations and languages. The migration should look like this:

~~~
class CreateTranslations &lt; ActiveRecord::Migration def self.up create_table :translations do |t| t.string :locale t.string :key t.text   :value t.text   :interpolations t.boolean :is_proc, :default =&gt; false
  t.timestamps
end
end

def self.down
drop_table :translations
end
end
~~~

To load the backend, a new file should be added to config/initializers named locale.rb:

<div><pre>require 'i18n/backend/active_record' I18n.backend = I18n::Backend::ActiveRecord.new</pre></div>

After the backend is loaded, the translations can be looked up or stored as previously described.

An optional module Missing can be included. It creates empty records in the database for all the missing translations:

<div><pre>I18n::Backend::Chain.send(:include, I18n::Backend::ActiveRecord::Missing) I18n.backend = I18n::Backend::Chain.new(I18n::Backend::ActiveRecord.new, I18n::Backend::Simple.new)</pre></div>

Stub records for pluralizations will also be created for each key defined in i18n.plural.keys.

## A gettext backend for i18n

I18n library provides an experimental support for using [PHP internationalization with gettext tutorial](/blog/php-internationalization-with-gettext-tutorial)  Gettext po files</a> for storing translations. To enable the support, I18n::Backend::Gettext module should be included in the Simple backend or other backend that is currently used

<div><pre>I18n::Backend::Simple.include(I18n::Backend::Gettext)</pre></div>

After the module is included, it is possible to load the po files with the I18n.load_path:

<div><pre>I18n.load_path += Dir\["path/to/locales/\*.po"\]</pre></div>

Following the Gettext convention this implementation expects that the translation files are named by their locales. E.g. the file en.po would contain the translations for the English locale.

The translations can be looked up the same way as for the Simple backend

<div><pre>t('some msgid')

=> 'msgstr for some msgid'</pre>  
</div>

<h2>Chaining backends</h2>

Using multiple backends at the same time is also possible. This can be achieved via the Chain backend. On initialization, it can receive any number of other backends as arguments. For example ActiveRecord backend can be used with a fall back to the default Simple backend:

~~~
first = I18n::Backend::ActiveRecord.new first.store_translations(:en, :foo => 'foo')

second = I18n.backend
second.store_translations(:en, :bar => 'bar')


I18n.backend = I18n::Backend::Chain.new(first, second)


I18n.t(:foo)  # => "foo" I18n.t(:bar)  # => "bar" 
~~~

The cost of replacing the Simple backend and implementing a built-in support for the translation process in each application can be the loss of simplicity and possibly performance. Additional time is also needed to implement and maintain an interface through which the translation would be conducted. On the other hand a specialized professional service can be used instead. You can let Lingohub assume this burden, which lets you focus on developing the application, and our platform takes care of the internationalization details.

<h2>Caching is an i18n gem advanced feature</h2>

To enable caching, the Cache module should be included in the Simple backend, or whatever other backend is being used:

<div><pre>I18n::Backend::Simple.send(:include, I18n::Backend::Cache)</pre></div>

Also a cache store implementation should be set, for example ActiveSupport::Cache:

<div><pre>I18n.cache_store = ActiveSupport::Cache.lookup_store(:memory_store)</pre> </div>

Any cache implementation that provides the same API as ActiveSupport::Cache can be used (only the methods #fetch and #write are being used).

## Fallbacks

I18n locale fallbacks allow use of translations from other locales when translations for the current locale are missing. This can be useful in several cases: <ul> <li>when the application is thoroughly localized to include even the regional variants of a language; in this case regional locale resource files would contain only the phrases that differ, but would fall back to the common base locale (:en-US, :en-CA... with fallback to :en)</li> <li>when it is acceptable to use a temporary fallback for missing translations to some other language that the users are expected to know, in order to provide them with some content until it is localized; the fallback language can be either some mutually intelligible language with the current language, one of the world languages or one of the languages widely spoken in the target community.</li> <li>for testing purposes in the development or during the localization process.</li> </ul>

Locale fallbacks can be enabled by including the Fallbacks module to the backend that is being used in the application:

<div><pre>I18n::Backend::Simple.include(I18n::Backend::Fallbacks)</pre></div>

This in fact overwrites the Base backend translate method in order to force it to try each locale given by the I18n.fallbacks until it finds a result. Otherwise it will throw the MissingTranslation.

If the :default is passed to the translation lookup method, it takes precedence over the fallback only if it is a Symbol. When the default contains a String, Proc or Hash it is evaluated last after all the fallback locales have been tried.

<div><pre>Fallbacks = I18n.Fallback Fallbacks.map( :'en-CA' => :'en-US', :'en-US' => :en, :de => :en ) Fallbacks\[:de\]

=> \[:en\]</pre>  
</div>

## Translation metadata

I18n <a href="https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/metadata.rb" rel="nofollow" target="_blank">translation metadata</a> is useful when accessing information about the way a translation was looked up, pluralized or interpolated.

<div><pre>msg = I18n.t(:message, :default => 'Hi!', :scope => :foo) msg.translation_metadata

=> { :key => :message, :scope => :foo, :default => 'Hi!' }</pre></div>

If <strong>:count</strong> option was passed to #translate it will be set to the metadata. Likewise, if any interpolation variables were passed they will also be set.

Translation metadata can be enabled by simply including the Metadata module into the Simple backend class - or whatever other backend is being used:

<div><pre>I18n::Backend::Simple.include(I18n::Backend::Metadata)</pre> </div>

## Cascading lookups

<a href="https://github.com/svenfuchs/i18n/blob/master/lib/i18n/backend/cascade.rb" rel="nofollow" target="_blank">Cascading lookups</a> can be done in backends that are compatible with the Simple backend.

This means that for any key that can not be found, the Cascade module strips one segment off the scope part of the key and then tries to look up the key in that scope.

For example when a lookup for the key :"foo.bar.baz" does not yield a result then the segment :bar will be stripped off the scope part :"foo.bar" and the new scope :foo will be used to look up the key :baz. If that does not succeed then the remaining scope segment :foo will be omitted, too, and again the key :baz will be looked up (now with no scope).

Cascading lookup can be enabled by passing the :cascade option:

<div><pre>I18n.t(:'foo.bar.baz', :cascade => true)</pre></div>

This will return the first translation found for :"foo.bar.baz", :"foo.baz" or :baz in this order.

The cascading lookup takes precedence over resolving any given defaults. This means that the defaults will kick in after the cascading lookups haven't succeeded.

This behaviour is useful for libraries like ActiveRecord validations where the library wants to give users a bunch of more or less fine-grained options of scopes for a particular key.

## Translation symlinks

It is possible to set key of one key-value pair as a value of another pair. This way both pairs would have the same value, but it would be set only at one place.

<div><pre>en: something: some phrase something_else: :something</pre> </div><div><pre>I18n.t :something_else

=> "some phrase"</pre></div>

Valid use for this would be situation where the key-value pairs that share values are already structured (for example localized libraries or gems). Or if two unrelated pairs, for example one for model and the other for the view, should share the value, perhaps it is better that they both point to a third shared pair, then to use the localization of the model for the localization of the view or vice versa.

<h2>Using custom exception handlers</h2>

The I18n API defines the following exceptions that will be raised by backends when the corresponding unexpected conditions occur:

<div><pre>MissingTranslationData       # no translation was found for the requested key InvalidLocale                # the locale set to I18n.locale is invalid (e.g. nil) InvalidPluralizationData     # a count option was passed but the translation data is not suitable for pluralization MissingInterpolationArgument # the translation expects an interpolation argument that has not been passed ReservedInterpolationKey     # the translation contains a reserved interpolation variable name (i.e. one of: scope, default) UnknownFileType              # the backend does not know how to handle a file type that was added to I18n.load_path</pre> </div>

The i18n API will catch all of these exceptions when they are thrown in the backend and pass them to the default_exception_handler method. This method will re-raise all exceptions except for MissingTranslationData exceptions. When a MissingTranslationData exception has been caught, it will return the exception’s error message string containing the missing key/scope.

The reason for this is that during development it is probably preferred to render the views even though a translation is missing.

In other contexts this behavior can be changed, e.g. the default exception handling does not allow to catch missing translations during automated tests easily. For this purpose a different exception handler can be specified. The specified exception handler must be a method on the I18n module or a class with #call method:

<div><pre>module I18n   class JustRaiseExceptionHandler < ExceptionHandler     def call(exception, locale, key, options)       if exception.is_a?(MissingTranslation)         raise exception.to_exception       else         super       end     end   end end

I18n.exception_handler = I18n::JustRaiseExceptionHandler.new</pre></div>

This would re-raise only the MissingTranslationData exception, passing all other input to the default exception handler.

However, if you are using I18n::Backend::Pluralization this handler will also raise I18n::MissingTranslationData: translation missing: en.i18n.plural.rule exception that should normally be ignored to fall back to the default pluralization rule for English locale. To avoid this translation key could be additionally checked:

<div><pre>if exception.is_a?(MissingTranslation) && key.to_s != 'i18n.plural.rule'   raise exception.to_exception else   super end</pre></div>

Another example where the default behaviour is less desirable is the Rails TranslationHelper which provides the method #t (as well as #translate). When a MissingTranslationData exception occurs in this context, the helper wraps the message into a span with the CSS class translation_missing.

To do so, the helper forces I18n#translate to raise exceptions no matter what exception handler is defined by setting the :raise option:

<div><pre>I18n.t :foo, raise: true # always re-raises exceptions from the backend</pre></div>

These were just some of the<strong> i18n gem advanced</strong> features that seemed most relevant. You can easily find some more if you browse through the <a href="https://github.com/svenfuchs/i18n" rel="nofollow" target="_blank">source code</a> of the i18n gem. Extending the existing functionality by adding custom features is also not very hard.

Even though i18n is probably the internationalization solution for Ruby that you were looking for, the final two articles on internationalization for Ruby that we have prepared will introduce some alternatives to it and will give you more complete picture. Stay tuned for more, follow us on the social media channels and please feel free to leave some feedback in the comments, I would love to hear your thoughts about the tutorial.

## Further reading

<ul> <li>Some sections of this article were taken form <a href="http://guides.rubyonrails.org/i18n.html" rel="nofollow" target="_blank">Ruby on Rails Guides</a> and the <a href="https://github.com/svenfuchs/i18n" rel="nofollow" target="_blank">documentation for i18n gem</a></li> <li>The original <a href="http://github.com/clemens/i18n-cascading-backend" rel="nofollow" target="_blank">Cascading backend implementation</a></li> <li><a href="http://vimeo.com/12665914" rel="nofollow" target="_blank"">Sven Fuchs' presentation on i18n features</a></li> <li>Internationalization for Ruby wiki on <a href="http://ruby-i18n.org/wiki" rel="nofollow" target="_blank">ruby-i18n.org</a></li> <li><a href="http://railscasts.com/episodes/256-i18n-backends" rel="nofollow" target="_blank"">Railscast on i18n backends</a></li> </ul>

Find inside this article the highlighting of some i18n gem advanced features in Ruby on Rails internationalization.

i18n gem advanced features - Ruby on Rails internationalization

<p dir="ltr">According to W3Tech statistics, <a href="https://en.wikipedia.org/wiki/PHP" rel="nofollow" target="_blank">PHP</a> is used by 80.5% of all websites [<a href="http://w3techs.com/technologies/overview/programming_language/all"rel="nofollow" target="_blank">1</a>] and this share is continuously rising \[<a title="Historical yearly trends in the usage of server-side programming languages for websites - W3Techs" href="http://w3techs.com/technologies/history_overview/programming_language/ms/y">2</a>\]. We can safely say that the web “speaks” PHP. But what about the content? Since PHP has been around for such a long time (18 years), its history also tells the story of the evolution of website internationalization. The first article in our series about internationalization programming focuses on <strong>PHP internationalization</strong> and its different dimensions and options PHP makes possible.</p>

## PHP internationalization (early days): Static web and internationalization

<p dir="ltr">Back in the days of static websites, the developer would copy the whole site structure as many times as the number of <a title="The definition of Locale in Wikipedia" href="http://en.wikipedia.org/wiki/Locale" rel="nofollow" target="_blank">locales</a> that the site supported. The translators would then go deep into the structure to make the changes directly in the pages. This was tedious and error prone. The translator would either need to know the basics of HTML and what should/should not be translated within the HTML file, or the developer would have to pull all the text strings, send them to the translator and then re-insert them back in the proper place. It was not a very friendly or quick process for either developer or translator.</p>

##PHP internationalization (today): Dynamic web applications

<p dir="ltr">Then came PHP and the dynamic web. In a dynamic website the content is stored in a database or a file system, and is being inserted into templates on each user request. The <em>separation of content, structure and design</em> became a new mantra of web development. When internationalizing the website, two steps need to be taken:</p>

<ol>
<li>the developer provides a mechanism and method for content to be accessible for the eventual translation of the program and its interface (internationalization)</li>
<li>the translator adapts the content to specific language and culture doing the actual localization.</li>
</ol>
<p dir="ltr">There are various internationalization mechanisms at a developer’s disposal and they differ greatly in their complexity, implementation time, flexibility, efficiency and ease of use for the translator.</p>
<p dir="ltr">Some of these mechanisms can roughly be divided in these groups:</p>

<ul> <li>localizing strings directly in the code</li> <li>storing the strings in a relational database</li> <li>storing the strings in string arrays</li> <li>storing the strings in <a href="http://en.wikipedia.org/wiki/JSON" rel="nofollow" target="_blank"><em>JSON</em></a></li> <li>use of language resource files</li> </ul>

## Localizing strings directly in the code

Localization of the text strings can be dealt with directly in the code. The developer writes conditionals that assign values to variables depending on the current language. The translator performs the translation by browsing the code and editing the string values. This produces “messy” code and is not very convenient for translators. Any later changes are hard to make and to track. <p dir="ltr">Strings can also be pulled from the code/templates. The current language is determined by the program, and a localized string is served.</p>

## Storing the strings in a relational database

<p dir="ltr">Another approach to <em>PHP internationalization</em> is to store the static strings in a <strong>database</strong>. The most simple implementation is to add as many versions of every string or text column as there are supported languages. The specific translations can be retrieved with a single query, so there is no loss of performance. When support for an extra locale needs to be added, the code that pulls the translated string does not have to change much if the naming of the columns is consistent, but every single table containing the translatable content does (new columns need to be added).</p>

Instead of adding extra columns, extra tables can be added. In this case much of the code can be reused, no existing table is altered and new table versions are added for all tables that contain translatable content, in order to translate it to a new locale. When accessing the translated content via <a href="http://en.wikipedia.org/wiki/SQL" rel="nofollow" target="_blank">SQL</a>, joining the table and its localized version is required.</p>

The model can be designed in such a way that no altering of the database structure is needed when a new locale is being added. All translatable content is extracted from the tables to dependent tables that store translated versions in any number of locales. Adding a new locale is as simple as adding a new row to the locales table. The SQL to access the translated strings is not more complicated than in the previous case - a single left join.

All of these implementations have common downsides. The most serious one is the need for developer to implement and maintain an admin interface through which the translator would access and perform translations. Also, a translator would be limited to translating through the given interface unless the developer provided I/O scripts that export to files that the translator could open in a text editor. The translator would have to be careful with the encodings and the format of the file, otherwise, there are problems when importing them back into the database.

## Storing the strings in message catalogues (string arrays)

<a href="http://en.wikipedia.org/wiki/Associative_array" rel="nofollow" target="_blank">Associative arrays</a> can be used to add i18 support to a website. If the number of translations rises, the arrays can be divided to one array per file, one file per locale. Still, these arrays could get quite large, and the developer has to manually maintain them and synchronize them. However, this is probably the simplest solution for a developer, yet it is not as convenient for translators. Translators still have to be very careful while editing not to mess the array and they have to know how to deal with the encoding. It puts a high technical burden on them.



## Storing the strings in JSON

When using this mechanism, a language file is loaded based on the configured language. A static array <strong>$translations</strong> is used to ensure that the language file is loaded once and every other subsequent call is handled through the <strong>$translations</strong> array in the memory rather than reloading the language file anew. The language file is constructed in <a href="http://www.json.org/" rel="nofollow" target="_blank">JSON</a> format and when the language file is loaded into the <strong>$translations</strong> array the PHP <a href="http://php.net/manual/en/function.json-decode.php" rel="nofollow" target="_blank">json_decode</a> function is used to convert from JSON into PHP associative array format. When a call is made to the function, a language phrase is passed to the function and the matching value is found in the <strong>$translations</strong> array by using the language phrase as a key for the associative array. The .txt files need to be utf-8 encoded (without <a href="http://en.wikipedia.org/wiki/Byte_order_mark" rel="nofollow" target="_blank">BOM</a>), otherwise the JSON PHP functions will not operate correctly. [<a href="http://www.mind-it.info/2010/02/22/a-simple-approach-to-localization-in-php/" rel="nofollow" target="_blank">3</a>]

<h2>PHP internationalization (contemporary): Use of resource files</h2>

The current prevailing practice is for applications to place text in resource strings which are loaded during program execution as needed. The resource file format most commonly used in PHP projects is <a href="http://en.wikipedia.org/wiki/Gettext" rel="nofollow" rel="nofollow" target="_blank">Gettext</a>, and it will be visited in detail in the next article. Click here for our earlier <a href="https://lingohub.com/blog/2013/04/localization-resource-file-formats-beginners-guide">article series on localization resource files</a>.

## How Lingohub enhances the translation process

All of the listed mechanisms and methods for PHP internationalization have some common shortcomings, and [Lingohub](https://lingohub.com) deals with all of them successfully. If resource files are used as the main <em>i18n</em> method, and if resource files are uploaded as a part of the Lingohub project, it is possible: <ul> <li>for developers to automate synchronization</li> <li>for translators to focus on translating, without keeping their mind on the technical methods used for internationalization</li> <li>for translators to see the context of the translations (such as meta information, comments, screenshots)</li> <li>for developers to add rules and guidances on how particular translations should be conducted (e.g. by defining <a title="How to: Importing comments and LingoChecks from translation resource files" href="https://lingohub.com/blog/2013/03/how-to-importing-comments-and-lingochecks-from-translation-resource-files">LingoChecks</a>, setting specific regional variety of a language, setting formal/informal)</li> <li>for translators, reviewers and developers to communicate and resolve any doubts on any of the translations using the Lingohub platform, reducing Email traffic</li> <li>for project owners to keep track of the translation status of each individual translation and the project in general</li> <li>for translators to easily and quickly find new or untranslated phrases using filters, advanced search or notifications</li> <li>for multiple people (translators or reviewers) to work on the same project simultaneously without any worry that they will undo each others changes (e.g. via roles and permissions)</li> </ul>

As a result, the <em>PHP internationalization</em> process is less of a hassle, automated to a much greater degree, better quality control is available and it is many, many times faster than it used to be. Ask us if you have questions on how you can best internationalize your project, and check out Lingohub to localize your product. Zero overhead, comfortable integrations and scalability as you'd expect it from a cloud service.

Read more about the PHP internationalization programming in the next article.
<p dir="ltr"><em>References</em>:</p>

<ol>
<li><a title="Usage Statistics and Market Share of Server-side Programming Languages for Websites - W3Techs" href="http://w3techs.com/technologies/overview/programming_language/all" rel="nofollow" target="_blank">Usage Statistics and Market Share of Server-side Programming Languages for Websites - W3Techs</a></li>
<li><a title="Historical yearly trends in the usage of server-side programming languages for websites - W3Techs" href="http://w3techs.com/technologies/history_overview/programming_language/ms/y" rel="nofollow" target="_blank">Historical yearly trends in the usage of server-side programming languages for websites - W3Techs</a></li>
<li><a title="A simple approach to Localization in PHP - Mind IT | Mind IT" href="http://www.mind-it.info/2010/02/22/a-simple-approach-to-localization-in-php/" target="\_blank" rel="nofollow" target="_blank">A simple approach to Localization in PHP - Mind IT | Mind IT</a></li>
</ol>

<h2>Ready to localize? Try Lingohub for free.</h2>

This article is provided by [Lingohub](https://lingohub.com), a translation management software. It is used by development and product teams from all over the world to manage software translations more productively.

<a href="https://translate.lingohub.com/sign-up/">Sign up for a free 14-day trial.</a>

Looking for effective PHP internationalization with fewer hassles? We found the solution that will help you. Learn more inside our blog

PHP internationalization - i18n mechanisms tutorial

Several of our customers asked us to support branches (from versioning systems like GIT or SVN) in <em>Lingohub</em>. The reasoning behind this is, that i18n resources and their according associations often belong to one or more branches, and then you should be able to merge them (GIT-like) with others. One of my beliefs is that a good product owner must be very skeptical of "feature requests" and instead look for the problems and/or the desired benefits behind such a request. In this case, a<strong> <em>faster release cycle</em></strong> including translated text was of the essence - and is in fact also very dear to Lingohub's mission. Once we narrowed that down, we focused on some of the circumstances and on common practices of the current situation determining the agility of your release cycle: <ul> <li>Developers usually text themselves (in English, or their native language, or both).</li> <li>Text changes during the development of a feature, hence a final version often exists only at the very end of a development cycle.</li> <li>Different language implementations are seldom tested already during development.</li> <li>Very often, a review process for texting and other copywriting (in source and target languages) is not in place.</li> </ul>

Based on this feedback, we started working on tool support to allow managing a faster release cycle for your translation. Basically, <strong>our main goal is to minimize the time it takes to translate text <em>*without*</em> sacrificing the quality</strong>. We already released a couple of features for that purpose: our  [CLI client](/blog/2013/01/syncing-your-resource-files-with-the-lingohub-cli-client) for scripted automation, and [LingoChecks](https://lingohub.com/blog/2013/01/introducing-lingochecks) for verification - but this is just the start, there will be more announcements in the upcoming weeks. However, this blog post is about a working solution for <strong>today</strong>. What's a best practice for integrating internationalization? Let me outline for you how we translate <em>Lingohub</em>:

For every feature, we create a <em>feature branch</em> named after the issue ID (we use JIRA, so in our case lwe-xx). Finished features are merged into our <em>master branch</em> (all specs green), from there it takes another merge into the <em>production branch</em> to actually get released. Some leave out the production branch, but this is a typical GIT workflow. However, our <em>i18n branch</em> is special. This is the branch that gets synchronized with <em>Lingohub</em>. Every time someone pushes something to the i18n branch, Lingohub checks for new or updated texts. Having<strong> a specific branch for internationalization</strong> allows us to specify the moment when texts are considered finished. This can be during any stage of feature development (specs can be red or the feature is just a mock up). It <em>decouples</em> the <em>development cycle from the translation cycle</em>. For every release (production branch), we then synchronize our resource files by script via Lingohub's REST <strong>API:</strong> Deployment and retrieval of the texts is one step with one shell command.

Since an image is worth a 1000 words, here is a diagram describing the workflow (without production branch since it is not necessary):

<ol> <li>Development in feature branch, merge with i18n branch once the texts are ready.</li> <li>Automatic synchronization with Lingohub (we use Github integration, but you can also use git hooks).</li> <li>Feature development is finished and merged into master (or any other 'production' branch).</li> <li>Before the release of the feature, the texts are synchronized with Lingohub.</li> </ol>

This is the workflow we use for translating our texts. Since 'eating your own dogfood' is the best way to actually see what's working and what not, we know the strengths and weaknesses of this approach. What we really like about this workflow is how easy it can be integrated in any software development process. Nevertheless, there are still some steps and issues we think can be improved to help you: better feedback on translation texts, faster translations, communication integration and more checks.

This is just one way to use Lingohub. With our API you can use the service as you like. Please check out our developer and [API documentation](https://docs.lingohub.com/api-docs/). Don't hesitate to contact me (<a href="mailto:helmut@lingohub.com">helmut@lingohub.com</a>) if you are using other approaches or if you are having questions. We welcome your feedback and work especially close with our customers on identifying other areas where we can make localization an even better experience for you.

Control the project versions with Lingohub. Our branching support allows work with the different branches and keeps the project clean.

Integrating internationalization in a GIT workflow

>**Note**: Lingochecks now is Quality checks. [Read about updated feature](/features/quality-checks) to get more information.


When a translation [resource file](/blog/i18n-resource-file-formats) is uploaded to <a href="https://lingohub.com"><em>Lingohub</em></a>, its content is analyzed and the translation texts are being parsed. Additionally, comments describing the translations are processed and saved. It also works in the opposite direction: the <em>extra</em> data added to a translation while using Lingohub is exported back as a comment preceding that translation in the resource file you download.

The comments in <em>translation resource files</em> are used to <em>tell</em> the parser to ignore something that would otherwise be parsed. They are usually added to either skip some content or to add information that describes the content. Lingohub recognizes all these comments as translation descriptions and stores them that way. At the same time, it ignores the commented-out content or comments not belonging to individual translations. Proper comment syntax for each of the resource file formats was described in previous posts.

This two-way synchronization of comments allows developers to add descriptions to any text without leaving the development environment. By the way, comments are only parsed for master locale resource files.

## Adding LingoChecks to comments

Recently we introduced <a href="https://lingohub.com/blog/2013/01/introducing-lingochecks">LingoChecks</a>, a convenient way for developers to add more context to content that needs to be translated. LingoChecks can be set on a project level or per translation. They can also be set in the translation comments of the resource files. This way, a LingoCheck can be added at the same time a translation is added to a master locale file. It also allows a means to quickly review and change multiple LingoChecks in a resource file, and apply the update by simply uploading the file to Lingohub.

LingoChecks are extracted from the comments belonging to translations while all plain comments preceding and following the LingoCheck line are kept, and saved as the translation description. LingoCheck lines start with the <strong>lh-check </strong>keyword, followed by a curly braces block. The block contains the rules that should be applied to the translation. The individual checks start with the keyword (for example <strong>min</strong>), followed by a colon and a value for the check. If the rule being set is <strong>terms</strong>, and it has multiple values, they should be comma-separated and enclosed in brackets. If there are multiple rules present in the block, they should be comma separated and the order is not important. <ul> <li><strong>min:</strong> <em>value</em>, where value can be: <strong>d</strong>, <strong>+d</strong>, <strong>-d</strong>, <strong>%d</strong>, <strong>d%</strong>, d being any positive integer</li> <li><strong>max:</strong> <em>value</em>, where possible values are the same as for <em>min</em></li> <li><strong>placeholders:</strong> <em>value</em>, where value can be either <strong>true</strong> or <strong>false</strong></li> <li><strong>terms</strong>: <em>value </em>or <em>\[value1, value2\]</em>, where value can be phrase or comma separated list of phrases enclosed in brackets</li> </ul>

The following is an example of uploading Java <a title="i18n Resource File Formats: properties files [properties files](https://lingohub.com/blog/2013/03/resource-file-formats-properties-files-comments) that contain comments and LingoChecks within comments. If the iOS strings file, yaml file, Android .xml file, or any other file format that we support, was uploaded instead, the result would be very similar, the only difference being in the file syntax.

The source of the properties file that is used for this test.

If you have further questions, I am looking forward to comments. We will highlight more features in detail in upcoming blog posts.

Learn how Lingohub handles translation resource files and how the uploaded content is analyzed and parsed, including comments describing translations.

How to: Importing comments and LingoChecks from translation resource files

<p class="p1">Angular 2 will <strong>change a lot</strong> (<a title="Brace yourselves, future is coming: ES6, AtScript and Angular 2.0" href="https://lingohub.com/blog/2014/11/brace-future-coming-es6-atscript-angular-2-0">RIP everything you know</a>) - also the client-side i18n support. Chirayu Krishnappa and Pascal Precht gave a <a title="Better i18n for your Angular apps" href="http://youtu.be/iBBkCA1M-mc" target="\_blank">talk</a> on this year's ng-conf in Salt Lake City about how to use i18n for future Angular apps. Currently there is no standard how you localize your angular app - <strong>we</strong> are using <a href="http://angular-translate.github.io" target="\_blank">angular-translate</a> from Pascal Precht. It is working great with JSON files + Lingohub. (Wanna try? Just <a title="Create Lingohub project" href="/help/getting-started/first-lingohub-project/" target="\_blank">create</a> an Angular project on Lingohub and upload your JSON files).</p>

<h2 class="p1">New Angular i18n usage and tooling</h2>
<p class="p1">Your texts (which should be translated) stay in the HTML templates. But a translator can't use HTML to translate, that is why Angular will offer an Extraction Tool. This tool <strong>extracts texts</strong> (also texts from placeholders) from your HTML templates. It will support different (standard translation) file formats, for example <a href="/developers/resource-files/standard-xliff-localization/">XLIFF</a> or PO.</p>

> A good solution lets you localize your apps in whatever shape they are.

<p class="p1">Lingohub already supports that kind of formats, so you will have no problems giving your translators a nice UI to translate your texts on Lingohub!</p>



<p class="p1"><span class="s1">These two code examples show you the main differences between angular-translate and the Angular i18n approach with the new Message Extraction Tool.</span></p>

<p class="p1">Angular 2 Tool then generates JSON or HTML templates for different languages. (At the moment it is not yet sure how the generated JSON will look like)</p> <p class="p1">An important feature will be that you can add <strong>context</strong> for the translator so that he knows what the text actually means, just by adding the <strong>i18n attribute</strong> to the HTLM tag. I am going to write another blogpost about how the process will work once the Extraction Tool is available (probably in May 2015)!</p> <p class="p1">You will find first implementations of the new i18n ecosystem already in Angular 1.4, where they will add support for pluralization and gender.</p> <p class="p1"><span class="s1">All these changes sound very exciting and is definitely a step towards easy translation of an Angular app. Of course Lingohub will support both approaches. Be Global, Go Local!</span></p> <p class="p1"><strong><span class="s1">References: </span></strong><a href="http://youtu.be/iBBkCA1M-mc" target="\_blank">Better i18n for your Angular apps</a> (Chirayu Krishnappa and Pascal Precht)

<span style="line-height: 1.5;">Special Thanks to </span><a style="line-height: 1.5;" href="https://pascalprecht.github.io/" target="\_blank">Pascal Precht</a><span style="line-height: 1.5;"> for additional information.</span></p>

## Lingohub - Localize & Translate Software

This article is brought to you by [Lingohub](/), a translation management system used by hundreds of teams to store and manage their translations. Lingohub helps you automate mundane tasks of software localization, while ensuring high-quality translations that are always up-to-date. With Lingohub, you can translate web apps, mobile apps, websites, games, design files or even documents. [Try it for free right here](https://app.lingohub.com/sign-up).

The Lingohub team described new Angular i18n usage and tooling in this article. Take a look in detail at how this work. Click and read all inside.
