统一维护 vuejs 的所有中文文档（本地化文档）

[awxiaoxian2020]

目前，这个仓库已经形成了良好的翻译规范，但是这种规范似乎只在 vuejs 核心项目里起作用。对于 Vue Router 和 Pinia 等官方维护的库的中文翻译却没有统一的规定。格式上的规范是容易参考的，但是某些术语的翻译希望能够统一到 wiki 里面来以便参考。当然如果能将所有的翻译统一迁移到这个组织下更好。

参见 vuejs/pinia#1193 (comment)
vuejs/pinia#1697

[Jinjiang]

我觉得“统一维护”的必要性不大，而且随着 Vue 相关的项目越来越多，这个翻译的范围很难界定。
我觉得主要值得参考的就是 wiki 里的术语约定和流程之类的东西，可以由各仓库的维护者根据自身情况来决定要不要参考，参考多少。

具体内容可以在各自的仓库里单独讨论。
另外有哪些希望官网这边的维护者看一下的，也可以把链接贴在这里，我们鼓励大家在有余力的情况下多多关照一下。(我自己平时偶尔也会看，但精力有限)

谢谢

[veaba]

我理解 LZ 提到的迁移到同一组织的意思。

我看到除去 vue/docs 已有固定的中文小组外，如 Pina、Vue-router 等 Vuejs 官方仓库渐渐活跃一小批中文翻译用户，他们正在做一些汉化工作，吸纳一些核心的用户加入 Vuejs/translations 并划到自己所属 repo 的中文小组，确实应该考虑下。 @Jinjiang

吸纳为 Vuejs/translations org 的原因有几个考虑：

• 付出得到认可
• 共享成熟的社区 i18n 技术栈
• 小组驱动，效率可以更进一步提高

vuejs-translations/docs-zh-cn 目前已稳定的，其他仓库主要关注的是能够使用多少规范的东西，各自项目肯定有自己独特的术语，由 owner 决定维护自己的 wiki，如果是相同的话，可以相互参考借鉴。

另外，vuejs/docs i18n 进度比较慢，但是，非母语者好像没啥好办法，之前有个 wiki 来着：https://github.com/vuejs-translations/docs-zh-cn/wiki/DRAFT:-General-guide-for-the-translation-in-your-language

[awxiaoxian2020]

具体内容可以在各自的仓库里单独讨论。

@Jinjiang 时隔半年，我想我的表达可以更明确一些了：目前的问题是除了 vuejs 和 vitejs 的中文文档有各自独立的仓库，其他的中文文档都是和原文档和源码一起放在 zh 文件夹内的，这样维护起来非常困难。所以能不能把翻译都独立出来，因为最近 vitepress 的文档和 API 都趋于完善，我想我们可以做到这一点。

[Jinjiang]

这样维护起来非常困难。

@awxiaoxian2020 关于这一点我想更多了解一下你感受到的非常困难是什么，我没有看到你在这里展开你的观点，同时自己也没有这种感觉，不知道这句话从何而来。

即便抛开这一点先不谈：

1. 不是所有的项目都像 vue core 一样大到文档是专人维护、设计和管理的。有些比较小的项目文档就几个页面甚至一个页面而已，与其创建一个新的仓库、域名、部署渠道，就近翻译和部署是最务实的做法。在整个生态系统里，官方和非官方的界线也未必那么清晰，有些项目就是一开始从个人项目转变成官方的，所以这个状态肯定是多样化的。长期来看，每个仓库应该有各自的自主性来根据情况和阶段决定采取什么方式维护文档和翻译。
2. vue 官网不只是技术文档，更是整个 vue 生态的入口，包括各种运营、商业合作等属性，所以虽然都是 vitepress，其定制程度和额外的编码量，跟其它仓库的文档相比都不是一个档次的，维护 vue 官网有相当一部分工作是写维护 theme，其它仓库不存在这个问题，工程复杂度和协作流程自然也不一样。
3. 我个人也并不觉得所有仓库的文档应该由同一组人维护，从翻译这个角度看，不同的仓库可以尽量有约定俗成的共识，但组织形式上最好是去中心化的。

另外我们正在以 vue router 为试点，尝试一种相比于 vue 官网更轻量的翻译流程，感兴趣的话可以看这里：vuejs/router#1770 (comment)

谢谢

[awxiaoxian2020]

@Jinjiang 感谢您的回复。我们确实需要考虑到翻译所需要花费的开销问题，您的回答也让我知道了为什么 vue 的文档是单独的组织和仓库，我对此表示理解。

我之前所说的困难是指，在单一仓库中加入多个翻译文档的话，那么至少我现在所看到的（pinia 和 vitepress）PR 的合并需要由非母语者的仓库的 owner 或现有的组织 member 来进行合并，而这些合并可能还需要等待其他母语者的 review，而这些 review 如果没有固定的人员来进行相关的跟进，那么处理可能是“随机的”，效率不高。一种语言还好一点，如果多种语言的 PR 都需要仓库 owner 处理，我实在觉得这是一种负担。

所以纵使不能有单独的仓库，我觉得我们需要有一些固定的人员可以去跟踪对应语言的 PR，能够合并翻译类的 PR。比如类似于 code owner 这样的机制。

当然我也看到您在最后给出的试点流程，我想这就是我想要的，我稍后会仔细研究一下。

• 有一个可以参考的流程使翻译可以顺利进行
• 有一些人可以推进这样的机制
• 这些人可以在一起讨论翻译的相关事宜

我不知道我的想法是不是“中心化”的，但是我觉得“中心化”或者至少有一个“可中心化”的流程作为参考，只会让流程更加高效，不会对开源的生态造成破坏。

[awxiaoxian2020]

vuejs/pinia#2549 Translation Status UI is a good solution. I will close this discussion.