Continuous delivery is a good illustration of that evolution. It has become a best practice in the software industry in recent years and is becoming an established norm. In a continuous delivery environment, months become days, and days become minutes. Continuous delivery is all about speed and flexibility: develop, test, debug, translate, release, rinse and repeat.

How do engineering teams achieve that magic? By maintaining complex, multi-branching environments, and working in virtual teams across the globe, yet using centralized resources: one source code can live in an online repository in multiple instances without any conflict, like coexisting time capsules in an ever-changing environment. Each time capsule, or “branch,” contains a snapshot of the code base. Engineers are assigned to perform specific tasks, like fixing bugs or developing new features, only in that branch. When the branch is complete, it’s ready to be merged to the master code, or “trunk,” and be released at the engineering team’s will. This process is extremely flexible, and lets teams release software products — SaaS or mobile, or both — quickly, in a granular fashion.

Product managers love continuous delivery too, because they can meet their customers’ needs so quickly. A new feature can be live in weeks, if not days. Bugs get fixed and released seamlessly. Continuous delivery reduces risk too; by releasing new features incrementally, bugs and other defects are less likely to be left in the code base. Since quality assurance is performed thoroughly right before each release, not months after coding, engineers can more easily spot errors in their freshly-made code.

Faster time to market, better quality, granular control, continuous innovation, flexibility. On paper, there are only benefits in adopting continuous delivery. However, this well-oiled machine can grind to a halt once resource files hit the localization world. The process becomes something like a horse with only two legs — it can limp along, but not very efficiently.

Indeed, continuous delivery methodology presents a challenge for the whole localization ecosystem. And the weakest link is usually found in translation tools. Many computer aided translation (CAT) tools and translation management system (TMS) technologies are not suited to purpose; too many still operate offline and are file-centric. That means enterprise localization project managers and language service providers (LSPs) waste time on low value-added tasks like handling zips and files on local hard drives, fighting version control issues and converting files in order to bridge the gap by passing plates between systems that do not speak the same language. Online repositories and TMS/CAT tools can hardly communicate, which slows the whole process, while introducing the potential for human error. On top of this, the amount of work necessary to process a translation batch is the same, regardless of the number of words to translate: files must be extracted from the online repository and prepared in one tool. Then they are pushed to translators in another tool to be reviewed and have QA applied. Once that’s done, files have to be converted and committed back to the repository. All the while, dozens of emails have been exchanged to monitor the process.

In the end, this compulsory preparation work sometimes takes more time than the actual translation work does. By following this cumbersome process for each branch, LSPs and the software teams that rely on them lose time, money and sometimes patience. There has to be a better way. What could this new world look like?

The essence of continuous delivery is to process software piece by piece. This creates significant overhead work that should — must be — automated. That is a pain point for translators and everyone else involved. Workarounds exist but are inefficient and not a good use of everyone’s time. If engineering can catch up in this speed-oriented environment, so should localization. Another way to crack the whip on LSPs, right? Not necessarily, if they’re provided with the right tools.

In light of these obvious limitations, LSPs are on the brink of a revolution too. Minimum charge is a hurdle in this fast-paced environment. What enterprise would pay $30 for five new strings per language several times a month? Who would wait a week for these strings? Let’s look at the LSP side for a minute. Minimum charge applies for one simple reason: to pay for all those preparation, conversion and file-handling local tasks, which would no longer be necessary with tools that connect translation processes with engineering branches. Bye, bye, minimum charge model. Outdated CAT/TMS technology and the minimum charge model are showing their limits when what matters most is speed and connectivity.

Along with the development of new continuous delivery-friendly CAT tools, LSPs have a unique opportunity to become more software-oriented. Most freelancers work for multiple agencies or clients. Why should they pay for multiple CAT tools? The challenge represents an opportunity for LSPs to join forces and build a SaaS platform that allows both themselves and freelancers to concentrate on their core competency: providing translation services. Using connectivity and open standards, that platform could also post-process and redeliver files to customers through APIs. If such a technology were available, LSPs would spend less time handling projects, translators would be more productive, and the whole process would be more streamlined and efficient. In a nutshell, you would see savings in time and money all the way down the production line.

Continuous delivery can work efficiently only in a highly connected environment. SaaS, open standards, centralized resources, connectivity and application programming interfaces are the keys to bring the engineering and localization worlds together into a more streamlined ecosystem.

The need for speed demands connectivity, which leads to greater efficiencies, more automation and less monitoring. The result? Faster time to market, and big reductions in costs and overhead for everyone involved. But if we want to see continuous delivery’s true capabilities realized, TMS and CAT technology needs to catch up — and catch up quick!