When organizations shift documentation and localization to the “left,” they start those processes earlier in product development. Ideally, these processes are embedded in design/requirements stages rather than being “bolted on” at release. Done right, shifting left saves money and changes what quality can mean.
What Is “Shift Left?”
The term came from software development, where it describes catching bugs and security issues as early as possible in the development life cycle. “Left” refers to the beginning of a horizontal project timeline: the left side represents design and the right, delivery. Moving code quality checks (or documentation) earlier means problems cost less to fix, since they haven’t been built on a shaky foundation.
Oleksandr Pysaryuk, Senior Manager of Globalization Technology at DevOps platform developer GitLab and a former globalization analyst at BlackBerry, adds a key nuance: rather than shifting a process to the left, think of it as a requirement baked into product design. “If you develop a product, it’s much more expensive to later realize that your customer isn’t buying your product because you haven’t passed the accessibility audit,” he says. Such scenarios, where costly legal, linguistic, or structural remediation must be done across a fully built product, are what “shift left” prevents. (Pysaryuk adds that his employer’s localization process is very much to the left.)
Docs as Code (a methodology that treats technical documentation with the same version-control rigor as software) is similar in that it also places content professionals inside the development loop, not waiting outside for a file handoff.
The Plumbing Problem
Consider an example from Pysaryuk’s career: a company needed documents localized into 15 languages. They phoned a translation vendor, handed over 200,000 words, and negotiated a per-word rate. After a month’s progress, the company’s CTO, who had misgivings based on his deep localization experience, halted everything. Pysaryuk was hired, the vendor contract was terminated, and the next 18 months went towards rebuilding the source documentation process to facilitate translation.
Better processes emerged from that work. But the organization paid twice: once for an approach that didn’t work, and once for the rebuild. Pysaryuk likens this misstep to erecting walls in a house without installing plumbing: “You have to completely undo what you did later if you don’t install it earlier.”
Why Documentation and Localization Are Often Delayed
One persistent challenge of “shift left” technical document localization is that internationalization rarely enters early-stage business conversations. A startup’s minimum viable product tends to be built for the founder’s home market. “Their first goal is not to say, ‘Let’s have international users,’” Pysaryuk says. “Their first goal is ‘let’s have users.’“
That makes sense, until the company tries to enter foreign markets without translated technical documentation and a product architecture that was not designed for localization in the first place. (Note that since localization errors are often content errors, the source writing matters at least as much as the translation of that writing.)
AI Creates New Demands
The most disruptive recent development in technical documentation and localization isn’t organizational; it’s technological. Agentic AI systems now translate millions of words across dozens of languages in timeframes that make traditional vendor workflows look sluggish. “With agentic systems, there is no right anymore,” Pysaryuk says. “Everything’s on the left.”
That sounds promising, but it also poses steep skill challenges. Building an agent, specifying its parameters, evaluating its output at scale: these are new localization and documentation competencies. Pysaryuk offers some advice: “Learn how to think critically. And learn Unicode. And learn your craft, your language skills.”
For instance, the repercussions of terminology choices can linger for decades. Pysaryuk once worked with a team in the mid-2000s deliberating what to call an “application” in Ukrainian, knowing the term would still be in use many years later. That decision required linguistic instinct, historical awareness, deep subject-matter knowledge and a stake in getting the choice right. LLMs (to date) are short on these qualities.
Championing Shift Left
Shift left must align with the organization’s financial and strategic goals. When framed properly, documentation and localization are not cost centers. Instead, they are revenue enablers. Stakeholders should ask a key question: what does it cost to document and localize a fully finished product? Another question is what changes if these processes are built into design and requirements from the start. These answers often reshape decisions quickly.
Smaller organizations may think “shift left” only applies to enterprises with dedicated teams. However, AI-powered agentic systems have changed that assumption. Small teams can now run content through localization pipelines. These once required large vendor relationships five years ago. The catch is human expertise, which remains essential. Agentic output follows the Pareto principle. About 80% is usable. The remaining 20% requires linguistic judgment. This includes terminology, cultural nuance, and contextual accuracy. That 20% is what linguists must own.
“Shift Left” Is Not One Size Fits All
The most important takeaway from Pysaryuk’s experience isn’t a tool recommendation. It’s a reframing: “shift left” is a metaphor, and the “left” looks different for every organization.
- For a SaaS startup, left might mean having a technical writer and translator in the room during sprint planning.
- For a manufacturing company entering new regulatory markets, left might mean having internationalization requirements reviewed by a linguist before engineering specifications are finalized.
The logic is the same in every case: the earlier documentation and localization expertise enters the process, the less expensive it will be to achieve quality and the more value the final product delivers to the people who use it.
Do you want to build the expertise to implement technical documentation and localization in your own organization? The TCLoc Master’s Program at the Université de Strasbourg trains working professionals (online and in English) in technical communication, localization, and project management.
