Building software that speaks their language

Categories Development

I’ll share a secret with you: great software has great localization support.

Frankly, this is not really a secret and it’s not just great for your users – having software that can be quickly adapted to any language or culture is a big plus for you and your company.

Writing software that speaks their language is not hard these days, as most frameworks have this support built in, and if your framework or technology doesn’t, it’s time to look for something new.


The infrastructure work of building an internationalizable and localizable product is usually already in place, but using this support is up to you. Most developers tend to treat this subject lightly, but I have found that the investment is well worth it.

Some tips for building applications that can be easily internationalized and localized:

  • Make sure the technology that you want to use has support for easy internationalization and localization. If it doesn’t, and you still want to use it, think about the costs of developing localization support for that technology or framework. If the costs are higher than switching to another technology…switch
  • Localization doesn’t just mean translation. Consider the cultural aspects
  • Always consider bi-directional text, even if exporting to Arab or Asian countries is out of the question now, in the future…who knows. The Internet has made the world a small place
  • Never hard-code date or currency formats, it’s just plain wrong
  • Remember that different locales have different decimal and thousands separators, don’t hard-code these either
  • Keep your strings in an easy-to-translate format. Usually, you’re not the one translating your application strings, which means that your strings must be sent to a translator. If you keep your strings in a complicated format (or hard-coded in your product), you’ll always loose time converting your format to a translator readable (normal human readable) format. Either keep your strings in a simple format, such as a flat text file (think about file format used in Java applications) or use a special translated text management tool
  • If possible, don’t embed your translation file in the binary of your application so that new translations can be easily added without re-compiling and updating. Doing translation update releases just annoys your user base
  • Have a native of the language and culture you are targeting use your application. This way, you can be sure that no critical translation or cultural errors have slipped into your product. Try not to use the same person that translated your text, for easily understandable reasons.

The process of localization may also include presenting your application in a different way or highlighting different features so your marketing approach could change(and it should change) also.

In the process of analyzing requirements and development, I usually try to learn the language and cultural habits myself (and I like to have my team do the same). You don’t have to learn the whole language, you just have to learn the terms used in the specific domain you’re targeting, as this can have an important impact on requirements gathering and even on product development, but more on this aspect in another post.


Featured image by Frankie Guarini

Leave a Reply

Your email address will not be published. Required fields are marked *