So, you’re a developer working on the next big thing. Your customers love your product and it’s getting rave reviews on all the social networks. Even better, the CEO of the company has just secured $10,000,000 in funding to expand into new markets. But before you can go global, the product must be updated to support different languages, currencies, date formats, and much more. And guess what? You and your team are the ones in charge of making this happen. In technical terms, your software must be internationalized and then localized.
Internationalization (also known as i18n) is the process of creating or transforming products and services so that they can easily be adapted to specific local languages and cultures. Localization (also known as L10n) is the process of adapting internationalized software for a specific region or language. In other words, internationalization is the process of adapting your software to support multiple cultures (currency format, date format, and so on), while localization is the process of implementing one or more culture.
These two processes are usually adopted by companies that have interests in different countries, however they might also come in handy for a single developer working on their own site. For example, as you might know, I’m Italian and I own a website. My website is currently in English but I might decide to internationalize it and then localize it into Italian. This is beneficial for those that are native Italian speakers and aren’t well accustomed to the English language.
But before delving into Globalize, I’d like to conclude this brief introduction on i18n with the words of Rafael Xavier de Souza, the lead of the project:
Developers think i18n is about translations to non-English languages. That i18n is only needed for expanding the current application to multiple countries or markets. I always try to explain that i18n is about “talking” in general. Every application, at some point, has to “talk” to its users. To talk with the users, the application may require pluralization support, gender inflection, date formatting, number formatting, and currency formatting. Even in English, it might be tricky to get this done properly.
What is Globalize?
Globalize is based on the Unicode Consortium’s Common Locale Data Repository (CLDR), the largest and most extensive standard repository of locale data available. So, unlike libraries that embed locale data, if you use Globalize it’s really easy to always be up-to-date with the latest CLDR data.
The library works both for the browser and as a Node.js module. Globalize 1.0 supports all major browsers including IE9+, Chrome, Firefox, Safari 5.1+, and Opera 12.1+.
The main features of the library are:
- Number formatting and parsing
- Date and time formatting and parsing
- Relative time formatting
- Currency formatting
- Message formatting
- Plural support
- Unit support
One of the things I like the most about Globalize is that it has a module for each of its features. A developer may not need the whole library and can thus cherry-pick the module(s) needed. Another interesting feature is that, unlike other libraries, it keeps the code separated from the content by not hosting or embedding any locale data in the library.
Intl object is an object available on the
window object which acts as a namespace for the Internationalization API. This API currently provides methods to format numbers and dates, and to compare strings in a specific language.
Now that you know of the existence of the Internationalization API, you could be led into thinking that Globalize uses it behind the scenes. This approach would surely lead to better date and number formatting performance. However, because the support is low and very inconsistent among browsers, the library doesn’t use it.
Before we move on and start the discussion on Globalize, I want to give you a taste of the Internationalization API.
Formatting a Date
The first example I’m going to show uses the Internationalization API to format a date in several locales: IT, US, and GB.