Our Analysts' Insights

Our current research into continuous localization shows that the lines have begun to blur between what it means for localization teams to support a traditional Agile model versus one that is more continuous. However, the 53 people who granted in-depth interviews generally agree that the end result remains similar. Organizations must automate as much of the localization process as they can in order to deliver services for mushrooming volumes of content and code that come to them in ever smaller pieces at faster and faster rates.

Our interviewees identified ten areas that merit attention when considering or implementing (expanded) continuous localization. We share four of them here.
 

Determining How Continuous You Actually Need to Be
 

One of the big mistakes that CSA Research often observes is the assumption that localization must keep up with code and content contributors at all costs. If engineers deliver one or more times a day, you feel that you have to jump. Yet nothing could be further from the truth. Before retooling for continuous localization, we recommend that you take the time to ensure what’s really required to meet customer expectations.
 

Implementing Continuous Localization with a Traditional Mindset
 

Continuous localization is not really about upgrading your TMS and processes to automate manual steps for software strings. It’s about rethinking and re-architecting for handling high-velocity, continuous demand for localization of software, documentation, support, and marketing content. You can’t do that with a traditional mindset hampered by code and content repositories that don’t talk to one another – let alone to your TMS. Don’t try to shoehorn continuous localization into a waterfall model. The worst thing you can do is to attempt to go faster using older, slower ways. And that includes how you purchase and pay for language services.
 

Assisting Continuous Development Teams that Aren’t World-Ready
 

No software development framework has ever been designed with world-readiness as one of its pillars. The gaps in these models continue to lead engineering teams to contest prioritization for enabling proper internationalization throughout a product’s lifetime as they vie for funding and resources. Yet buy-in from these teams is exactly what must happen for an organization to ever claim real success in continuous localization. It’s a no-go when non-globalization-compliant code keeps popping up. This includes globalization compliance requirements for third-party components and newly acquired teams.
 

Solving the Context Conundrum
 

Several interviewees expressed frustration and reservations when it comes to the possible effect of continuous localization on linguistic quality. Rapid and frequent drops of content with zero contextual information to guide the linguist is typical. The high-velocity process tends to defeat the goal of delivering an acceptable global customer experience (CX) – let alone pleasing, high-quality content – if your functional QA team isn’t set up to test localized releases and updates. This happens when feature velocity outpaces localization testing’s ability to keep up. Again, you must balance velocity, turnaround times, and localizing every single drop against the global CX that you deliver. You should also factor in the amount of wear and tear – not only on your internal teams, but on your partners as well.

Continuous content development is no longer limited to software strings. It has expanded to include technical documentation, knowledge base content, marketing material, web content streams, apps – and can really be applied to any category of written content that creators deliver on a continuous basis for translation. Even if your company only supports more traditional and Agile workflows today, you must prepare for the day when teams will require continuous delivery of multilingual content and code.