Localizability and World-Readiness for Software, Part Two

In part one of this series we looked at the overall goals of software localization and some of the distinct processes involved. In this part, we’ll examine why context is king in software localization.

It might seem obvious, but the key to a successfully localized software product is allowing linguists to do the best job possible. Even the best linguists need to have a solid understanding of the original product if they are to produce a great translation, and reducing the number of functionality issues relating to world-readiness is one factor that will allow linguists to get the translation right first time.

When it comes to giving linguists what they need to do the job correctly, context is the single biggest factor. In software localization, context is king. Provide as much contextual information as possible, and your product will reap the benefits. The perfect scenario is a full visualization of the UI during translation, but other elements can also be very helpful:

String identifiers (if meaningful) can provide additional context information
Comments from developers can be a great source of information, especially for cryptic UI messages
Length limitation information – note that a “number of characters” limitation will work only with fixed-width fonts. When using proportional fonts, the linguist will need to know the actual width of a string in pixels compared with the length limitation

In examples where localizability has not been built into the development process and where the product manager decides that the product should be sold globally, a developer is often quickly reassigned to produce “translatable” resources. In practice, these developers are very often tempted by easy looking formats like Excel files, where linguists are expected to insert translations into their language’s column parallel to the English string.

Once translation is completed, a developer then needs to copy and paste translations back into the code. It should not surprise anyone to learn that hurried copy and paste operations in an unfamiliar language are rarely done right the first time!

The following is an example of such a translatable file in Excel format:

Software Localization in Excel

As you can see, the developer put a great deal of effort into creating the file and has included useful information, such as where the string is found and maximum string lengths. Although the file might look cumbersome, the developer has done a decent job in this example – it is significantly better than many localization files received as recently as 10 years ago. However, these formats are not easy to process in a translation workflow, and it is important to get developers and localization engineers talking together at the same table to hammer out the available options. In most situations, there are better ways to handle the UI files. Today’s linguistic technologies are far more advanced, and a little forethought can result in a much smoother localization process.

Where should you start? Usually, the best place to begin is the software development framework being used. Most modern software development frameworks provide tools to extract UI content from code and guidelines on how to create code that can be easily processed for localization. These tools produce files in formats supported by translation tools like .resx, .properties, .po, and .ts files.
Processing UI content with translation tools gives linguists access to many advanced features, such as translation memory, terminology databases, and automated quality checks right at the translator’s fingertips as part of the translation environment. These features help speed up the production of high-quality translations.

Some frameworks even enable linguists to preview UI while translating. This is usually the best possible scenario – translators see the translation immediately in the right context, they see what type of element is being translated, and they can also see the potential space limitations.
Unified formats for UI translation are a key element in the automation of hand-off/hand-back processes in Agile workflows. Without automation, Agile localization processes cannot integrate with Agile development processes, and there is no automation if formats are not clearly defined.

The following is a preview generated from a .resx Windows Form by a popular translation tool. As you can see, there is plenty of useful information for linguists, including the string ID, development comments as well as a preview of the dialog, which will help linguists understand how a dialog is used and whether there are any string length limitations.

Software Localization

Custom XML files can also be previewed, and because XML files can be easily processed for translation, additional info such as comments about usage or context can also be included for linguists, giving them the best possible chance of getting translations right the first time.