This repository is now primarily kept as a reference for existing Vue documentation translations and their maintenance workflows.
Vue core docs are no longer accepting new translations. Existing translations that are not actively maintained may lose official
*.vuejs.orgdomain support and be redirected to the English docs. For Vue ecosystem projects, see Vue Ecosystem Translation Guidelines.
- We are not accepting new translations of the Vue core docs.
- We are not onboarding new translation repos into
vuejs-translations, and we are not adding new translation links tovuejs.org. - Existing translations need active maintainers and reasonably timely upstream sync to keep official support.
- If a translation is no longer actively maintained, its official domain support may be removed and redirected to the English docs.
- Teams that still want to maintain a translation can continue doing so in their own repos, but official Vue support is limited to actively maintained translations.
This change is mainly about sustainability, not a judgment on the value of past community translations. Those translations helped many users, and we appreciate the work that went into them.
- AI-assisted translation quality is now high enough that the benefit of maintaining a separate official translation is much smaller than it used to be.
- For maintainers, translation is not only initial writing work. It becomes ongoing operational work: tracking upstream changes, reviewing terminology, resolving drift, and keeping versions aligned over time.
- Vue docs evolve continuously. Once an official translation falls behind, users may reasonably assume it is current because it is on an official domain, which can create more confusion than sending them to the English docs directly.
- Official support also creates continuing coordination cost for both translation teams and the core team: repo transfers, access management, review expectations, link curation, and domain support.
- Given the lower ROI of manual maintenance today, we would rather avoid creating expectations that volunteer maintainers need to keep carrying a long-term sync burden just to preserve official status.
If you are already actively maintaining a translation, the following recommendations still apply.
Read the Contributing Section of the English docs. Make sure to use pnpm and Node.js v14+. Familiarize yourself with VitePress' markdown extension features.
It's recommended to manage the workload using issues and pull requests. Create an issue for each page that still needs translation, then let team members self-assign to claim the work. Create a pull request for the translation of each page. This way, other collaborators can review and provide feedback before the the PR is merged. It is also recommended to use "Squash and Merge" for the PRs so you have a clean history.
When working as a team, make sure to use consistent translations for common terminologies to avoid confusion. It's best to have a place to document the conventions and consensus generated from reviews. You can use GitHub wiki, team discussions thread, or directly as a markdown file in the repo itself. If a term is particularly tricky to concisely translate in your language, consider leaving it untranslated.
Some text are part of the VitePress theme instead of markdown content. You can translate these in .vitepress/config.ts. In addition to navigation and sidebar items, you can also customize most of the theme text by providing the themeConfig.i18n option. Example usage in Chinese translation
All the images are embeded into docs with the Figma URLs set aside as code comments. You can search them out by this link:
https://github.com/search?q=repo%3Avuejs%2Fdocs%20figma&type=code
To translate the text in those images, we recommend to:
- fork the Figma docs accordingly,
- translate the text in Figma, and
- export the new image.
You can add specific suffixes to the new images according to your language code. Adding the forked Figma URL in the code comment is also welcome. Example practice in Chinese translation
VitePress automatically generates header anchor links (links that start with #) based on the text. Since we have a lot of cross-linking to headers within the site, it is easier to retain original English header links so that you don't need to update links everywhere when you translate the headers. It also makes it easier to switch between different languages of the same header link.
We already added header anchor links in the original English document, use the following syntax when translating to retain them:
- ## Original Header {#original-header}
+ ## Translated Header {#original-header}You may also notice that some headers are followed by one or two \* markers:
### `<script setup>` \*\* {#script-setup}These are custom markers we use to differentiate between Options-API-only and Composition-API-only sections. We use a custom markdown plugin to wrap these sections in additional divs that can be shown / hidden by toggling CSS classes. Please keep them when translating the headers!
It is recommended to set up an automated workflow to sync with upstream updates from time to time. If you don't have an existing preferred method of doing so, we have two recommendations:
-
Use Ryu-Cho to track upstream updates and automatically open issue / PRs. See example workflow in Japanese translation.
-
Create an
upstreambranch, and use this GitHub Action to sync that branch with the English docs. Periodically create PRs betweenupstreamandmainto sync the content with necessary translations. See example config in Chinese translation.
You can reach out to the respective teams in their translations repo if you have questions on how to set up syncing.
The lists below are kept for reference. Being listed here does not by itself guarantee continued official domain support.