Localization is product work now.

What’s changed

Here we are. AI has insinuated itself into every nook and cranny of our work lives. Some AI solutions are plug-in ready, promising and delivering incredible productivity gains. Others need careful setup, grooming and validation before they can be declared a success.

Until now, the steps to set up a localization program involved activating connectors, creating file parsers, configuring projects in a TMS with translation memory and glossaries, setting up QA routines. This was done with an eye towards extracting text from data structures for translation and setting up a work environment for linguists to do their best work. That hasn't gone away, but the investment of time and money when standing up a program has shifted upstream and morphed into a branch of product development.

Here is an example to illustrate what we mean. Do you need a high volume of images with embedded text localized? You have a few options. You could ask a language service provider (LSP) to do it, which would entail text extraction, DTP, and a translation workflow. Or you could consider an AI-oriented approach, which requires setting up a sandbox, identifying test artifacts, and model refinement. One of those approaches is, in our experience, roughly 50x - 100x more expensive (and slower) than the other.

Further, the AI-oriented route often involves software engineers and IT. While a solutions architect at an LSP largely has agency to do all the configurations, AI projects require a place on the roadmap. Which means a product requirement document (PRD), grooming, and sprint planning. This is what we mean by 'upstream'.

There are plenty of other examples: evaluating neural machine translation vs AI translation against agreed quality metrics, evaluating automated QA vs human post editing, setting up orchestration to route data in the most efficient and affordable manner, gradually moving to a data lake to derisk over-reliance on a given TMS.