The Localization Blog

In this blog we want to talk about localization in software development. We will explore techniques, tools and best practices in software localization that help you avoid the pitfalls of localization and deliver great products to an international audience.


Coding with localization in mind

Feb. 2017

Localization is usually not as complex as it is sometimes presented. All modern development environments support localization and provide the necessary infrastructure to separate strings to be translated from code.

Localization support is integrated directly into .NET Windows Forms, ASP.NET, WPF and all other .NET target platforms. It can be activated with a few clicks in Visual Studio and usually requires you to insert all your strings into resX files, which are then compiled into satellite assemblies.

Angular offers the i18n attribute to highlight text to be translated, and the xi18n tool to extract these strings to an XLIFF file for translation.

So far so good, but the best platform support is useless if the localization is an afterthought. We've seen many projects over the years that have been developed without localization in mind and then inevitably run into trouble when another language needs to be supported. If all your strings are somewhere in your code, unmarked and not separated, adding a new language becomes a real challenge. Finding all strings and changing or moving them to separate files is almost impossible in a larger project and will almost certainly cause many errors that only your customers will find.

So when it comes to localization a good start is everything. Think about localization before you start coding! And follow these simple rules:

  • Never put any stings into your source code. ALL strings must be placed into separate files (resx files in case of .NET) or marked for localization (i18n in case of Angular). This rule also applies to formatting strings and constants to be displayed as they also need to be translated.
  • Always use the possibility offered by the platforms to name strings with unique ID's.  Come up with a good naming convention for string ID's and stick with it throughout the project. The ID if often a real helpful (sometimes the only) clue for the translator to get some context. It makes a huge difference if a strings is used in a menu, as a label or in a button.
  • Do not use concatenated strings built at run time. Concatenated strings are difficult to localize because they often assume the grammatical order of the invariant language that does not apply to all languages.
  • Avoid using images and icons that contain text or other content that may need to be localized. They are cumbersome and expensive to localize.
  • Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space.
  • Localization is something the client or presentation layer should take care of. It is good practice to keep localization out of the data access and business logic layer and this way avoiding to localize the backend services. This means for example that these layers will only return error codes with error texts in the invariant language. All unhandled exceptions raised in lower layers need therefore be cought by the UI layer to display a localized error message.

Visual Studio and Localization

Nov. 2016

Visual Studio is a very productive development environment but with regards to localization if offers very little. Localizing in Visual Studio is possible by creating resource files (.resX files) for the different target languages and then translating the Windows Forms (C# or VB.NET) or ASP.NET pages (.aspx files). 

Drawbacks when you localize directly in Visual Studio

  • Localizing directly in Visual Studio means generating lots and lots of .resX files that are hard to manage in Visual Studio and often make Visual Studio become slow and instable.
  • No change management for resource strings. In Visual Studio you don't know which string have been changed or added with each new release of your software. To prevent errors all translations have to be verified with each release.
  • No support for a localization process. Software products have a life cycle and with each new release the localization has to be performed again. Without support from a tool this can be a daunting task.
  • Outsourcing translations is cumbersome.

Advantages of using a localization tool

  • Good localization tools support a localization process that becomes part of the general release cycle.
  • The tool keeps track of the translation status of each string. When changing or adding new strings these will be clearly marked as to be reviewed and/or translated.
  • Separation between coding and translating. Developers and translators can work independently from each other.
  • Translations can be outsourced to several external translators in parallel.
  • Support for automatic translations (Google Translator, Azure Translator) and Translation Memory increase the consistency of the translation.
  • Greater productivity when translating due to an environment tailored to translation.