Video, dubbing, and subtitles at API speed: a deep dive into the media localization execution layer

A product team ships a feature video, a release note explainer, or an in-app onboarding clip, and the localization step still looks like this: export the final cut, email it to a vendor, wait for a quote, wait again for turnaround, receive a folder of subtitle files back, and manually verify they sync before anyone pushes them to the CDN. Every other stage of the release, encoding, transcoding, CDN distribution, QA, is automated and instrumented. Localization is the one step still running on file attachments and human coordination.

That gap is the argument: media localization, including subtitles, captions, dubbing, and audio description, has to be modeled as a pipeline stage a product team can call programmatically, not a side process a localization team manages by hand after the fact. This is an architecture issue. If your release pipeline treats localization as an external, manual dependency, your global launch dates will always trail your domestic ones by however long the vendor round-trip takes.

What Ollang's media surface actually covers

Ollang is not a subtitle tool bolted onto a translation memory system. It is built as an execution layer that takes a source asset, video, audio, document, image, subtitle file, or strings file, and produces reviewable localization outputs through the same order and project structure across every modality. For a PM, the relevant part of that surface breaks into four order types.

Subtitles and closed captions. This is the widest end of the funnel. Ollang can generate captions from source audio, translate them, and export SRT, VTT, ASS, STL, SCC, DFXP, ITT, DOCX, XLSX, and broadcast-compatible formats. That range matters operationally. SRT and VTT cover web and app players; SCC and DFXP cover broadcast and OTT delivery requirements that many modern subtitle tools drop support for once you move past YouTube-style use cases. DOCX and XLSX exports exist because localization QA and legal review teams still work in spreadsheets and documents, not subtitle editors, so the execution layer must support both workflows.

AI dubbing. Ollang's AI dubbing order type produces multilingual dubbed audio and mixed video with optional lip sync or audio description. It also supports script-only input, TTS-first flows that accept a .txt script with no source video, which is useful when a team generates narrated product tours or training content before the final video cut exists.

Studio dubbing. This is a distinct order category, not a tier of the AI dubbing flow. It routes through Ollang's network of professional voice talent and dubbing studios, and outputs are synchronized, mixed with the original audio bed, and output in broadcast-ready format, including M&E track, stereo, and 5.1 surround. A PM choosing between AI dubbing and studio dubbing is choosing between turnaround speed and production-grade voice acting, and the fact that both are addressable as order types in the same system, rather than one being a product and the other a manual services add-on, makes the choice a pipeline decision instead of a procurement decision.

Audio description. Audio description is treated as its own order type alongside subtitles, captions, and dubbing rather than a checkbox inside one of them. This matters for teams under accessibility compliance obligations who need it addressable independently of whether a video is also being dubbed.

Ollang's own order taxonomy confirms this structure: the platform's documented order types are AI Dubbing, Subtitle Translation, CC, Document, Studio Dubbing, Visual Translation, Website Translation, and the media-specific documentation goes deeper into subtitle export formats, AI dubbing outputs, audio description, and studio dubbing. For a PM the practical read is that these are not features nested inside a video localization product tier. They are independently addressable order types with their own inputs, outputs, and workflows, which is what you need if your release pipeline has to route different video assets differently, for example a marketing launch video that needs studio dubbing and audio description, while an internal training clip might only need machine-generated captions in three languages.

How this gets invoked

The reason this matters for a PM rather than only for a localization ops lead is that the entire order surface above is reachable without a dashboard. Ollang exposes it through APIs, an MCP server, an SDK, and agent Skills, so the same order types available in the project management UI are callable directly from a build pipeline, a CMS webhook, or an AI agent operating inside a coding environment.

Concretely, order creation is a single documented endpoint. The API's order-creation call creates one or more translation orders for a project, and supports order types including closed captions, subtitles, document translation, AI dubbing, and studio dubbing. That means a release pipeline can fire one API call when a final video cut lands in storage, and that call can simultaneously kick off a closed caption order for accessibility compliance, a subtitle order for the app's language switcher, and a studio dubbing order for the three markets where broadcast partners require voice-over, instead of a human filing three separate vendor requests at three different points in the week.

For teams that want agent-driven operation rather than direct API calls, Ollang's MCP server lets coding agents and internal tooling issue these same order requests conversationally, with documented examples as simple as an agent prompt to create a subtitle order for a given project in specified target languages, which the MCP layer translates into the underlying order-create call. Full authentication, request structure, and endpoint behavior are in Ollang's API documentation, which is the reference to check before wiring any of this into a live pipeline.

The subtitle embedding case: shipping an asset instead of a file to manage

One detail in the API surface that is easy to undervalue and worth calling out for PMs is subtitle embedding as its own request type, separate from subtitle generation and export. Most subtitle workflows stop at a file, you get an SRT or VTT back, and someone downstream has to load it into a video editor, burn it into the frame, re-encode, and re-upload before the asset is actually ready to publish somewhere that doesn't support soft subtitle tracks, such as many ad placements, some social distribution paths, and certain broadcast delivery specs.

A subtitle embedding request collapses that work into the localization step, so instead of receiving a subtitle file that becomes a new artifact for your team to track, version, and re-attach to the video asset, the request returns a finished video with subtitles burned into the frame. Operationally, this removes an entire class of downstream file-management work: no separate subtitle file to keep in sync with a video that might get re-cut, no risk of a subtitle track silently detaching during a CDN transcode step, and no additional QA pass to confirm the file loaded correctly in the target player. The video that comes back from the API is the video you publish. Implementation specifics, required inputs, supported source formats, and request parameters are documented alongside the rest of the order and upload endpoints in Ollang's API documentation.

Why this belongs in the release pipeline instead of the localization team's queue

The structural point underneath all of this is simple: every order type above sits behind the same Folder → Project → Order hierarchy and the same programmatic access layer. That means a PM designing a global release pipeline can treat "generate captions in 12 languages," "burn in subtitles for the ad cut," and "produce a studio-dubbed broadcast version" as steps with the same shape as "transcode to H.264" or "push to the CDN edge," API calls with defined inputs, asynchronous completion, and structured outputs, rather than open-ended requests to a vendor inbox.

That shift changes who owns the timeline. When localization is a manual handoff, the localization team's queue determines when a global release ships, regardless of how fast engineering finished its work. When localization is a callable pipeline stage, the release timeline is determined by the same orchestration logic that governs every other build step, order status can be polled, review gates can be inserted where quality requires human sign-off, and the video, caption, and dubbing outputs land back in the pipeline as artifacts ready for the next stage, rather than as attachments that require manual follow-up.

Organizations that get global launches out the same week as domestic ones stopped treating media localization as a vendor relationship and started treating it as infrastructure their release pipeline calls directly.