While Agile flows smoothly inside the software dev team, it often stalls when it reaches the documentation team, where waterfall methods prevail. The time gained in working in scrums gets partly lost. Breaking the silos requires adopting a set of tools and methods that will allow you to slash time-to-market and ensure terminology consistency between the UIs and documentation content.

What is agile localization?

It is an extension of the agile methodology which has been applied to software design for over twenty years. With agile, teams work concurrently in scrums and all activities are sequenced in sprints of usually one or two 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 any given time, different versions of the same content piece are being translated. This can lead to scheduling conflicts, duplicated efforts, and translation inconsistencies.

Early adopters of Agile Localization are obviously the companies applying the agile methodology for their software design, and nowadays most companies from all industries integrate software in their offering.

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:

• Software freeze: a complete release is selected, thoroughly tested, packaged to be marketed.
• Software translation: the corresponding new UI terms are translated into all languages, usually with no or little context.
• Software translation validation: the different language versions of the software are generated, and the translated terms are validated in full context.
• Documentation translation preparation: software UI translation memory is converted into a termbase for translated terms to be provided to the documentation translator.
• Documentation translation: documentation is translated into all languages. The correct translation of the UI terms relies on proper semantic encoding and the goodwill of the translator to search for these terms in the termbase and pick up the right one when UI terms include similar entries that can be ambiguous.
• Translation review: the translation of embedded UI terms is checked by in-country reviewers, usually local SMEs.

This process can take several months, while in the agile model, the translated document 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 into 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:

• 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 maintenance)
• Measure the efficiency increase and the impact on translation memory.
• After the pilot project, automate your process with a software development framework and the CMS or content repository.
• Measure and share the outcome will all parties who contributed

Full-agile processes for localized software and related documentation require strategic steering, and organization and metholodogy changes.  They are key to significantly improve time-to-market and consistency.