A Useful Hack : Using Localization Tools For UI/UX
Most software companies don’t think about localization early on in product development. After all, why spend time making your app run in multiple languages when you don’t know if there’s demand for it in your home market?
This is true, but there’s a good but little known reason to prep your application to run in multiple languages, even if you never launch it outside your home language. The reason is to enable UI, UX and marketing people at your company to refine the text that appears throughout your application without touching its source code. The basic pattern looks something like this. First, a brief overview of how localization is typically done in most development environments.
Most development environments and frameworks provide a set of tools for localizing your application for specific languages and locales. A locale typically consists of a language and country pair. For example, en-US for American English, or es-MX for Mexican Spanish. The locale code, usually a country code, can affect both language (for example you might use different terms in Mexican Spanish than Argentine Spanish) and display settings (e.g. date/time formats, numbers, and so on).
Your development environment will typically provide a set of helper functions that perform tasks such as pulling human readable prompts out of prompt catalogs (so you aren’t hard coding your display prompts in source), formatting strings according to location specific rules, and so on. Prepping your app for multilingual operation is pretty straightforward if you make a habit of externalizing human readable text early on (although many companies don’t get around to doing this until they decide they need to localize, often because the requirement is being forced by customers, investors, etc).
For now though, let’s assume you never plan to release your app outside of its home language, usually English. You can still benefit a great deal from incorporating localization into your development process, except instead of localizing your app from English to Spanish, you will be localizing it from functional English to polished English.
Developers maintain your application and its prompt catalog in functional English. They don’t need to worry about fine tuning the language, UI/UX and marketing will take care of that, but instead use a description of what the prompt should say and where it appears. So “Signup Today” becomes something like “[home/signup] Signup Button”. This isn’t pretty to look at, but the idea is to give other people the information they need to do their job (prompt description, location, inventory code, etc).
Meanwhile, UI/UX, marketing and others maintain the polished English “translations” via a localization management tool (I recommend Transifex). These tools function in a similar manner to source code repositories, and enable people to edit and maintain translations from the master language into other locales, track progress, etc. They never have to touch the application source code, so less technical people can safely make changes to wording with a lesser risk of introducing bugs. Likewise, developers aren’t burdened with making tons of minor changes every time someone decides to move or reword a link somewhere. UI/UX can just change the en-US localization from en-DV and the changes will be carried over in the next build.
The real benefit of doing this is that in the process of doing this for your home language, you will be setting yourself up so that if you decide to add new languages and locales, you are already prepared to do so with incremental effort and cost. It’s a bit of a hack, but it’s one that can save you a lot of money and hassle should your app prove to be popular in other markets. If its popular in your home market, it will probably develop a following elsewhere, and even if you remain in your home country, it’s often a good idea to support other languages such as Spanish in the US.
