# video-translator is an OpenClaw skill that delegates dubbing to a remote API

> video-translator is a skill definition for OpenClaw that accepts one video, submits an asynchronous job to a hosted translation service and polls it until a preview URL comes back. The heavy lifting, from background separation to voice cloning, happens on the service, not in the skill.

**InsiderX-Pro/video-translator** — Real time video translation / dubbing skill

- Repository: https://github.com/InsiderX-Pro/video-translator
- Stars: 812 · Forks: 1
- Language: Shell
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/insiderx-pro-video-translator

## A skill definition, not a translation engine

video-translator is described as a skill for OpenClaw to translate and dub user videos via an online service and return a preview_url. That single sentence defines the whole architecture, and it is worth pausing on where the work happens.

This repository contains no speech recognition, no translation model and no audio processing. It is a specification of behaviour plus a thin client. The repository layout shows it: a SKILL.md file holding the skill behaviour and invocation rules, an agents directory with an openai.yaml for agent metadata, a references directory with an API contract document, a scripts directory holding a quick test script, an assets directory for the README diagrams, and a Chinese-language README with its own diagrams.

The runtime requirements are correspondingly small: curl and python3.

So the pipeline is a set of instructions to an agent, plus HTTP calls. The agent accepts the input, calls the service, waits, and hands back a link. Everything expensive happens on the far side.

That has an obvious upside and an obvious cost. The upside is that the skill needs no GPU, no model weights and no audio toolchain, so an agent that can run curl can dub a video. The cost is that the skill is only as good as the service behind it, and the service is somebody else's.

This is a different category of project from a self-hosted pipeline, and it should be evaluated as one: you are adopting a client and a contract, not an implementation.

## The pipeline that runs server side, in eleven steps

The README describes what the service does with a video, and the list is where the real complexity sits.

Step one accepts a local video file or a video_url. Step two runs preprocessing, background separation, speaker diarization, ASR, translation, voice cloning, dubbing, subtitle rendering, and the final mix and composition.

Read that sequence as the actual technical content of the service. Background separation is what lets the spoken voice be replaced while the original audio bed is kept. Speaker diarization assigns the transcript to speakers, which is what makes a multi-speaker interview translate sensibly. ASR produces the transcript, translation turns it into the target language, and voice cloning produces a synthetic voice in that language for the dubbed track. Subtitle rendering and the final mix put everything back together.

Two things are worth noticing. The first is that the skill takes no options for any of this. There is no mention of a quality setting, a speaker selection, a voice choice, a timing alignment parameter or a retranslate option. The skill's interface is one input and one output, which keeps the agent instructions simple and puts every such decision inside the service.

The second is that the language coverage is not symmetric, which is discussed further below. Speaker diarization, voice cloning and subtitle rendering are all language-dependent operations, and the set of source languages is considerably wider than the set of targets.

## Submit, poll, return a preview_url

The control flow is three HTTP calls against a fixed base URL.

The base URL is https://audiox-api-global.luoji.cn, and the endpoints used are:

```bash
GET /video-trans/health
POST /video-trans/orchestrate
GET /video-trans/jobs/{job_id}
```

The health endpoint is the obvious first call when you are setting the credential up. The orchestrate endpoint submits the work as an asynchronous job, and the jobs endpoint is polled by job_id until the job finishes.

The contract has two outcomes and they are symmetric in the documentation. On success the skill returns the final preview_url. On failure it returns the API error text directly. There is no retry policy, no timeout rule and no partial result described anywhere in the README, which means those decisions are left to the calling agent or to the service.

The workflow numbering in the README puts the acceptance of the input first, then the processing pipeline, then the submission and polling as step three, and the return of preview_url or the error as step four. The skill accepts exactly one input source, either a video file upload or a public video URL, which is a deliberate simplification: there is no batch mode described.

The practical consequence for a caller is that the skill is asynchronous all the way through. The agent that invokes it has to be willing to poll, and the returned value is a URL to a preview rather than a local file. Anything that expects a finished artefact on disk is not what this skill returns.

## Target languages are limited to two, source languages to eight

The language rules are the most concrete part of the contract, and they are asymmetric in a way that will bite anyone who assumes otherwise.

Supported target languages are zh for Chinese and en for English. The README is explicit that only Chinese and English are valid target languages. If the user specifies a target language it is converted to ISO 639-1 and sent as targetLanguage, and if the user does not specify one, the default is en.

Supported source languages are wider: en, zh, ko, ja, fr, ru, es and de, each converted to ISO 639-1 and sent as sourceLanguage.

The defaulting rule for the source language is the detail to remember. If the source language is omitted, the skill uses sourceLanguage=zh when targetLanguage=en, and sourceLanguage=en when targetLanguage=zh. In other words, the default pair is always Chinese to English or English to Chinese, and any other source language has to be stated explicitly by the user.

That rule is sensible for the common case, and it has a failure mode: a request that omits the source language for a Korean, Japanese, French, Russian, Spanish or German input will be sent to the service as Chinese. The skill does not detect that, and the error, if any, comes back as the service's error text.

Subtitle behaviour is configured with two flags. show controls whether subtitles appear in the output video and defaults to false. bilingual controls whether they are bilingual and also defaults to false. For bilingual subtitles the README says to send both show=true and bilingual=true.

## One credential, and an error path that points at a website

Authentication is a single environment variable, VIDEO_TRANSLATE_SERVICE_API_KEY, and the key is sent as a bearer token:

```bash
Authorization: Bearer <api_key>
```

That is the whole credential surface, and it is a single point of failure for any deployment: there is no per-user identity, no scoping of the key to a project, and no documented mechanism for rotating it without restarting whatever holds the environment.

The error handling section is unusual and worth reading twice. There are two named failure cases, a missing or invalid API key and insufficient token, and both of them direct the user to a website: https://luoji.cn for users in China and https://luoji.cn?lang=en-US for users elsewhere. Any other failure returns the API error text directly, with no interpretation.

So the skill's own error taxonomy is a purchase or top-up flow rather than a technical error handler. That is a strong hint about how the service is metered, since a token balance is a pre-paid concept, and it means the person who sees the error message needs to know that a token exists and where to buy more of it.

The repository also ships scripts/curl_examples.sh as a quick test script, which is the sensible first thing to run when setting up, because it exercises the real endpoints without needing an agent in the loop.

## Where this skill is the wrong tool

The constraints come from the design and they are hard limits rather than rough edges.

First, your video leaves your machine. Every input is uploaded to a hosted service at a specific domain, and there is no local mode, no offline path and no way to point the skill at your own endpoint, since the base URL is fixed in the README. For anyone handling footage that cannot be uploaded to a third party, this skill is simply not usable, and the licence and the fact that it is MIT do nothing to change that.

Second, the target language set is two. Producing a Spanish, Japanese or Arabic dub is out of scope for the skill, and while the service may support more, the skill will not request them, and the rules describe the two as the only valid targets.

Third, there is no control surface. No options for speaker selection, voice choice, timing, subtitle styling or quality are described, so anything of that kind is decided by the service rather than by you.

Fourth, the skill is thin enough that adopting it means adopting the service. There is no offline fallback, and the error path routes users to a commercial site rather than to a status page or an alternative implementation.

On maintenance, the facts are modest. The repository is not archived and the last push was on 2026-06-17, which is a little over four months ago and therefore recent enough to show the work is live. There are no GitHub releases, so there is no version to pin, and the behaviour that matters lives in the remote service rather than in the code you would pin. The licence is MIT, so the client code is free to reuse and modify, but that freedom does not extend to the service on the other end of the connection.

## Conclusion

Teams building an OpenClaw agent that needs to produce dubbed or translated videos on demand should adopt this skill, because it handles the job submission, polling and preview URL flow with a single credential and a documented API contract. It is the wrong choice if your videos cannot leave your network, since every input is uploaded to a hosted service, and it is the wrong choice for languages beyond Chinese and English, which are the only supported targets. Before deploying, confirm your credential works against the health endpoint, decide who is allowed to upload what, and read the API contract in references/api-contract.md rather than relying on the README alone.

## FAQ

### What does the video-translator skill do with a video?

It accepts either one uploaded video file or a public video URL, submits an asynchronous job to the remote service with POST /video-trans/orchestrate, polls GET /video-trans/jobs/{job_id}, and returns the final preview_url on success or the API error text on failure.

### Which target languages are supported?

Only Chinese, as zh, and English, as en. The skill converts a user specified language to ISO 639-1 and defaults to en when the user names none. Source languages are broader: en, zh, ko, ja, fr, ru, es and de.

### How is the API key supplied to video-translator?

Set the VIDEO_TRANSLATE_SERVICE_API_KEY environment variable. The skill sends it as an Authorization: Bearer header. A missing or invalid key is reported with a pointer to the service website, and an insufficient token balance is reported the same way.

### What does video-translator need to run?

Only curl and python3, plus a service API key. The processing itself, including background separation, speaker diarization, ASR, translation, voice cloning and dubbing, runs on the remote service, and the repository includes scripts/curl_examples.sh as a quick test script.

## Sources

- [InsiderX-Pro/video-translator on GitHub](https://github.com/InsiderX-Pro/video-translator)
- [Issues](https://github.com/InsiderX-Pro/video-translator/issues)
- [License: MIT](https://github.com/InsiderX-Pro/video-translator/blob/main/LICENSE)
- [README](https://github.com/InsiderX-Pro/video-translator/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/insiderx-pro-video-translator