GUI Localization tools have been around for years and they can be helpful when they correctly handle the file formats in question. We used them and know their strengths and limitations. At times, they don’t handle all the file formats that clients require. Many also rely only on the top-down localization process requiring leveraging old translations into new files each time they are used.

With Agile programming, development groups are building code at times as often as once a week. Leveraging translations on a weekly basis using these tools can be time consuming, or error prone if done hastily.

Furthermore, quality assurance time is usually not proportional to the change in the code. There are mandatory steps that need to take place with each build regardless of the number of translated strings. Agile development teams should weigh-in QA time needed not only for the source language, but for all target languages if they seek simultaneous releases.

GlobalVision has many processes in place to help our clients address the localization of GUI files produced by Agile development. Each client however has their own needs and requirements. Although the high level issues presented in this blog may be the same, one process or tool, will not fit all.

When reading this article several questions came into my mind: Why does your client is thinking of creating an internal tool to provide you with a list and location of changed GUI strings? Specialized visual software localization are meeting all these requirements: Automatically detecting changed and new text strings between two software versions and pushing these text strings to the translation vendor, of course including the GUI context. These processes can be integrated into automatic built server environments. So no need to think about a file prep process, missing context, or identifying translatable strings.

The externalization of software strings as part of the internationalization of a software is not related to agile development processes. It must be done anyway to ensure a proper and successful localization. Software manufacturers are usually testing the localization readiness before sending a package to a translation vendor. When implementing agile development processes these basic internationalization tests should be part of each sprint. This objection is also true for quality assurance. A (translated) software that is released to the client should be tested regardless which development method you are using.

The interesting questions are related to the costs, but it’s not only about min fees of translation vendors. First of all software manufacturers must evaluate if the implementation of agile localization processes are economically worthwhile. Some useful answers were presented at the Localization World 2010 in Seattle in the session “How Do We Create an Agile Localization Process That Can Keep Up with an Agile Development Process?”.

Regarding the localization costs the software manufacturer will decide if it makes sense to localize a small drop. In long running agile developments I assume that preferred translation vendors will be used that already localized the last drop. It’s up to the software manufacturer to negotiate whether a min fee applies or not. Maybe there are also good reasons to rethink the business model between software manufacturer and translation vendor. The session “Continuous Workflow” held at the Localization World 2008 in Berlin has presented a new approach and its results.

I’m personally interested to get in touch with software manufacturers to discuss their experience with agile development and software localization.