Home arrow Ruby-on-Rails arrow Multiple Language Support for an Ecommerce Application

Multiple Language Support for an Ecommerce Application

If you're building an ecommerce application that will do business in more than one country, you will probably need to support multiple languages. Indeed, you might face this problem even if you're doing business in just one state in the US, such as Florida or Texas. This four-part article series will show you how to add support for multiple languages to a Ruby-on-Rails ecomerce application. It is excerpted from chapter 10 of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 4
June 25, 2010
  1. · Multiple Language Support for an Ecommerce Application
  2. · Using the Globalize Plugin
  3. · Localizing with Globalize
  4. · Localizing the Model

print this article

Multiple Language Support for an Ecommerce Application
(Page 1 of 4 )

In this chapter, you will learn how to translate your application into multiple languages. Supporting more than one language is essential to the success of an online business. For example, tens of millions of Spanish-speaking Internet users are all potential customers, and making your website accessible to these people will most likely increase your sales. Supporting a new language usually means a lot of extra work, but we’ll show you how to do it easily with the help of a Rails plugin called Globalize.

Getting the Localization Requirements

George is hoping that making the new Emporium website accessible in multiple languages will boost his sales and profits into the stratosphere. His end goal is to make Emporium the biggest online bookstore, and translating the site to Swedish is the first step. He also has plans on expanding to China and North Korea, but that’s going to be done later after he has conquered the English- and Swedish-speaking countries.

We tell him that the technical part is easy with Rails, because there’s a plugin called Globalize that does the tricks needed for supporting different languages. All he has to do is find someone who can type in the translations, and we’ll provide the technical implementation.

For this sprint, we define one user story related to the user interface and four user stories related to the administration interface for managing translations:

  1. Change locale: The customer must be able to change the locale on the Emporium website. This should be done by clicking a link, which changes the locale and stores the setting in the session.
  2. List translations: The administrator must be able to view a list of all text that is used in Emporium. The administrator should be able to easily see text that hasn’t been translated and text that has been translated. 
  3. Add translation: The administrator must be able to add a new translation for text. 
  4. Edit translation: The administrator must be able to edit translated text. 
  5. Delete translation: The administrator must be able to delete translated text.

We’ll get started by installing the Globalize plugin and seeing how it supports localization.


Adapting an application to a specific language or region is commonly referred to as internationalization (i18n) and localization (L10N). The numbers, 18 and 10, specify the number of characters that have been left out in the somewhat cryptic abbreviations.

Internationalization refers to the process of modifying an application’s design so that it can support locale differences like text orientaton, currency, date and time format, sorting, and so forth. This can be done by externalizing text strings into files or a database, and by developing currency and date formatting utilities.

Localization means adapting an appication to a specific language or locale; for example, by translating text into multiple languages. A locale is identified by the user’s language and country, and specfies how, for example, numbers, currencies, and dates are dsplayed on the screen. The code for the US English locale is en-US. Locales are specified by RFC 3066 and consist of two parts. The first is an ISO 639 language code and uses lowercase letters. The second is usually an ISO 3166 country code in uppercase letters.

blog comments powered by Disqus

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials