个人来说，一直希望能将《Go指南》这个项目的版本管理从 bitbucket 迁移到 github。但是由于上游英文源项目仍然在用 hg 作为版本管理工具所以一直也没有这么做。前几天 OlingCat 找我，希望将这个翻译项目放在 github 上的 go-zh 项目中。我当然欣然同意，虽然翻译工作还得用 hg 维护，但是 git 上能够有个镜像也是不错的事情。
（中间略过若干 hg –> git 的鸡零狗碎不说）
在等待同步的时候，我简单阅读了一下“Go 项目翻译规范”，发现一个让我觉得很不舒服的设定。
由于godoc只会提取紧挨着声明之前的注释作为文档，因此我们可利用这点进行翻译。 请在注释符号//之后，文字之前插入一个制表符（Tab符号），段注释前直接插入制表符， 这样便于跟踪官方文档的更改。注释与代码间插入一个空行，紧接着开始翻译。翻译与代码之间不要有空行。
在一切完工之后，OlingCat 问了我一个终极问题：直接在 article 文件里翻译，是怎么和官方同步的？
后来闲下来的时候仔细想了想，从 PHP-GTK 的手册到 ZF 的手册，再到 Golang 的一系列文章、项目。自己参与了这么多的翻译项目。虽然每个项目都与一套自己特色的翻译跟踪规则，不过工作得最轻松的可能还是《学习 Go 语言》和《Go 指南》这两个项目了。《学习 Go 语言》我使用的是 git 来跟踪和翻译。而《Go 指南》由于上游原因使用了 hg。为了更加清晰的解答 OlingCat 的这个疑问，也为了让更多的人能更轻松的参与到各种本地化项目中来，我在这里统一解释一下这个维护流程吧。其实完全去除原文的翻译项目主要还是依赖版本管理工具，这里有一个简单的流程：
-
a) fork 源项目到一个独立分支； // git clone src dest
-
b) 进行翻译并提交入版本库；// edit && git commit
-
c )从源项目更新变更；// git pull
-
d )合并；// git merge
-
e )提交合并结果。// git commit
许多朋友可能会觉得这个流程跟一般的项目开发没什么不同嘛。是的，不是说要遵从 KISS 原则，一切从简么？
简单解释一下：
步骤 a) 是必不可少的。不少翻译项目可能一开始并未保留原文版本变更，解决办法是做一次对应版本的 merge 操作（当心，工作量甚大），保留译文但让原文版本进入版本管理。步骤 b) 就是标准工作流程了。步骤 c) 需要注意如果源项目的分支发生了变化，一定要调整拉取正确的分支，要不就天下大乱了。步骤 d) 实际操作中，我一般用 git mergetool 命令配合 meld 的三方对比进行合并。哪些地方出现调整，需要怎么调整一目了然。步骤 e) 就是标准工作流程了。在翻译不断跟进的时候，重复步骤 b) 到 e) 就可以不断的从源项目中更新修改。同时，译文版本也可以随意根据本地化需求进行结构调整，而不用担心因为这些结构调整导致源版本修改时无法同步。
这样作的好处是，在这个流程中那些不存在冲突的修改会自动合并。比如项目中的一些资源、代码等等与内容无关的东西。或是新补充的内容。而存在冲突的修改，进行手工合并即可。
这里我写了一个流程脚本，可以模拟整个翻译项目操作维护的过程。
希望本文能帮助正在或者想要参与到一些翻译和本地化项目的朋友。同时我也相信，这个流程并不是最优的，欢迎大家一起来探讨改进。
Leave a Reply