How to survive multilingual continuous delivery

5 essential questions to agile translations

By Steve Atkin and Anouk Perquin

Goal
This article aims to give insight on the impact on localization and translation processes when software is deployed continuously and addresses the paradigm shift that is required to prevent translation from becoming a bottleneck to rapidly delivering software.

5 things you’ve always wanted to know
* What is Continuous Delivery?
* Why Continuous Delivery?
* How does this impact translation?
* What needs to change?
* What can we learn from Agile software development?

What is Continuous Delivery?

The software industry has been in a revolutionary transition from building software using waterfall and highly structured methodologies to more lean, agile and highly fluid methodologies. Current methodologies look to release continuously and frequently deliver incremental change.

Development teams do this by continuously deploying small functional increments of their product in short time boxed iterations that are commonly known as ‘sprints’ and having people test it through actual deployed use. Teams use the feedback of these users to create the next incremental capability that is also deployed as early as possible.

The effect of this is that instead of spending months to create a huge software release, teams deploy small frequent updates, sometimes multiple times a day.

Why Continuous Delivery?

The advantages of taking this new approach to software development have proven to be:

Minimize the time to market

Business value increases with every day an application is on the market sooner. The sooner you can start selling your product, the sooner it will bring in money.

Minimize the risk and cost

The chance that your application will be more successful increases. This is because, in early stages of product development, user feedback is used to see whether new capabilities will be liked, accepted, and used in the marketplace. This prevents costly development to take place on functionalities that will never be used, as has happened with 80% of software features that were developed in the waterfall processes.

How does this impact translation?

This approach to software development is completely at odds with today’s translation and localization processes. To reach broader markets requires software to be translated into the users’ languages. The need to spend a lot of time and money on translation is often in direct opposition with the desire to minimize the overall cost in creating applications. This is especially apparent when new capabilities are being delivered that are unknown as to whether they will be developed further.

In a traditional waterfall development process translation and localization is often delayed until near product release. User interfaces and most product documentation is generally frozen close to final completion before translation even begins. The translation phase typically becomes a bottleneck for delivery as this process often takes many iterations and requires deep education by the translators to ensure that they have a proper understanding of the context of the application in order to properly translate and localize the software. This means that the overall release time of new capabilities, though already completed in English, are delayed for several weeks or even months, because translations are not yet done.

As in a continuous delivery cycle, the value of what is released is largely determined by the speed that it is deployed, delaying a product release because of translation is unacceptable. This means that translation and localization processes must adopt a continuous delivery model, just like software development processes have, and incrementally deliver translation with minimal human overhead.

What needs to change?

This new way of working now requires us to rethink how translation fits into modern development strategies. Translators need to take on new roles that extend beyond pure translation:

• Translators need to quickly determine and understand the context of an application without having to engage the software development team in lengthy training sessions.
• Translators now need to decide how and when to make use of machine translation and quality criteria needed in order to reach the goal of the content.
• Translators also need to collect and provide early feedback to the development team as it relates to UI design and linguistic implications of features and capabilities.

This means that for teams to be able to capture the wider marketplace beyond English, translators now need to be viewed as peers in the development process rather than as simply external translation providers in order to quickly deliver capability across multiple languages simultaneously.

What can we learn from Agile software development?

Many principles of agile methodologies in software development can be transferred to translation processes in order to comply to the current need for speed.

Maximize the work not done

The notion of translation quality is substantially changing from creating the most accurate translation to creating the translation that has the ‘most value’. The value is defined by the combination of usability and time to market. Clearly define the quality criteria needed in order to achieve ‘minimally viable products’ across the supported languages.

It is important to understand that the notion of ‘quality’ is highly fluid and can vary across both functional features as well as across languages. Also, realize that the first version of a translation that merely complies with the speed asked for by the Continuous Delivery process may only live up to minimal quality criteria and differ from the final version of the translations.

Create and empower multidisciplinary teams

Include the translators in the team so they can participate in how the goals are to be reached when it comes to multilingual deployment and they are aware of the capabilities that are to be translated.

Embrace change

Make sure change is at the core of your process. Content is dynamic and the need to consolidate the source before starting translation unnecessarily delays deployment.

Constantly solicit feedback

Don’t be afraid to publish early versions of your translations. Test whether your content reaches your goals and make sure you can implement feedback easily and quickly.

Conclusion: a paradigm shift

For a lot of people that have been working in the translation and localization industry, it is not an easy step to let go of the traditional processes that have worked well for many years. It is often difficult to allow products that may have imperfect translations to go out, as this is something that seems completely at odds with the high standards that the industry has established. Typically many QA cycles are usually applied before translations are published. These processes have worked well in the past where constant change was less of a factor, but in today’s rapid and shortened development cycles these processes no longer meet current needs.

What we need to realize is that the notion of quality is now more fluid. Our emphasis needs to shift to the concept of usability and the only people that can really tell you whether your content is usable, are your users. The crowd will tell you what you should be spending your scarce time and money on to maximize the user experience.

Practice what you preach

Was this article useful to you? Do you have any questions? What else would you like to know? How can we improve the usability of this article? Your feedback is invaluable to us. Please share it through the medium platform or contact the authors directly through LinkedIn.