个人来说,一直希望能将《 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 的这个疑问,也为了让更多的人能更轻松的参与到各种本地化项目中来,我在这里统一解释一下这个维护流程吧。其实完全去除原文的翻译项目主要还是依赖版本管理工具,这里有一个简单的流程:
许多朋友可能会觉得这个流程跟一般的项目开发没什么不同嘛。是的,不是说要遵从 KISS 原则,一切从简么?
简单解释一下:
步骤 a) 是必不可少的。不少翻译项目可能一开始并未保留原文版本变更,解决办法是做一次对应版本的 merge 操作(当心,工作量甚大),保留译文但让原文版本进入版本管理。步骤 b) 就是标准工作流程了。步骤 c) 需要注意如果源项目的分支发生了变化,一定要调整拉取正确的分支,要不就天下大乱了。步骤 d) 实际操作中,我一般用 git mergetool 命令配合 meld 的三方对比进行合并。哪些地方出现调整,需要怎么调整一目了然。步骤 e) 就是标准工作流程了。在翻译不断跟进的时候,重复步骤 b) 到 e) 就可以不断的从源项目中更新修改。同时,译文版本也可以随意根据本地化需求进行结构调整,而不用担心因为这些结构调整导致源版本修改时无法同步。
这样作的好处是,在这个流程中那些不存在冲突的修改会自动合并。比如项目中的一些资源、代码等等与内容无关的东西。或是新补充的内容。而存在冲突的修改,进行手工合并即可。
这里我写了一个 流程脚本 ,可以模拟整个翻译项目操作维护的过程。
希望本文能帮助正在或者想要参与到一些翻译和本地化项目的朋友。同时我也相信,这个流程并不是最优的,欢迎大家一起来探讨改进。