如何用版本工具维护翻译项目

个人来说,一直希望能将《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) 就可以不断的从源项目中更新修改。同时,译文版本也可以随意根据本地化需求进行结构调整,而不用担心因为这些结构调整导致源版本修改时无法同步。

这样作的好处是,在这个流程中那些不存在冲突的修改会自动合并。比如项目中的一些资源、代码等等与内容无关的东西。或是新补充的内容。而存在冲突的修改,进行手工合并即可。

这里我写了一个流程脚本,可以模拟整个翻译项目操作维护的过程。

希望本文能帮助正在或者想要参与到一些翻译和本地化项目的朋友。同时我也相信,这个流程并不是最优的,欢迎大家一起来探讨改进。

Join the Conversation

2 Comments

  1. 我目前参与的Linux.cn的翻译组,porject也是放在Github上。管理员们出于稳定性,推荐使用的翻译流程是:1.git clone;2.git pull(可以先用fetch查看一下更新);3.edit && git commit;4.git pull;5.通过web端从自己的repository发起一个PR;6.等待被merge。在申请翻译和翻译完毕后,一般会各发起一次PR,前者主要是为了及时告知某篇文章已被申领。
    流程相对冗长,但从保证团队翻译流程的稳定性来说,还是比较合适的,因为很多新人最开始对git不熟悉,而且这里面涉及到的git命令基本比较简单,容易上手。:)

Leave a comment

Your email address will not be published. Required fields are marked *