OpenClaw Chinese Translation: A Localized Build of the OpenClaw Personal AI Assistant

What OpenClawChineseTranslation actually is, and who it is not for

This repository is not an AI assistant. It is a distribution layer. The README describes it as OpenClaw plus a fully Chinese interface, with both the CLI and the web Dashboard localized. OpenClaw itself is credited in the README as an open source personal AI assistant platform that runs on your own computer and connects to WhatsApp, Telegram and Discord so you can handle mail, calendars and files through chat.

The audience is narrow and specific: people who already decided they want OpenClaw and who want the command line and control panel in Chinese. If you are still choosing an assistant, this project does not help you decide, because it inherits every one of OpenClaw's design constraints. If you are comfortable with the English CLI, you gain nothing from the fork except a translation sync you now have to trust.

There is a second layer here that is easy to miss. The README points to ClawPanel, a visual management panel with a built-in AI assistant, and ClawApp, a mobile chat client, both under the same publisher. Those are separate repositories. This one is the translation and packaging effort.

How the translation is applied: a CLI that patches, verifies and restores

The mechanism is visible in package.json. The package ships a binary named openclaw-zh-cli pointing at ./cli/index.mjs, and the npm scripts expose four verbs: status, apply, verify and restore. That set of verbs tells you the model. The tool does not reimplement OpenClaw. It inspects an installed OpenClaw, applies translated strings from the translations/ directory, checks the result, and can roll the change back.

The files array confirms what travels in the published tarball: cli/, translations/, install.sh, install.ps1, README.md and LICENSE. The translations live as data, not as a patched fork of every source file, which is what makes an hourly sync feasible. The repository also carries an untranslated_list.txt at the top level, an explicit record of strings that are known to be untranslated. That file is the honest part of the design. A localization project that publishes its gaps is easier to evaluate than one that claims completeness.

The Docker path is different. The Dockerfile does not run the translation CLI at build time. It copies a prebuilt openclaw-runtime.tgz produced by npm pack --ignore-scripts in CI and installs it globally, then runs openclaw --version and openclaw gateway --help as a build-time sanity check. So the image and the npm package are two separate delivery mechanisms for the same localization, and the image depends on CI having already produced the runtime tarball.

Installing the npm package and confirming the translation took

The package requires Node.js 22.19.0 or newer, per the engines field. The README's four-step quickstart states the Node.js prerequisite but is truncated in the available text before the steps themselves, so the commands below come from package.json's script definitions rather than from the quickstart prose.

The package is published as @qingchencloud/openclaw-zh. Install it globally, then run the status verb to see what the CLI detects before changing anything:

npm install -g @qingchencloud/openclaw-zh
openclaw-zh-cli status

status should report the state of the OpenClaw installation it found. If it reports nothing to translate, you are either on a version the translations do not cover yet or OpenClaw is not installed where the CLI expects it.

Apply the translations, then verify:

openclaw-zh-cli apply
openclaw-zh-cli verify

verify is the step that matters. It checks the applied state rather than assuming apply succeeded, and if the result is wrong, restore is the documented way back:

openclaw-zh-cli restore

If you prefer the container route, the compose file pins the image ghcr.io/1186258278/openclaw-zh:nightly and requires a token before it will start, because the environment entry uses the ${OPENCLAW_GATEWAY_TOKEN:?Set OPENCLAW_GATEWAY_TOKEN in .env} form. Without a .env file containing that key, Compose refuses to bring the service up. The first run is not a plain up -d: the compose comments give two paths, a one-line script or three manual commands including openclaw setup and a config set for gateway.controlUi.allowedOrigins.

The nightly tag is the default, and that is a deliberate trade-off

Both the compose file and the README's badge structure point at a nightly build as the normal artifact. The compose image tag is :nightly, the repository publishes a nightly release alongside tagged releases like v2026.9.3-zh.1 and v2026.9.2-zh.1, and a GitHub Actions workflow named nightly.yml drives it. The README states the sync runs hourly and that the localization lags upstream by less than one hour.

That is a coherent choice for a translation layer, because a translation is only useful if it matches the current upstream strings. It is also the main operational risk. A nightly-tagged image can change under you between two deploys with no version number to pin. The compose file acknowledges this by offering a Docker Hub mirror comment for users in China, but it does not offer a stable tag alternative in the text available. If you need reproducible deploys, you are choosing between pinning a dated release tag yourself or accepting that the container you pull today is not the container you pulled yesterday.

The second constraint is the gateway. The compose command starts openclaw gateway run with --allow-unconfigured and --bind lan. --bind lan means the gateway is reachable beyond localhost, which is why the token variable is mandatory and why the allowedOrigins list has to be set correctly. A misconfigured allowedOrigins is the most likely reason a Dashboard that loads fine locally refuses to connect from another machine.

Where this is the wrong tool

The licence field is the clearest problem. The repository metadata reports NOASSERTION, while package.json declares MIT and the Dockerfile carries the label org.opencontainers.image.licenses="MIT", and the README's badge links to a LICENSE file. Those signals disagree. NOASSERTION means the hosting platform could not classify the licence automatically, which is not the same as a missing licence, but it does mean you cannot settle the question from the repository page. Open LICENSE before you ship anything built on this.

Second, this is a fork of a fast-moving upstream. The hourly sync is a promise about the sync job, not about quality. Every upstream release can introduce strings the translations do not cover, and untranslated_list.txt exists precisely because that happens. A mixed Chinese and English interface is the expected state, not a bug report.

Third, this is the wrong tool if you do not want a Node.js service on your machine at all. The minimum is Node.js 22.19.0, the Docker image is built on node:24.16.0-slim and installs Chromium, Python 3, make and g++ to satisfy native dependencies. That is a heavy image for what is, from the user's side, a chat assistant.

Finally, the README contains sponsored placement for a third-party API reseller, including a Base URL and registration links, and the project explicitly labels it as third-party promotion. If you are evaluating this for an organization, that block is worth reading as a business relationship rather than as documentation.

Alternatives, and what the difference in approach costs you

The direct alternative is upstream OpenClaw itself, at openclaw.ai. The difference is not features, since the translated build is derived from upstream. The difference is where the maintenance burden sits. Upstream gives you one codebase and English strings. This project gives you upstream plus a translation patch layer, a sync job, a verify and restore CLI, and a nightly container. You are trading an English interface for a second moving part.

A second alternative is to localize OpenClaw yourself, which is closer to what this project does than it sounds. Because the translations live as data in translations/ and the CLI exposes apply, verify and restore, the same machinery could be pointed at your own string set. The repository even ships a translation guide with a glossary, principles and a style guide, plus a contributing document describing how to add a new translation. That is an unusual amount of process for a fork, and it is the strongest argument that this project is meant to be built on rather than only consumed.

A third option, if your actual goal is a management interface rather than a translated CLI, is ClawPanel, referenced from this README as a visual management panel with a built-in AI assistant and one-click install. It is a different repository with a different scope, so it is not a drop-in replacement, but it addresses the same friction for users who do not want a terminal.

Maintenance cost and what the licence situation means for you

The last push was on 2026-09-09, and the most recent release in the list, v2026.9.3-zh.1, is dated the same day. The repository is not archived. package.json reports version 2026.9.4-zh.1, which is ahead of the newest release tag in the list, so the version string in the package and the release tags do not move in lockstep. If you pin by version, pin by the npm version, not by the release name.

The upgrade path is the part the documentation covers least. The README's table of contents lists an update and upgrade section, but the text available does not describe what happens to applied translations when OpenClaw itself is upgraded. The restore verb implies you can return to an untranslated state, and apply implies you can reapply, so the safe sequence is restore, upgrade OpenClaw, then apply and verify again. Treat that as the workflow the CLI's design suggests rather than as documented procedure.

On licensing, the honest position is that the repository page, package.json and the Dockerfile do not agree, and nothing in the available documentation resolves it. MIT is declared in two machine-readable places, but the platform reports NOASSERTION. I am not giving legal advice, and this is exactly the kind of discrepancy that should be resolved by a human reading LICENSE and, if the answer matters commercially, by someone qualified to interpret it. The Dockerfile's maintainer label points to a company, Wuhan Qingchen Cloud Network Technology, which is also the package author, so there is a real entity behind the fork rather than an anonymous mirror.

Editorial conclusion

Adopt this if you want OpenClaw's CLI and Dashboard in Chinese and you are willing to track a fork that syncs hourly, which means reading the upstream changelog yourself rather than trusting a stable release line. Do not adopt it if you need a project with an unambiguous licence file, or if you want an assistant that is not tied to a Node.js 22.19.0 minimum and a running gateway process. Before installing, verify three things: what LICENSE actually contains, whether the openclaw-zh CLI applies patches to a global npm install on your machine, and whether the gateway.controlUi.allowedOrigins value in docker-compose.yml matches the host and port you will actually browse from.

Frequently asked questions

Official sources

1. 1186258278/OpenClawChineseTranslation on GitHub
2. Issues
3. Project website
4. README
5. Releases