v2.cn.vuejs.org: the Chinese Vue 2 documentation built on Hexo

A translation mirror, not a documentation source

The scope of this repository is narrow and the README is upfront about it. It holds the Chinese translation of the Vue 2 documentation, the site is published at v2.cn.vuejs.org, and the header states that the site has entered maintenance mode, meaning the English upstream is the source of truth and this repository follows it.

The English original lives at the `vuejs/v2.vuejs.org` repository, and the README makes the direction of travel explicit: contributions here are expected to be translations of upstream changes, corrections of typos and wrong formatting, and issues discussing wording or the deployment process. The sync is described as periodic, covering both the documentation content under `src` and the front-end code under `themes/vue` in the English repository.

There is also a scope rule that matters for anyone about to open an issue. The README says that in principle only translation work happens here, and that if the English text itself could be improved, or if an idea would help every language version, it should be raised in the English repository instead. Questions about using Vue are explicitly redirected to the official forum and the chat room. For a Vue 3 project, the README names the destination outright: the Vue 3 Chinese documentation moved to `vuejs-translations/docs-zh-cn`.

The tree matches that role. It is a documentation site, with `src/` for content, `themes/` for the site chrome, `_config.yml` for Hexo configuration, `writing-guide.md` for translation conventions and a `pnpm-lock.yaml` for reproducible installs.

Hexo with a pinned generator set, including one dependency from a fork

The site is a Hexo site and the dependency list in `package.json` shows how it is assembled. There is `hexo` itself at version `^7.2.0` and `hexo-server` at `^3.0.0` for the development server, a set of generators for archives, categories, feeds, indexes and tags, and renderers for EJS, Markdown and Stylus. The `hexo` config block in the same file pins `version` to `6.2.0`, which is a separate knob from the installed package and is the field Hexo uses to decide how the site directory is laid out and which features to enable.

Two dependencies are worth flagging. `hexo-generator-alias` is not taken from the npm registry but from a git URL pointing at a fork hosted under the `chrisvfritz` account, which is the mechanism that turns the English documentation's link structure into working Chinese paths. And `hexo-renderer-marked` is pinned at the older `^0.3.2`, which is a conservative choice for a documentation site where a renderer upgrade can silently change how every page renders.

The remaining utilities are small and telling. `axios` and `hoek` are present, `js-yaml` handles configuration, and `zhlint` at `^0.6.0` is the Chinese typography linter that gives the project its most distinctive tool. The `engines` field asks for Node `>=14.0.0`, and the package is marked `private` with `true`, so it is never published to a registry; it exists to be deployed as a site.

Running the dev server with pnpm, and what you should see

The README gives the development setup in two commands, and the second one carries the detail that saves you a search.

$ pnpm install
$ pnpm start # 开发服务器地址为 http://localhost:4000

The development server listens on `http://localhost:4000`, and the repository ships a `pnpm-lock.yaml`, so `pnpm install` produces a deterministic dependency tree rather than resolving fresh versions. The lock file matters more than usual here because of the git-sourced generator dependency, which has no version range that a registry could pin.

The npm scripts add a little more than the README shows. The `dev` script is not a bare `hexo server`, it first runs a sponsor sync step.

node _scripts/sync-sponsors.js && hexo server

That script in `_scripts/` fetches the sponsor list so the acknowledgements page stays current without a human editing it. The `build` script does the mirror image before generating, running a pre-deploy script and then a clean and a generate.

node _scripts/pre-deploy.js && hexo clean && hexo generate

The `_scripts/` directory is therefore part of the build contract, not a collection of one-off helpers. A fork that skips the pre-deploy step will produce a site that differs from the published one, whatever the Markdown content says.

The lint step only covers three directories, and that is deliberate

Chinese documentation has typography problems that a JavaScript linter cannot see, and `zhlint` is the tool this project reaches for. The `lint` script is scoped to a precise glob.

zhlint 'src/v2/{guide,api,style-guide}/*.md'

The scope is the interesting part. The glob covers `src/v2/guide`, `src/v2/api` and `src/v2/style-guide`, and it stops at the top level of each directory, so nested Markdown files are outside it. A `lint:fix` variant runs the same command with `--fix`, which means the tool can correct what it flags instead of only reporting it.

Two consequences for a contributor. First, a passing lint run is not a statement about the whole site, so a change outside those three directories is not checked by the linter at all. Second, the pattern of Chinese documentation work is to fix spacing and punctuation between Chinese and Latin text, and the automated check catches the mechanical part of that, while `writing-guide.md` and the wiki linked from the README cover the judgement calls the tool cannot make.

The README asks contributors to raise an issue when they want to discuss wording or formatting conventions, which suggests the maintainers treat translation style as something to be settled collectively rather than in a pull request comment.

Deployment, and one inconsistency worth checking

The README says the site is deployed automatically to the `master` branch through CircleCI. The repository tree, however, also contains a `vercel.json` at the top level, and `package.json` defines a `deploy` script that runs the build and then `hexo deploy`.

Those two statements do not line up neatly. A CircleCI pipeline keyed to the `master` branch and a Vercel configuration file in the root are two different hosting arrangements, and the README does not explain whether the Vercel file is a current deployment target, a leftover from a migration, or a configuration used for preview builds. The repository does not include a CircleCI configuration directory in the top-level listing, though a `.github/` directory is present and could hold the workflow.

If you are deploying a fork, this is the first thing to resolve. The `deploy` script in `package.json` relies on Hexo's own deploy mechanism, which needs a remote configuration in `_config.yml` that is not reproduced in the files listed for this project, while an automated pipeline needs whatever the hosting service expects. Anyone who assumes the README sentence describes the whole setup can end up with a site that builds but never updates.

The `build` script is the part worth copying regardless, since the pre-deploy script runs before `hexo clean` and `hexo generate`, and skipping it changes the output.

What a contributor actually does here

The contribution loop is short, and the README names the steps. Sync the latest changes from the English site, fix typos or incorrect formatting, open an issue to discuss wording or formatting, or open an issue to discuss deployment and collaboration process. The README also asks contributors to read the wiki linked at the end of that section before translating, and it points at an acknowledgements page at `/about/` that records who did the original whole-site translation.

The acknowledgements deserve a mention because they explain the history of the project. The README says the site was founded with a lot of help from many people who divided the work and completed the translation of the whole site together, and the current state is that the site is in maintenance, with the latest documentation and translation contributions visible on the GitHub contributors page.

Maintenance status itself is worth stating plainly. The last push to the repository was on 2026-10-16, and the repository is not archived, so it is receiving updates. But the README describes those updates as a periodic sync of an upstream that is itself in maintenance mode, which is a different thing from the project being under active development. There are no GitHub releases attached to the repository, so version history is not tracked here either. The `writing-guide.md` file and the wiki are the practical references for making a contribution that matches the existing style, and a pull request is the mechanism the README asks for.

Editorial conclusion

Adopt this repository if you need the Vue 2 documentation in Chinese, or if you want a working Hexo setup for a translated documentation site you can fork, since the generators, the theme folder and the lint tooling are all here. Do not adopt it as the base for Vue 3 work, because the README points Vue 3 readers at the separate `vuejs-translations/docs-zh-cn` repository, and do not expect new Vue 2 features to be documented here. Before contributing, read `writing-guide.md` and the linked wiki, and run `pnpm run lint` on your changed files, since the `zhlint` script only covers `src/v2/{guide,api,style-guide}/*.md` and will not check the rest of the tree.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vuejs/v2.cn.vuejs.org on GitHub