From ticketing system to callable infrastructure: two competing models for enterprise localization

A product manager doesn't lose sleep over translation quality. Modern AI models are good enough for most use cases, and many vendors claim parity on that front. What actually derails a roadmap is timing: the feature is code-complete, QA has signed off, and the launch is blocked because the German and Japanese strings are still sitting in a translation queue with no committed delivery date. The bottleneck was never linguistic. It was operational.

The fork in this market is not which vendor has the sharpest model or the widest language list, most will converge on "good enough" within a product cycle or two. The fork is between two different operating models: a file-a-ticket-and-wait workflow that vendors have bolted AI onto, and infrastructure that lets your product systems and AI agents call localization programmatically, inside the same loop where you build and ship.

The legacy model: localization as a ticket

The traditional TMS (translation management system) workflow follows a pattern most PMs know by heart: someone files a request, the request enters a queue, a project manager on the vendor side triages and assigns it, translators work the files, and eventually a package comes back that engineering has to manually re-integrate into the codebase, CMS, or video pipeline. Even when the vendor has added an AI layer for first-pass translation, the underlying shape of the process hasn't changed, it is still a discrete project with a start, a queue position, and a handoff back to your team.

This model was built for a world where localization was episodic: a big product launch once a year, a website relaunch, a handful of markets. It was not designed for the cadence of continuous deployment, where copy changes weekly or daily and every merge is a potential localization event. Bolting an AI translation engine onto a ticket queue makes the translation step faster. It does nothing to remove the queue, the manual re-integration, or the coordination tax that PMs absorb every time a request crosses a team boundary.

The structural alternative: call-as-a-service

The alternative is not a faster ticket, it is removing the ticket entirely. In a call-as-a-service model, localization is not a project you request, it is a function your systems invoke as part of an existing event: a content publish, a build, a merge to main, a CMS save. The request happens programmatically, the work is orchestrated automatically, and the output lands back inside the same system that triggered it, without a human filing a request or manually reassembling files on the other end.

This is the structural approach Ollang is built on. Ollang ships translated content through APIs, MCP, automation, and CI/CD pipelines, so localization runs inside the deployment workflow you already trust. For a PM, the result matters more than the mechanism: localization stops being a separate workstream that has to be scheduled, staffed, and chased, and becomes a step that happens automatically wherever content already flows.

In practice, Ollang sits at three points in the stack that a PM interacts with.

In the pipeline, as infrastructure. Ollang connects the tools you already use, content sources, dev platforms, and delivery targets, into one localization workflow, so content flows in, routes through review, and ships back automatically, without changing how your teams work. The CI/CD integration point is a merge or a content event triggering localization the same way it triggers a test suite or a deploy.

Inside agent workflows, as a callable skill. The SKILLS layer is designed to be framework-agnostic, and once connected to an agent, the agent can use Ollang capabilities on the fly. The agent can understand the tech stack and workflow context, then trigger the right multimodal localization actions accordingly. This is what "agent-native" means operationally: an AI coding agent that's already touching your i18n files can call localization directly, rather than flagging a task for a human to route to a vendor portal.

On the business side, as a governance surface, not a re-entry point. Review, approvals, publishing, and visibility run from a visual workspace, so quality and sign-off happen on the same engine, with no engineering handoff required. Localization review does not require a second system of record. The same asset that was localized programmatically is the one a native reviewer approves, not a copy that has to be re-uploaded somewhere else.

Why "English-first by default" is the real problem

Underneath the workflow question is a structural issue: most AI agents and applications are English-first by default, and localization gets treated as an afterthought bolted onto the end of the build, not a property of the system itself. Ollang frames the problem this way: many AI agents, apps, and workflows assume English and offload the rest to a separate team or pipeline.

That offload is exactly what a ticket-based model formalizes. It takes an assumption baked into how software gets built, English first, translation later, and turns it into an organizational structure: a separate team, a separate queue, a separate deadline that has to be negotiated against the product deadline. Infrastructure that lets systems call localization inline does more than make translation faster, it removes the structural reason localization gets treated as separate in the first place.

A concrete scenario: the feature flag that ships multilingual

Consider a feature flag rollout. A PM's team ships a new onboarding flow behind a flag, with copy changes across a dozen UI strings. In the ticket model, someone has to notice the new strings, extract them, file a localization request, wait for the queue, receive translated files, and manually merge them back before the flag can be safely enabled for non-English markets. That coordination overhead routinely adds days or weeks to a launch that's otherwise code-complete, and it falls on the PM to track, not on engineering.

In a call-as-a-service model, the merge event itself is the trigger. The i18n files are scanned, localization is invoked through the API or SDK, translated strings are generated and routed through the review gate the team has configured, and the flag ships with multilingual copy already in place, no ticket filed, no vendor portal, no manual file reconciliation. The PM's job shifts from chasing a request through a queue to configuring the review and quality gates once, and letting the pipeline run.

What changes organizationally

Fewer handoffs. Every handoff between teams is a place where a launch can stall waiting on someone else's queue. Removing the ticket removes the handoff, not just the wait time inside it.

Faster market entry. When localization is a pipeline step instead of a project, the marginal cost of adding a new language to an existing feature drops sharply because the infrastructure to route, translate, and review already exists. Expansion into a new market becomes a configuration change, not a new vendor engagement.

Less coordination overhead for PM teams specifically. PMs don't manage translators. They manage timelines, and in the ticket model a large share of that management time goes into tracking a process that lives outside their systems, checking on vendor status, re-litigating turnaround estimates, and chasing file re-integration. Infrastructure that lives inside the deploy pipeline removes that tracking burden because the status of the work is visible in the same systems the PM already monitors.

The closing argument

The comparison is whether localization behaves like a request you make of another team, or like a capability your own systems already have. A TMS with an AI model attached is still, structurally, a queue, and faster translation doesn't change the fact that a human has to notice the need, file the request, and manually re-integrate the result. Infrastructure that's callable from a pipeline or an agent removes the queue itself, and with it, the coordination tax that PMs have quietly absorbed for years as the cost of going global.

That is the decision in front of a product organization evaluating this category: which operating model you want localization to run on for every release after this one. Once localization is something your build pipeline calls rather than something your team requests, the question of "how fast is the vendor's queue" stops being relevant, because there isn't one.