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.