Localization?

Localization is a way of presenting content to users in the locale of their choice. Using Localization, one can present content in multiple languages, currency formats etc. to facilitate application use.

Imagine building a Web Application that will be used by users in many countries.

It is important to make a list of all the Static Text Content (such as Headers, Labels, Text Messages, Button Titles) so that it can be translated into multiple locales.

If you’re working with .NET, Microsoft provides Resource files (.resx format) that developers can create to build a list of elements that need to be translated. Satellite assemblies or locale specific resource files can be easily created by appending the locale as a part of the file name.

Here is an example of a Resource file in English:

As you can see, simple key/value pairs are created for the various messages used in the system.

The corresponding Japanese version of this file can be created by simply appending the Japanese locale (ja-JP) as a part of the resource. The example for the Japanese resource file is as follows:

That Was Easy? Not Really – aka The Challenge

Sounds great chief! Let’s GO! Nope, wait a minute. The story doesn’t end there…

Developers are often stuck with the arduous task of passing on these files to marketing departments who are responsible for translating these files. They often communicate with teams of translators to get translations completed. Once complete, these still need to be passed on to the developers.

So you manage Localizations in Word? Excel? JSON? XML? Notepad? Believe it or not, we’ve tried it all.

This process may seem easy, but as the complexity of the Software Applications grow, managing translations takes a life of its own.

Sooner than later, you’ll end up with angry developers and last minute change incorporating Marketing folks (those Marketing folks!) pointing fingers at each other for not putting the right version in the release that went out.

GitHub to the rescue?

In the past, we have resorted to building GitHub Source Control projects for managing translations, but that comes with its own learning curve.

You can’t expect translators to learn Git.

So much for being able to do things in an efficient manner.

There has to be a better way to do this

Our Developers started asking this question and lo and behold, we stumbled into an amazing service called Locize that takes away the pain on the procedural overheads of Localization.

The premise behind Locize is pretty simple. You can build your own Projects to identify a system that needs translation.

Once that is done, you can setup Namespaces underneath this project (think of this as sub-domains in a larger application that need translation).

Under each namespace, you can define Key/Value pairs of entries that need to be translated.

You can also define the languages that you need translations for.

Entries can be created using the Locize Web Application, or simply uploaded from the multiple different formats that are supported.

A typical example of an uploaded resource looks like so:

Once the resources are created, we can invite Users to translate these resources and optionally also decide which languages they have access to for translation.

Once your translators sign up, they can start translating content.

What’s even more amazing is that all you need to do is drop a Script in your Web Applications and instantly get the latest CDN translations into your app!

Users can see the translation progress in real-time and more or less automate the entire process of localization while maintaining a strong audit-trail of translations.