前言
去年，我在实习过程中加入了国内大型前端文档翻译组织—印记中文。参与了 ionic 和 vuepress 的翻译。
我深深感受到，翻译过程中，最吸引人的，令我收获最大的，不是说那些零零碎碎的 API，而是开源精神对我的鼓舞。
开源社区，是程序员这个人群最宝贵的财富。
我从翻译文档中学到了什么？这是我的答案：
- 翻译流程与 git 操作
- 翻译与开源理解
- 翻译素养
翻译流程与 git 操作
印记中文的翻译流程几经更迭，到如今已经形成了一个比较可靠、高效的流程。以 ionic 翻译流程为例：
我们将翻译涉及到的仓库分为三级：
项目原仓库（一级）、印记中文仓库（二级）、译者仓库（三级）。
三者职责分明，一级仓库负责原始信息的生产，二级仓库用来管理，不提供翻译，只负责同步上游信息和审阅下游翻译。真正的贡献者，在第三级仓库。
从图中可以看出，我们使用了大量 git 和 github 操作：
- fork(github) 复制仓库
- clone(git) 从 github 签入代码到本地仓库
- remote add(git) 关联上游仓库
- remote update(git) 同步上游仓库
- add/commit(git) 将工作区更改保存到本地仓库
- push(git) 将本地仓库代码推送到远程仓库中
- pull request(github) 将下游仓库的更改同步到上游仓库
除了图中明显的操作，还有一些实际中也常用到的操作：
- branch(git) 列出或新增、删除分支
- checkout(git) 切换分支
一般开源项目都有若干个分支，每个分支都可以说是几乎对应着一个版本。在印记的翻译流程中，中文文档统一在 cn 分支下。
- fetch(git) 将远程仓库内容拉取到本地仓库
- merge(git) 将本地仓库内容合并到工作区
为什么要提这两个命令呢？因为实际上 pull = fetch + merge，而 pull 是不具备拉取所有分支的功能的，所以我们需要把这个步骤拆开：先把远程仓库所有分支内容同步到本地仓库，再选择某一个分支和当前工作区内容合并。
当然，还有一些不常用的操作和骚操作，这块内容会在本文靠后的成长与挫折部分介绍。
对于基本的 git 概念和操作还有疑惑的读者可以参考下面资源：
理解开源
在这里，我真正学会了真正的阅读源码的技巧。
以前，我以为读源码和上学时读教科书一样，顺着章节从头读到尾就能达到目标，通过考试。
但开源项目不同，它没有考试，也不会终结，只要世上还有人在运行着它的代码。
要理解一个开源项目，必须要沿着它的 git log 一路寻找才能真正感受到它的真正魅力。最初的起点，可以是项目刚刚好正常运行的那个节点，也可以是被打上第一个 v1.0.0 tag 的节点。
开源项目是动态的。
如果像过 PPT 一样过源码简直就是对它价值的浪费！我们应该将这个项目先运行起来，这是对它的基本尊重。然后打断点，跟调试。
开源项目是有生命的。
就拿 Vuepress 来说，我们从它发布的 v0.1.0 跟到这篇文章发布时的 v0.8.4，期间可以看到作者对这个产品的奇思妙想，也能看到来源于大众的各个 issue 和 pr，沿着时间一点一滴地浇筑这个项目。
比如说这个关于下拉导航链接的讨论：从基本的功能需求到详细的数据结构，再到之后对基于此功能开发多语言特性的展望。
开源项目是集体财产。
开源是一个自下而上的体系，如果从译者的角度来看。但这同时也是一个自上而下的体系，如果从项目本身来看。一个优秀的开源项目，会源源不断地产生新的灵感和想法，下游的译者们孜孜不倦地受着来自上游的给养，从而又转化成更适合当地吸收消化的语言版本反哺给上游。
把译者替换成万千默默无闻给开源项目贡献代码的普通工程师也是一个道理。正是因为有了这些人，前端乃至IT界的技术生态才会如此繁荣。
它是分权、公开、同僚复审的。
我们都是其中的一员，没有人是一座孤岛。
翻译素养
“翻译技术文档不是随便翻译就完了，你需要重新审视它，让它容易被读者理解，但又不能出现原意的偏差。”
在我第一次提交翻译 ionic 文档的 pr 时，印记的前辈这样教导我。
“排版和格式也需要注意，记住我们是专业的。”
说完他给了我一个链接：中文文案排版指北。它详细地规定了哪些元素需要用空格隔开，遇到完整的英文整句、特殊名词该怎么办等不容易引起注意却很重要的细节？
翻译文档和翻译文章不同，它应以通顺重视原文为准。
我的英文水平自认为不是非常好，虽然过了所谓的六级，但阅读英文资料时常常还是需要借助翻译工具来辅助阅读。这就更加提醒我了，翻译是个耐心活，看似没有多少技术含量，实则非常能反映译者的水平。我的水平，显然还是不太够的，还是需要多向各位前辈们学习的。
成长与挫折
- 三级仓库同步流程
原始项目往往更新地非常迅速，我们需要跟上更新还是挺费力气的。不过李同学提出了一个方法：二级仓库只拓展，不修改。拓展来源可以是一级的更新，也可以是三级的翻译。
然后在三级仓库同步二级仓库，遵循行数不变的原则，利用 git diff + 可视化编辑工具完成同步。具体步骤为：
- 1.1 fetch(从一级远程仓库到二级本地仓库)
可以看到图中有三个箭头，最上面的箭头指向最新版本，中间箭头指向我们需要拓展到的 0.9.0 版本，第三个箭头指向 fetch 成功提示。
- 1.2 push master（从二级本地仓库到二级远程仓库）
经过这一步操作，我们就可以将一级远程仓库的更新拓展到二级远程仓库。
注意：push 的分支是 master 不是 cn。
- 1.3 fetch + merge 发现冲突(从二级远程仓库到三级本地仓库)
这个时候我们工作区已经切换成翻译者拥有的，而不是管理者拥有的。
注意：由于我既是管理者也是翻译者所以才需要切换。
翻译工作区的 fetch + merge：
- 1.4 diff 解决冲突（翻译的过程）
webstrom 为我们提供了三块编辑区：你的版本、合并版本、服务端版本。红色的自然就是冲突部分了，我们可以选择全部要我们的版本，也可以全部要服务端的版本，当然，一般是部分来自于我们的版本部分来自于服务端的版本。
- 1.5 push cn（从三级本地仓库到三级远程仓库）
翻译者此时提交自己的翻译成果。
- 1.6 pull request（从三级远程仓库到二级远程仓库）
到这时，如果管理员觉得 pr ok 的话，就会接受，否则会不接收然后注明不接收的原因。有时管理员还要处理产生冲突的 pr。
webstrom 还有很多操作 git 的功能：Smart merge、Stash Change、Rebase 等，更多用法可以参考在 WebStorm 中熟练地使用 git
- 翻译错误或有瑕疵
限于本人水平有限，翻译成果自然有不如人意的地方，比如 vuepress 的 yaml front matter，我不知道这是一个库，就直译成“yaml 前端” ，闹了笑话，幸好之后有人指出来错误。我们印记中文是乐于接受批评和指正的，因为我们也是开源社区的一份子。 - 遭遇无耻抄袭
抄总比自己做简单的多。再加上我们又是开源，自然有不少站点如 xx码头等直接搬运过去用的，不打招呼就算了，还在网页上加一句：经自己整理翻译。这就令人很痛心了。
结语
这，就是我从翻译文档中收获到的。
