Update git l10n workflow and tool kit

Signed-off-by: Jiang Xin <[email protected]>

Author: jiangxin

_posts/2012-02-28-git-l10n.md

@@ -12,7 +12,7 @@ Git从版本1.7.5（2011年4月）即开始国际化/本地化（i18n/l10n）的
 
 Git本地化（包括中文本地化）的协同方式不同于Git项目本身，不使用邮件列表进行提交评审，而是通过GitHub的协同工具来完成，这在Git邮件列表中有专门的讨论： [Git官方邮件列表](http://article.gmane.org/gmane.comp.version-control.git/189584) 。最终确定的工作流程参见Git源码中的文件 [po/README](https://github.com/git/git/blob/master/po/README) 。
 
-### 工作流程 ###
+### 中文本地化工作流程 ###
 
 中文本地化的协同版本库为： [https://github.com/gotgit/git-po-zh_CN/][git-po-zh_CN] ，以下简称 [git-po-zh_CN] 。
 如果您对翻译有修改或补充，请参照如下工作流程。
@@ -37,7 +37,17 @@ Git本地化（包括中文本地化）的协同方式不同于Git项目本身
 
 5. 使用GitHub提供的 pull request 功能，创建到 [git-po-zh_CN] 版本库的 Pull Request。
 
-6. 版本库 [git-po-zh_CN] 的管理者审核您的 Pull Request，若审核通过则将提交合并到代码树中，若不通过则会给出原因。
+6. 版本库 [git-po-zh_CN] 的管理者审核您的 Pull Request。
+
+7. 若审核通过则将提交合并到代码树中，pull request 自动关闭。
+
+8. 若提交有问题，管理者会通过评论给出原因。作为贡献者继续执行步骤3、步骤4，当修改后的提交推送（或强制推送）到GitHub后，pull request 中的提交会自动更新。管理者基于贡献者的最新提交重新审核（即步骤6）。
+
+### 工作协同 ###
+
+为了避免多人翻译过程中的工作重叠，使用 GitHub 维基帮助工作协同。即在翻译之前现在维基页面上领受工作任务，不同贡献者的工作任务不要重叠。
+
+例如中文本地化工作任务管理WIKI: https://github.com/gotgit/git-po-zh_CN/wiki/TaskList 。
 
 ### 提交规范 ###
 
@@ -47,33 +57,65 @@ Git本地化（包括中文本地化）的协同方式不同于Git项目本身
 
 * 提交说明符合 “50/72 原则”。
 
-  - 提交说明第一行会作为补丁邮件的标题或者作为简要日志输出，长度以50个字符为限。
+  - 提交说明第一行会作为补丁邮件的标题或者作为补丁文件的文件名，长度以50个字符为限。
 
-    建议这部分提交说明使用 `l10n:` 作为前缀，以便和Git其他代码的提交相区分。
+    有人喜欢第一行提交说明的末尾添加一个“点”表示句子的结束，这是不可取的。试想你在写邮件是标题要以点来结束么？一个文件名（不含扩展名）如果以点结束，加上扩展名或出现两个点！
 
-    还有注意这部分内容不能包含中文。
+    还有要注意这部分内容不能包含中文，建议提交说明使用 `l10n:` 作为前缀，以便和Git其他代码的提交相区分。
 
-  - 一个空行
+  - 一个空行。此空行用以分隔标题和详细描述。
 
-  - 关于提交的大段说明，例如原翻译存在的问题，为什么要进行修改等。
+  - 关于提交的大段说明（可选）。例如原翻译存在的问题，为什么要进行修改等。
 
-    提交说明可以折行，每行以72个字符为限。
-    
-    这部分提交说明可以包含少量中文。
+    提交说明可以折行，每行以72个字符为限。这部分提交说明可以包含少量中文。
+
+* 提交说明中包含签名，并且签名和提交说明间用空行分隔。
+
+  可以通过命令 `git commit -s` 会自动在提交说明中添加签名。
+
+作为Git的 l10n 协调者（l10n coordinator），我写了一个脚本以实现对本地化文件、提交规范的自动化检查。
+l10n teamder 在向 l10n coordinator 创建 pull request 前，建议使用该脚本对提交进行体检。
+
+* 获取 `po-helper.sh` 脚本到本地工作区的 `po` 目录下。
+
+        $ git fetch git://github.com/git-l10n/git-po.git po-helper
+        来自 git://github.com/git-l10n/git-po
+         * branch            po-helper  -> FETCH_HEAD
+        $ git checkout FETCH_HEAD -- po/
+
+* 检查本地的新提交。
+
+        $ po/po-helper.sh check commits
+
+* 检查最近的5次提交。
+
+        $ po/po-helper.sh check commits HEAD~5
 
+* 检查本地化文件。
 
-* 提交说明中包含签名。可以通过命令 `git commit -s` 会自动在提交说明中添加签名。
+        $ po/po-helper.sh check commits zh_CN.po
+
+* l10n 协调者对本地化的全面检查。
+
+        $ po/po-helper.sh check
 
 ### 翻译示例 ###
 
 * C语言字符串中的参数（占位符）很重要，需要维持其顺序。
 
-  注意字符串中出现的两个占位符 `%s` 和 `%s` 的先后顺序要严格保持。
+  注意字符串中出现的两个占位符 `%d` 和 `%s` 的先后顺序要严格保持，或者采用后面的解决方案。
 
-        #: builtin/pack-objects.c:2326
+        #: builtin/apply.c:824
         #, c-format
-        msgid "unable to parse value '%s' for option %s"
-        msgstr "不能解析值 '%s' 针对于选项 %s"
+        msgid "regexec returned %d for input: %s"
+        msgstr "regexec 返回 %d，输入为：%s"
+
+* 如果确有需要，可以使用类似 `%<n>$s` 的语法对C语言字符串中的参数（占位符）进行标记，以便调整语序。
+
+        #: builtin/apply.c:3266
+        #, c-format
+        msgid "new mode (%o) of %s does not match old mode (%o)%s%s"
+        msgstr "%2$s 的新模式（%1$o）和旧模式（%3$o）%4$s%5$s 不匹配"
 
 * 然而，Shell语言字符串中的变量（占位符）的顺序则不重要，可以根据翻译需要调整先后次序。
 
@@ -184,6 +226,31 @@ Git本地化（包括中文本地化）的协同方式不同于Git项目本身
         "将要删除的分支 '%s' 已经被合并到\n"
         "         '%s'，但未合并到 HEAD。"
 
+## 工具 ##
+
+* VIM 和 po.vim
+
+  安装 `po.vim` 插件后，使用 VIM 编辑 `.po` 文件，可以使用如下热键非常方便地进行本地化工作。
+
+  - `\u` - 下一条未翻译条目
+  - `\U` - 上一条未翻译条目
+  - `\f` - 下一条fuzzy条目
+  - `\F` - 上一条fuzzy条目
+  - `\c` - 将 msgid 的字符串拷贝至 msgstr
+  - `\d` - 删除 msgstr 字符串
+  - `\z` - 将字串标记为 fuzzy
+  - `\Z` - 移除字串标的 fuzzy 标记
+  - `\s` - 显示统计信息
+  - `\W` - 格式化文件
+
+  下载地址: http://www.vim.org/scripts/script.php?script_id=2530
+
+* kbabel, loaklize
+
+  Linux 平台有非常好用的图形界面工具辅助本地化，如 kbabel, lokalize 等工具可以方便地对 `.po` 文件进行编辑。
+
+  不过我还是喜欢在文本工作模式（VIM + po.vim），尤其是切换到 Mac OS X 平台后无法用到 kbabel 和 lokalize。
+
 ## 术语表 ##
 
 已翻译内容中涉及到的术语的翻译做到了基本一致，若遇到不确认的术语请先在已翻译内容中查找，恕不一一列举。