Translation management in a continuous delivery world

Innovation, speed of deployment and rapid response to customer feedback are key to the success or failure of any new software application launched in the global marketplace. It is well known and well proven that teams able to execute effectively in each of these areas gain a tremendous advantage over their competitors.

Over the last five years we have experienced a great evolution — perhaps it is not overstating to call it a revolution — in development methodologies in response to cloud computing and the ever-increasing demands of speed, rapid innovation and timely response to customer requirements. This evolution has taken many intermediary leaps. It began with waterfall and went through iterative and agile to arrive at the modern methodologies of continuous delivery enabled by DevOps. With this evolution has come a major change in tools, processes, and the very culture and personality of software teams.

DevOps, combined with continuous delivery, is a business-driven software development approach to taking a new business capability from idea to production, providing value to the customer as rapidly as possible, and capturing and responding to customer feedback as they engage. Employing lean and agile principles, DevOps, as a practice, is all about integration, collaboration, rapid iteration and perhaps most importantly, culture — meaning how individuals work together — as well as the tools they use to build, test and deploy. In short, DevOps is about accelerating time to value for both the customer and the development team. Application developers and product managers (indeed every stakeholder involved in the software development business) are embracing DevOps to rapidly innovate and get new capabilities to their customers with speed and quality.

Just as software development has evolved, translation processes and technologies in the last decade have transformed as well. The impetus for this transformation is two-pronged. First, to accommodate the new requirements of development organizations, and second, to take advantage of the unparalleled opportunities to open global markets that the cloud, mobile and social computing provide. In the cloud world, once an application is deployed it instantly goes to everyone in the world whether that is planned for or not. We have witnessed the birth of rule-based machine translation, statistical machine translation and domain-specific machine translation customization. We have witnessed the emergence and adoption of cloud-based translation tools and platforms, translation management application programming interfaces (APIs) and other related technologies. There is no doubt that the industry is transforming and we are in the midst of great change. To a large degree, in spite of all the change we have experienced as an industry, we have not yet made the leap to viewing translation as a core participant in the new practices and methodologies of development teams. Too often, despite incremental changes, translation and translation management remains a siloed, ancillary operation, grounded in waterfall practices, operating from principles outside the DevOps toolchain. In the cloud universe, developers have come to expect that their tools and processes be provisioned through self-service, involve minimal human interaction and be fully integrated and automated. Yet when it comes to translation, many still struggle to find approaches that support the new continuous delivery methodologies and the transition to DevOps.

To break down the silos between development and translation and to bring translation into DevOps, organizations need to recast the values and assumptions they bring to software translation. They need to reconsider such variables as when to translate, when to employ machine translation, when to engage professional translation, when to test and when to release. They also need to take a hard and realistic look at what level of quality is good enough at any particular stage of a product’s life cycle. Just as DevOps is founded on principles of self service; automation; continuous development and integration; continuous test and deploy; and response to continuous customer feedback, translation processes must mirror and embrace these principles to truly integrate into DevOps.

Historically, in an on-premise waterfall world of software delivery, in the absence of DevOps and with the magnitude of features and functions delivered en masse, it was generally too costly and time-prohibitive for organizations to release products more than once or twice a year. In turn, because development schedules were so protracted, there was little desire to integrate or engage in translation activities earlier in the development cycle — there was simply too much flux and change in the translatable content to make it cost effective. Indeed, the very nature of on-premise software delivery necessitated many software development teams having a fixed, highest-standard, one-size-fits-all translation approach, applying the same model and translation plan no matter the application. When you are releasing once or twice a year and burning CDs and mailing them to customers, who in turn must go through an extensive upgrade process, you rarely get a second chance to get it right. When you aren’t releasing a fix pack for another three months, you want to make sure the product (and translation) you are delivering is as “perfect” as possible. And so it became common practice in an on-premise world for software teams and translation stakeholders to establish a fixed translation model at the inception of a project and stick with it through the entire release delivery cycle.

From fixed to flexible and asynchronous

Now, development cycles are significantly shorter, delivery is more frequent, fixes can be delivered in minutes and the notion of versioned software is becoming obsolete. So translation activities, in turn, need to be launched earlier and more frequently, and be integrated into the overall delivery of application features. Additionally, in this DevOps world, organizations must take a more flexible, context-driven approach to how, when and what gets translated to better accommodate the needs of development, while responding to customer requirements and customer feedback. If you don’t get it quite right the first time, very soon (perhaps within a matter of hours of receiving feedback) you will have the opportunity to respond and iterate.

Within the context of this new development methodology, when an organization embarks on a project and is formulating a worldwide go-to-market plan, it can now take a holistic view of the application, weighing such factors as the development schedule, the maturity of an application, the application’s domain, the intended audience (geographic market), the availability of translation memories, human translators and machine translation technologies. With this knowledge, teams can better formulate an overall globalization plan that corresponds to the requirements of the individual project. For example, if a team plans to deliver frequently and the software will have a high degree of flux in features and design, then one would potentially start with machine translation. The same might apply to applications being tested in the market and for which one wants to maintain a lower level of investment until their return on investment is proven. On the other hand, if you are delivering an application that has a high degree of domain specificity or is in a regulated industry, you might hand translation over to human professional translators with subject matter expertise at the outset. If you are deploying software updates multiple times a day, you could potentially use machine translation to translate the new user interface (UI) strings, followed up with human post-editing in the background. A key aspect of this approach is the application of the Observe, Orient, Decide, Act (OODA) loop philosophy that enables teams to manage risk by constantly observing and reacting quickly to how well or poorly the translation process is working for any given application and how it is being received by customers. This approach enables us to take a macro view of translation on a per application basis, rather than a generalized approach that is broadly applied to all projects.

To successfully employ this transformative approach, here at IBM we proposed a technical solution that enabled us to integrate the translation process into DevOps and manage the translation process automatically and asynchronously apart from the process of writing and deploying code. Development gets to operate at whatever frequency they like, while translations (whether by machine or human or a combination of both) are delivered in real-time as they become available — without impacting the development team and their development cycles.

The technical solution consists of three key components:

1 Common core RESTful APIs to manage translation processes.

2 Cloud-based interactive dashboards to provide real-time insight into the APIs and tooling for translation editing.

3 Programming language software development kits (SDKs) that link to the application to enable automatic translation updates.

Key to the solution is that all translation services (requesting translation, checking status, sending content and retrieving content) are delivered exclusively as APIs and all tooling and SDKs use a common set of services that are delivered as RESTful APIs. The other crucial component to our technology solution is the elimination of file-based translation processes — the requirement to send and retrieve content through files. Instead, our solution utilizes key value pairs encoded in simple Javascript object notation objects. Eliminating the dependency on files enables the delivery of translation updates and changes without requiring developers to recompile, repackage and redeploy their applications.

Additionally, as translatable content is generated, our interactive dashboards provide real-time insight into translation operations through the use of common translation RESTful APIs. When professional translators need to review or edit translated content, their work is conducted and completely managed within the DevOps integrated cloud-based tooling. As translators make edits and corrections the changes are persisted in the cloud and are accessible to all stakeholders (developers, testers and project managers) for further review. These changes become immediately available to running applications that use the translation SDKs without requiring the development team to take specific intervention (recompiling, repackaging and redeploying) on behalf of the application. Development teams need only to worry about the creation of translatable content, while translators have the opportunity to review, edit and test in context, in real time.


As traditional siloed, human- focused, file-based and UI freeze-driven processes struggle to operate at the accelerated rate demanded by DevOps and continuous delivery, it is becoming increasingly clear that translation processes need to evolve. The real question is how best to evolve. There are as many various ways of adapting translation to new development and market realities, as there are software companies, products, markets and translation vendors. Some organizations view this from the perspective of scalability and attempt to find ways to add more resources and tooling to support increasing development frequencies. Others take the view that they will limit how frequently they translate their products by waiting until there is a critical user mass before engaging in translation.

While there are many valid approaches, we would like to present an alternative path — one that embraces the DevOps principles and attributes of self-service, automation and integration, providing the flexibility to tune translation activities and investment to the phase and type of product being developed and to local marketplace needs.

It is understandably difficult to arrive at a translation approach that satisfies the cost, quality and speed-of-delivery concerns of both internal development stakeholders and external customers. It is a challenging balancing act that each organization must undertake to remain competitive and be responsive to the marketplace. Empathy, as many in the software industry have described, is at the core of DevOps — empathy between internal stakeholders and empathy with the customer. Ultimately, it is this empathy — a deep understanding of the needs and perspectives of everyone involved in the software development process — that must drive and inform the future of software translation management, including the processes we adopt, the tools we develop and the culture in which we work.