docs-cn keeps a Chinese translation of the Vite manual in step with upstream

A translation target, not a fork of the Vite source

docs-cn holds the Chinese edition of the Vite documentation and nothing else. The Vite source code lives in a separate repository, and the documentation itself in English lives in the docs directory of that source repository. What sits in docs-cn is the translated site, its build configuration and the automation that keeps it aligned with the English text. The README is direct about the scope: in principle this repository only does translation work, and anyone who thinks the original text should be improved, or who has an idea that would help every language version rather than only the Chinese one, is asked to raise it in the English repository instead. The same note says this is not the place to discuss how to use Vite, and points questions to the Vite issues area, the official chat, or the wider technical communities. The audience for the repository is therefore split: readers who want the Chinese manual, and translators who want to contribute to it.

The daily bot turns upstream changes into reviewable pull requests

The workflow is the interesting engineering here, because the failure mode of a translated documentation set is drift. The README describes the mechanism: the English documentation is pulled every day into a sync-docs branch, and a bot then automatically opens a pull request, resolves Git conflicts and translates the changed content. Because a human reviews the pull request, a translation is not a blind machine copy, but because the trigger is a daily sync, the queue of work is self-feeding. The docs are stated to be at the v8 version and to be synced with the English documentation every day. The consequence for a reader is straightforward and slightly uncomfortable: the Chinese text is a moving target that follows upstream on a delay, so a page you read this morning may describe a flag that changed in the English source last week, and a page you bookmark may be rewritten underneath you.

VitePress does the site work, and the scripts are four lines long

The site is a VitePress project, and the package.json keeps the script surface very small.

	"scripts": {
		"dev": "vitepress dev . --port 5174",
		"build": "vitepress build .",
		"typecheck": "vue-tsc",
		"serve": "vitepress serve ."
	},

So the dev server runs on port 5174, the build produces the static site, typecheck runs vue-tsc, and serve previews the built output. The devDependency list shows how much of the site is custom: a custom VitePress theme package, twoslash for type-aware code samples, a graphviz plugin, a group icons plugin, gsap for animation, feed for the RSS output, and gray-matter for frontmatter. Vue and vue-tsc are present, and a yorkie dependency handles the pre-commit git hook. The commit-msg hook runs scripts/verifyCommit.js, so commit message format is enforced locally rather than only by a CI check.

Getting the site running locally takes three commands

The README documents the editing setup as clone, install, start.

$ git clone https://github.com/vitejs/docs-cn.git

# 安装依赖
$ npm install
# 或者使用 pnpm
$ pnpm i

# 启动开发服务器
$ pnpm dev

Both package managers are offered, and the repository ships a pnpm-lock.yaml while the package.json pins the package manager to [email protected]. The engines field requires Node ^20.19.0 or >=22.12.0, so an older Node installation will not be accepted by the package manager. The command that starts the local site is pnpm dev, which maps to the VitePress dev script on port 5174. The repository also holds a .vitepress/ directory for site configuration, a config/ directory, a plugins/ directory, a scripts/ directory, and content directories for guide, blog, changes, releases and team pages.

Deployment, domain and contribution counting are wired into the repo

The repository is set up to publish, not only to build locally. A CNAME file at the root points at the cn.vite.dev domain, a vercel.json holds the hosting configuration, and the public/ directory holds static assets while images/ holds the illustration files referenced across the pages. The _data/ directory suggests structured data files that the site loads rather than repeating inline, and the .github/ directory carries the workflow definitions that drive the bot. The contributor statistics on the home page are generated by a separate script, and the README states the counting rule explicitly: every contributor who produced a commit to the main branch counts, with the avatar images produced by a dedicated generator. That is a small but deliberate piece of contributor infrastructure rather than the usual badge-only approach, and it also means that a translator who opens a pull request but whose change is not merged into main does not appear in the count.

The licence blocks commercial reuse of the translated text

The licence is the constraint that decides how this repository can be used. The package.json declares CC BY-NC-SA 4.0 and the README carries the Creative Commons badge for the 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议, which is the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence. The GitHub licence field for the repository is listed as a custom licence that GitHub cannot classify, which is consistent with a Creative Commons terms document in the LICENSE file rather than an OSI approved software licence. Two things follow. The non-commercial clause means a company cannot drop these pages into internal training material or customer documentation without a separate permission, and the share-alike clause means an adapted translation inherits the same terms. This is the usual arrangement for a documentation set that is not software, but it differs from the permissive terms most documentation repositories carry, so it is worth checking before mirroring the content.

Where the Chinese edition is the wrong source to read from

Two limits are structural. The first is latency relative to the English source. The sync runs daily, the bot then opens a pull request, and a human still has to review the machine translation, so a change in the English documentation is visible in Chinese only after that chain completes. For a tool where configuration keys and CLI flags change between minor versions, a documentation page that is two days behind is usually harmless, but a page describing a feature that was renamed or removed is misleading, and the Chinese text is the version most likely to still describe the old behaviour. The second is scope. The README explicitly states that this is not the place for Vite usage questions, so an issue filed here about how to configure a plugin will not get you an answer. Anyone who needs the current, authoritative answer to a Vite question should go to the English documentation and the Vite issue tracker, and use docs-cn as the Chinese reading copy of the same content.

Editorial conclusion

docs-cn suits a Chinese speaking developer who wants the Vite manual in their own language, and it suits a translator who wants a defined workflow for contributing, since the bot automates the sync and the contribution rules are spelled out. It is the wrong tool for a reader who needs the authoritative text, because the Chinese edition necessarily lags the English source by the duration of the bot run and the review that follows, and the wrong tool for anyone planning commercial reuse, because the content is under CC BY-NC-SA 4.0 with a non-commercial clause and the repository is marked private. Before relying on it, check the sync pull requests on the main branch to see how recently a page was updated, and confirm a section against the English documentation when the wording of a config key matters. The last push was on 2026-10-08 and the newest tag is v8.3.0 from 2026-09-10.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vitejs/docs-cn on GitHub