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

When translating software, it is particularly important to pay attention to <a href="http://en.wikipedia.org/wiki/First_language" rel="nofollow" target="_blank">native language</a> 
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 <a href="http://en.wikipedia.org/wiki/User_experience" rel="nofollow" target="_blank">User Experience</a>. 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 <a href="http://revealingerrors.com/translation_systems">error message</a>.

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 <a href="http://en.wikipedia.org/wiki/Internationalization_and_localization" rel="nofollow" target="_blank">software localization</a> 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.

Software localization is crucial to adopt a native approach to provide customers with an excellent product. Neglecting this task could result in missing out on a significant portion of the market. Read our article for more information.

Your customers prefer native language

Your customers prefer Native Language

This is the second post of my series "Do you speak <a class="zem_slink" title="UTF-8" href="http://en.wikipedia.org/wiki/UTF-8" target="_blank" rel="wikipedia">UTF-8</a>?". <a title="Do you speak UTF-8?" href="https://lingohub.com/blog/2012/04/do-you-speak-utf-8">Here </a>you can find the first article on this topic.

This article covers how <a class="zem_slink" title="Ruby (programming language)" href="http://www.ruby-lang.org/" target="_blank" rel="homepage">Ruby</a> 1.9 handles encoding internally and which tooling it provides for encoding issues. Prior to Ruby 1.9 a String was just a sequence of bytes. Calling the method size() returned the size of this byte array, not the character count. In Ruby 1.9 the <a class="zem_slink" title="Character encoding" href="http://en.wikipedia.org/wiki/Character_encoding" target="_blank" rel="wikipedia">Encoding</a> is stored along with that byte array.

As you can see in this example: You may ask for the encoding of a String. size() returns the actual character count. bytesize() gives you the actual number of bytes. How these two representations differ can be seen if you compare the codepoints and the bytes.

\[gist id=2818443\]

So this looks fine. But what to do if you want to change the encoding of a String eg. to write it to a file in a specific format. To change the encoding of a String you can use <a title="String#encode" href="http://www.ruby-doc.org/core-1.9.3/String.html#method-i-encode">String#encode</a>.
But you have to be aware that there are some pitfalls to that. There is not always a possibility to concatenate Strings having different encodings. This rule is true if one of the characters exceeds the <a class="zem_slink" title="ASCII" href="http://en.wikipedia.org/wiki/ASCII" target="_blank" rel="wikipedia">ASCII</a>-7 charset (having a byte value bigger than 127). A not allowed concatenation will lead to a Encoding::CompatibilityError. 

As mentioned in the prior post: text files do not have that meta information. There is no information about the encoding stored along with the file. The same restriction applies to source files. The effect of this issue can be seen if you change the encoding of a source file that includes non ASCII strings inside a text editor.

But not only text editors have to know the encoding of strings to store the correct byte sequence to disk. The Ruby interpreter has to know how to decode the read bytes. To add this meta information Ruby 1.9 allows to specify this information as a comment in the first line of the source code:

\[gist id=2815831\]

Speaking about files. How do I specify the encoding of a file that I want to read from disk? File.open() allows you to assign the encoding that will be used to read and encode the file data. In this example the read string will have the encoding specified at open().

\[gist id=2831484\]

In the second part of the above code example you can see that there is the possibility to specify the internal encoding of this file operation. The read string will be transcoded to that given format.

Doing this makes life really easier. For most applications it is a best practice to work with just one internal encoding. Preferably 'utf-8'.

Sources:
<ul>
<li><a href="http://yehudakatz.com/2010/05/05/ruby-1-9-encodings-a-primer-and-the-solution-for-rails/">http://yehudakatz.com/2010/05/05/ruby-1-9-encodings-a-primer-and-the-solution-for-rails/</a></li>
<li><a href="http://blog.grayproductions.net/articles/ruby_19s_string">http://blog.grayproductions.net/articles/ruby_19s_string</a></li>
<li><a href="http://nuclearsquid.com/writings/ruby-1-9-encodings/">http://nuclearsquid.com/writings/ruby-1-9-encodings/</a></li>
</ul>

In this article, we'll discuss how Ruby 1.9 manages encoding internally and the tools it provides to handle encoding issues. Looking to get more info? Visit Lingohub blog

Ruby and Encoding

Rails 3 added a security protection against <a class="zem_slink" title="Cross-site scripting" href="http://en.wikipedia.org/wiki/Cross-site_scripting" target="_blank" rel="wikipedia">Cross-site scripting</a> per default. This is a good thing because it makes your <a class="zem_slink" title="Web application" href="http://en.wikipedia.org/wiki/Web_application" target="_blank" rel="wikipedia">web application</a> safer, but it also can cause troubles when you are using html in your translations. What Rails does, is to distinguish between 'html_safe' and not 'html_safe' strings. When a string is not safe, it will be always escaped. Hence, your <a class="zem_slink" title="HTML element" href="http://en.wikipedia.org/wiki/HTML_element" target="_blank" rel="wikipedia">HTML tags</a> are shown in the text and not used as actual HTML tags.

What does that mean in your code? Let's digg in:

Let's say we want a formatted text like this:

<hr />

<h2>Lingohub (h2 tag)</h2>

can't wait to see it (text enclosed in p tag)

<hr />

Of course we use a resource file to store our text, so our application is ready to go global. And for demonstration purposes we put the HTML tags in the text (something I normally don't recommend). Here is our resource file:

\[gist id=2472073\]

All these translation have the text from above and the key is named after the method we use to display them.

And here is the code with the results:

\[gist id=2500433\]

The first line translates the string and puts it right in the view. Since the string isn't marked as html_safe, the tags are escaped using &lt; and &gt;.In doing so, Rails makes sure that when you display text from an untrusted source (e.g. user inputs), no harmful code can be embedded in your site. Line 2 uses the raw method to create a new string that is marked html_safe. Line 3 uses the html_safe method, which works like the raw method. Note, no raw! or html_safe! method exists to mark the existing string html_safe. There will be always a new string object created. Most interesting is Line 4 which shows a handy convention. When a translation title ends with "_html", Rails assumes that the text contains <a class="zem_slink" title="HTML" href="http://en.wikipedia.org/wiki/HTML" target="_blank" rel="wikipedia">HTML</a> and you don't want to escape it.

Like above mentioned, I am not a big fan of using HTML in your translation texts, but if you do, I would recommend to stick to the "_html" convention. It keeps the code cleaner and shows you right at the source if a translation text will be escaped or not.

Have fun translating!

Sources:
<ul>
<li><a href="http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/">http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/</a></li>
<li><a href="http://guides.rubyonrails.org/i18n.html#using-safe-html-translations">http://guides.rubyonrails.org/i18n.html#using-safe-html-translations</a></li>
</ul>

Here are three methods to incorporate HTML into your Rails translations. Click and learn more useful information in our blog

Three ways to use HTML in your Rails translations

<blockquote>“ @ mperham : You have a problem, your data is in latin1 so you think : " I'll convert to UTF8 !" Now you have � problems .” cc @ kingshy_g</blockquote>

Everyone of us coders who dealt with encodings felt that pain, didn't you?

## Character Encoding

Since 2009, UTF-8 has been the dominant encoding (of any kind, not just of Unicode encodings) for the Internet, and as of March 2020, it accounts for 95.0% of all web pages. UTF-8 overtook all other encodings in 2008 and over 60% of the web in 2012.

Character encoding is an information point for anyone planning to create content outside languages that use the basic Latin alphabet characters. Character encoding refers to the proper readability of characters within the text - by human users, machines, and search engines.
Computers store characters as single or grouped bytes. Character encoding is the way these bytes (characters) are properly displayed.

It’s important to differentiate between fonts and character encoding - while you might have the proper character encoding on your hands, the selected font might not display the proper character and instead offer unreadable icons, such as empty squares, question marks, etc.

## ASCII basics

In the beginning, there was ASCII - American Standard Code for Information Interchange. ASCII is a character encoding standard for digital communication. ASCII includes basic characters, punctuation, numbers, and letters, which are present in the English alphabet.

However, as the Internet expanded further from the basics of the English language, billions of users had little use of Latin characters to access relevant content, and ASCII was succeeded by new character encoding.
It’s helpful to know that the first 256 code points (unique numbers for each character) of ASCII, ISO-8859, and UTF-8 are identical. Although ISO-8859 offers coverage of most languages that use the Arabic script, UTF-8 further expands and covers most living languages and writing scripts worldwide.

If you haven’t thought about your target audience (current and future), this is the time to do so.

## What is UTF-8?

UTF-8, or Unicode Transformation Format, is an extension of ASCII. UTF-8 encodes code points in one to four bytes.

Structure of UTF-8: 
- One byte: The first 128 characters ( corresponding to ASCII characters). 
- Two bytes: The following 1,920 characters require two bytes to encode (which includes a huge majority of Latin-script-based alphabets, but also Hebrew, Arabic, Cyrillic, and Greek)
- Three bytes: Includes other characters for languages such as Chinese, Japanese, Korean
- Four bytes: Includes historic scripts, mathematical symbols, and emoji. 


## Is UTF-8 compatible with ASCII?

The UTF-8 codes for the standard ASCII characters are corresponding. This makes UTF-8 ideal for backward compatibility with existing ASCII text. However, keep in mind that UTF-8 and UTF-16 are not as compatible.

In general, UTF-8 dominates the web and has been the recommended encoding since HTML5.

## Why is this relevant for you?

Since an HTML page can be only in one encoding, UTF-8 is the favorable choice. It supports many languages and allows a mix of different languages on a page.

Since all ASCII characters in UTF-8 have the same bytes, it makes backward compatibility easy as well.

Dealing with encodings can be frustrating for coders. It's still an ongoing issue in the tech industry, especially when working with various resource file formats. In this article we are sharing our experiences and solutions for this question.

Do you speak UTF-8?

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:
<ul>
<li>Do it Yourself</li>
<li>Pay Someone for doing Translation</li>
<li>Ask your Users</li>
</ul>

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 "<a href="http://ruby-i18n.org/">I18n</a>" (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. <ol> <li>Give support for English and other similar languages out of the box</li> <li>Provide a user-friendly and adjustable functions for supporting other languages</li> </ol>

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: <ol> <li>The public I18n API - provides a Ruby module with public methods to characterize the work of the library</li> <li>A default backend - which executes these public methods</li> </ol>

The Public I18n API comes with two most important methods which are: 

<ol> <li>translate # This public method do translations of the text</li> <li>localize # This public method localize Date and Time objects to local formats as per settings</li> </ol> 

These method have aliases #t and #l respectively, so you can use them like this:

\[gist id=772983\]

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:

\[gist id=773002\]

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 :

\[gist id=773005\]

Some other available locales which are supported by rails 3 are:

ar, bg, bn-IN, bs, ca, cy, cz, da, de, de-AT, de-CH, dsb, el, en-GB, en-US, eo, es, es-AR, es-CO, es-MX, es-PE, et, eu, fa, fi, fr, fr-CA, fr-CH, fur, gl-ES, gsw-CH, he, hi-IN, hr, hsb, hu, id, is, it, ja, ko, lo, lt, lv, mk, mn, nb, nl, nn, pl, pt-BR, pt-PT, rm, ro, ru, sk, sl, sr, sr-Latn, sv-SE, sw, th, tr, uk, vi, zh-CN, zh-TW

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:

\[gist id=773012\]

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.

\[gist id=773014\]

Let's check now whether this settings translate "hello" into "German" locale or not.

\[gist id=773017\]

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.

\[gist id=773020\]

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.

\[gist id=773024\]

The algorithm for pluralization is:
\[gist id=773027\]

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 <ul> <li>Localization of Times/Dates</li> <li>Using views for translation</li> <li>Translating ActiveModel errors</li> <li>Organization of resource files</li> <li>Setting the locale (from domain, parameter or client) and of course storing it in the database when the user is logged in</li> </ul>

For more details you can check <a href="http://ruby-i18n.org/">http://ruby-i18n.org/ </a>.

Learn about the Internationalization (I18n) API in Rails 3, including its definition, mechanism, setup, configuration, and usage with interpolation and pluralization.

Internationalization (I18n) API in Ruby on Rails 3 (Part I)

In <a title="Internationalization (I18n) API in Ruby on Rails 3 (Part I)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-i">Internationalization (I18n) API in Ruby on Rails 3 (Part I)</a> and <a title="Internationalization (I18n) API in Ruby on Rails 3 (Part II)" href="https://lingohub.com/blog/2011/09/internationalization-i18n-api-in-ruby-on-rails-3-part-ii">Internationalization (I18n) API in Ruby on Rails 3 (Part II)</a> we already covered a lot of the Rails I18n functionality. In part III, we will now look at some more advanced features of I18n.

<h2>Using Different backend with I18n</h2>

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.

<h3>Using Database backend for Ruby I18n API</h3>

You can easily use your database for storing all the translations with the help of i18n_backend_database (<a href="https://github.com/dylanz/i18n_backend_database" target="_blank">https://github.com/dylanz/i18n_backend_database</a>) 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:

\[gist id=801603\]

Add this lines in config/initializers/i18n.rb

\[gist id=801606\]

In config/routes.rb register admin panel routes

\[gist id=801610\]

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().

\[gist id=801637\]

Interpolation is handled by passing in key/value pairs as a value to an interpolation tag    ( {{ }} ).

\[gist id=801638\]

<h2>Translating Routes with translate_routes Gem</h2>

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:

\[gist id=801612\]

And let bundle do the rest: bundle install

1) Let's say you have this in your routes.rb file:

\[gist id=801614\]

You can see the available routes with the 'rake routes' task:

contact  /contact(.:format) {:controller=>"contact", :action=>"index"}

2) Now write your translations in a standard YAML file (e.g: in /config/i18n-routes.yml), including all the locales and their translations pairs:

\[gist id=801617\]

3) Append this line in your routes.rb file to activate the translations specifying the path of the translations file:

\[gist id=801618\]

4) Execute rake routes to see the new routes:

contact_es  /es/contacto(.:format) {:controller=>"contact", :action=>"index"}
contact_en  /contact(.:format)     {:controller=>"contact", :action=>"index"}

5) Include this filter in your ApplicationController:

\[gist id=801619\]

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.

You can find additional information in the <a href="http://ruby-i18n.org/wiki">translate_routes' wiki</a>.

Globalize2 - Alternatives for Ruby I18n Gem

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. <ul> <li>Model translations – This functionality transparently translates ActiveRecord data</li> <li>Locale LoadPath – This gem load translation data from standard locations enforcing conventions that suite your needs</li> <li>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</li> <li>Translation value objects – You can access useful meta data information on the translations returned from your backend and/or translated models</li> </ul>

<h2>Conclusion</h2>

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, <a href="http://rails-i18n.org/wiki">I18n Wiki</a>.

This article is the third part of the Ruby series, where we will delve into some of the more advanced features of I18n. Read it and the previous two parts in our blog