From ticket queue to pipeline: a playbook for migrating enterprise localization to a programmatic execution layer

A product manager shipping a quarterly release to twelve markets does not lose time translating. They lose time waiting: filing a ticket, waiting for a vendor portal to pick it up, waiting for a project manager to scope it, waiting for translated strings to come back as a spreadsheet that someone then has to re-import by hand. Multiply that by every string added after the ticket was filed, and localization becomes the thing that either delays the release or ships two weeks after everything else, as a patch.

This is an architecture problem rather than a translation quality problem. Manual localization workflows assume translation is a discrete project with a start and end date. Continuous software delivery has no such boundaries, strings change daily, sometimes hourly. The fix is not a faster vendor. The fix is removing the ticket queue entirely and replacing it with a pipeline, an execution layer your build process calls directly, the same way it calls a test suite or a linter.

The playbook uses Ollang's SDK, continuous i18n tooling, and a review-gate model as the concrete mechanism. It is written as an implementation runbook for a product team that already wants to stop using manual requests and needs the sequence, not the pitch.

Where this actually sits in your stack

Before the phases, it helps to know what you're wiring in. Ollang exposes four integration surfaces, and picking the right one for each part of your workflow matters more than picking a favorite: programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, API-key authenticated, plus a hosted Model Context Protocol server using OAuth 2.0 and PKCE that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. For this migration, the piece that matters most is a TypeScript/Node.js SDK for asset scanning, i18n workflows, CMS capture, and a typed REST client.

Operationally, the SDK and API sit alongside your existing repo and CMS rather than replacing them. Content stays where it lives, in your i18n files, your CMS fields, your video and document stores, and Ollang's layer scans, routes, translates, and writes back. The organizing model underneath all of it is documented as the Folder → Project → Order hierarchy, which is worth reading before you integrate, since it determines how your teams, markets, and content types map onto the system. Full detail lives in Ollang's API documentation.

Phase 1: inventory and map to folder/project structure

Every migration starts with knowing what you actually have. Most product teams underestimate their string sprawl, a handful of en.json files, a few hardcoded strings that never made it into the i18n system, marketing copy embedded in a CMS field, help-center content nobody remembers to update.

Run the SDK locally against your project root. It scans i18n files (JSON, YAML), hardcoded strings, videos, images, and audio, then shows a Kanban board (Scanned → Translating → Translated → Submitted) so you can see the full inventory before committing anything. Configuration is a single file, ollang.config.ts, where you set projectRoot, sourceLanguage, targetLanguages, and video translation type. This is also where you decide the shape of your Folder/Project structure, for example one Folder per product line and one Project per platform or repo, so that Order-level activity later maps cleanly onto how your teams actually organize work.

If content lives outside the codebase, a Strapi-backed help center or a marketing CMS, the SDK's browser capture handles that: select a folder for local project content, and for CMS content, add the Browser SDK to your site. That gives you a single inventory across code and CMS instead of two separate migration efforts.

The output of Phase 1 should be a scanned, categorized map of every translatable asset, sitting in the Folder/Project structure that will host all future automated syncs. Nothing gets translated yet, this is the audit that makes the rest of the migration possible. Configuration details and troubleshooting for scan paths are in the SDK quickstart.

Phase 2: wire continuous i18n instead of batching at freeze

This phase removes the ticket queue. Instead of exporting a batch of new and changed strings at release freeze and filing a request, new and modified content syncs automatically as it's committed.

Ollang's documentation describes this pattern directly as continuous i18n, covered as one of the platform's end-to-end walkthroughs: AI dubbing, subtitle pipelines, document localization, visual translation, audio description, continuous i18n. In practice, the scanning and submission step from Phase 1 stops being a one-time event and becomes part of your normal build or CI process. New strings are detected, diffed against what's already been translated, and sent through automatically rather than waiting for someone to notice they've piled up.

For teams building this into CI/CD, the relevant reference points are the same ones that govern any programmatic integration: API keys, callbacks, retries, pagination, error handling, folder structure, and memory, along with base URL, authentication, request/response format, pagination, errors, and callbacks, documented in one place in the API reference. Translation memory and custom instructions carry across syncs, so a string translated in sprint three doesn't get re-translated from scratch in sprint four, it is matched and reused and only the delta gets processed. That's the mechanical difference between "batch project" and "continuous pipeline", the unit of work shrinks from a release to a commit.

Phase 3: tier review by market risk, not by habit

The instinct in a manual workflow is uniform review, every string and every market goes through the same human check because there's no cheaper alternative once you're already paying for a vendor relationship. A programmatic layer lets you tier that decision deliberately.

Ollang's model documents this as a Levels distinction, AI-only versus AI plus human review, editor interface, assignments, QC annotations. For a product team, the practical application is straightforward. High-visibility markets, where a mistranslated button label or a broken legal disclaimer creates real support and reputational cost, get routed through a Level 1 review gate, where a native-speaking reviewer signs off before anything ships. Lower-risk locales, or lower-risk content types within a market, internal tooltips or low-traffic help articles, ship on AI-only output.

This acknowledges that not every string carries the same blast radius. The review-gate assignment happens at the Folder or Project level, so once it's configured, new strings inherit the right review path automatically instead of requiring a human to triage each one. Detail on how AI-only and human-review paths differ, including editor assignment and QC annotation behavior, is covered under the platform's review workflow documentation.

Phase 4: close the loop with webhooks and callbacks

The single biggest time sink in the old model is the handoff back. Someone downloads a completed file from a portal, reformats it, and merges it into the repo or re-uploads it to the CMS by hand. Every manual handoff is a place where a release can stall waiting on a person's calendar.

Webhooks close that loop. Ollang's API surface explicitly includes programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, meaning completed translations, whether AI-only or post-human-review, can trigger a callback that writes the result directly back into your repo via pull request or directly into CMS fields via the same Browser SDK connection used for capture. Production guidance on this, including callbacks, retries, pagination, and error handling, is documented so you can build retry logic that doesn't silently drop a locale if a callback fails mid-sync.

Once this phase is live, the operational shape of the team changes. No one is manually checking a vendor portal for completed work. Translated content simply appears in the build, gated only by the review tier assigned in Phase 3. The API documentation's callback reference is the place to work out the retry and error-handling logic before this goes into a production CI pipeline, a dropped callback on a legal disclaimer string is a worse failure mode than a slow one.

Phase 5: prove quality held steady

Migrating off manual review triggers a legitimate question from stakeholders, did quality drop when the human-in-the-loop step got selectively removed? This is where the migration needs measurement, not reassurance.

Ollang's platform tracks AI QC across accuracy, fluency, tone, and cultural fit, human QC annotations, QC score progression and human-edit-percentage analytics. For a product team running this migration, the useful comparison is longitudinal, track QC scores and the percentage of AI output that human reviewers actually edit, before and after moving a given locale from Level 1 review to AI-only. If human-edit-percentage stays low and QC scores hold across the transition, that is evidence the tiering decision in Phase 3 was calibrated correctly, a monitored one rather than a one-time judgment call. If a locale's edit-percentage climbs, move it back to a review gate. Order-level analytics covering this progression are documented under the analytics reference.

The argument this playbook is making

This migration matters because localization stopped being schedulable when continuous deployment became the norm, and a workflow built around discrete projects and manual handoffs cannot keep pace with a release cadence measured in days rather than quarters. Treating localization as callable infrastructure, scanned, synced, tiered, and measured the same way you'd treat any other build dependency, is the model that scales with how software actually ships now. The five phases are the sequence for making localization stop being a release-blocking event and become a build step that runs.