• Marianne Calilhanna

Go Agile for Software Content Localization

Updated: Oct 7

Guest blog post by Dominique Trouche, CEO, WhP


Companies work with WhP to improve their localization practices. When asked what their objectives are, adopting agile localization is at the top of their list. They see two major benefits in moving away from the waterfall process. First, localization becomes aligned with the agile processes already in place for software and information development. Second, time-to-market is shortened.


What is agile localization?

Agile localization is an extension of the agile methodology, which has been applied to software design for more than 20 years. With agile, teams work concurrently in scrums and all activities are sequenced in sprints of usually 1 or 2 weeks:

  • Agile software design: new features are designed, tested, and integrated at each sprint.

  • Agile information development: new related content pieces are authored and approved in the same sprint or sprint + 1. Information developers are often members of the development scrums.

  • Agile localization: new related content pieces are sent for translation and delivered in the next sprint (sprint +1 or sprint +2)

Agile localization represents a major evolution compared to the waterfall model, which still prevails. In this model, only complete and approved documents are sent for translation in large and long projects.


Agile localization should not be confused with continuous localization, where both source content and translation are exchanged on-the-fly. Continuous localization means that at some point in time, different versions of the same content piece are being translated, leading to scheduling conflicts, duplicated efforts, and translation inconsistencies.


Externalizing the UI terms goes hand-in-hand with agile localization

For optimal content quality, the standard waterfall software localization process consists of several steps:

  1. Software freeze: a complete release is selected, thoroughly tested, packaged to be marketed.

  2. Software translation: the corresponding new UI terms are translated into all languages, usually with no or little context.

  3. Software translation validation: the different language versions of the software are generated, and the translated terms are validated in full context.

  4. Documentation translation preparation: software UI translation memory is converted into a term base for translated terms to be provided to the documentation translator.

  5. Documentation translation: documentation is translated into all languages. Correct translation of the UI terms relies on proper semantic encoding and the goodwill of the translator to search for these terms in the term base and pick up the right one when UI terms include similar entries that can be ambiguous.

  6. Translation review: the translation of embedded UI terms is checked by in-country reviewers, usually local SMEs.

This process can take several months, while, with the agile methodology, the translated documentation can be delivered at the latest two sprints behind the software freeze.

Therefore, the only option for agile documentation localization that is related to software is to decouple documentation translation from software translation.


Agile localization for software information, such as online help, customer support or tutorials, is more complex than hardware or process documentation because of the user interface (UI) terms. Decoupling software and documentation translation requires UI externalization:

  1. Creating a reference table with the software UI terms

  2. Linking these terms to the documentation instead of embedding them

When the UI is externalized, content is translated without needing to know if and how the UI terms were translated. The actual UI terms are automatically injected in the documentation when it is published.

Note: Injecting words into a sentence may lead to grammatically incorrect sentences when these words should agree with the rest of the sentence, or the rest of the sentence should agree with the term gender. Since UI terms are neutral and are not updated, this concern is not relevant.


The reference table can be generated:

  • From the content pieces, through an automated scripted conversion process

  • From the software resource files managed by the development teams through an automatic conversion.

Externalizing UI terms increases efficiency and consistency

When the UI is externalized, the expected benefits from agile localization can be achieved: turn-around-time goes from several months to a few weeks, and conflicts over topic versions disappear.


Additional benefits can be expected, as we have demonstrated and measured in several projects:

  • The documentation is consistent with the software application, which is paramount for user experience, especially when information is delivered as contextual help.

  • Since 50% of the queries during the translation cycle are related to the UI translation, these will automatically disappear in an agile localization process.

  • Similarly, 50% of the linguistic review effort, which was dedicated to checking the UI translation, is saved.

  • Content is faster to author: linking a UI term when using Oxygen is three times faster than typing its value.

  • There are fewer words to translate (usually around 10%)

  • The cost of maintenance is drastically reduced: correcting a UI term in English or local language only requires updating the term in the reference table and republishing. This requires at least 80 % less effort than finding the term in the translation memory and retranslating the related content.

  • Please be aware that this process decreases the leverage of the translation memory on the first project since terms (a few words) will be replaced by a tag. However, this loss of leverage can be slightly restored through proper translation memory scripting.

How should you approach going agile for your documentation?

  • Define your ideal process: build the reference table from the content itself or from the software resources managed by your development teams.

  • Evaluate the number and frequency of UI terms in your content.

  • Inform and train the information developers and update your style guide.

  • Run a pilot project to validate the process (from software development to CMS, publishing and finally maintenance)

  • Measure the efficiency increase and the impact on translation memory.

  • After the pilot project, automate your process with software development framework and the CMS or content repository.

  • Measure and share the outcome will all parties who contributed

If you want to decrease your time-to-market by setting up an agile localization process and

if you are managing software related information, you should consider externalizing the UI terms. WhP will cover this topic and other practices related to software localization at the WhP Summit on October the 28th. Register today for this helpful and informative event!


32 views0 comments