i18n 折腾感受
这个年注定不好过。也好，可以有更多的时间写“无用”的代码和博客了。
去年 9 月接手 giplet，初衷只是想自己用的更方便一点。没想到竟得到些许反馈。或许是因为这辈子为了糊口写了扔了太多无用的代码，只是零星几条反馈就让我很感动，觉得自己应该再做点什么。想来想去，决定加上 i18n 支持，没想到就这么一点点想法也折腾了好几天。
主要问题还是对工具链不熟。
之前为了上手 autoconf/automake，就花了不少精力。好在这方面中文入门资料质量尚可（比如 IBM 的这一篇就不错），遇到更多问题时摘 gnu 官方文档的相关章节细细咀嚼即可。只剩最后一个疑难杂症时，所幸及时读到了 m4 文档中的这一段，便悬崖勒马，很 dirty 很 ugly 地应付了事，至今未知其所以然。
如今引入 i18n，实际上也就是要熟悉另外一条开源工具链，具而言之就是 gettext 和 intltool。却未料这类资料如此之少。在代码中应用 gettext 尚有几篇中文，但如何使用 intltool 在一个 autoconf/automake 的项目中加入 i18n 支持竟连英文都鲜可搜到。这里推荐一篇，以期节省大家时间。其实这 I18N-HOWTO 本是 intltool 自己的文档，理应已在灯火阑珊处，只是不知为何 archlinux 打包时竟未收录此文件，此刻给我造成了麻烦——最权威的第一手资料，当然应该在本机文档里，这样的第一反应是没有错的。
提醒一下，这篇 howto 略显过时——如第 7 步，现在的标准做法已经不是在 configure.in 中使用 ALL_LINGUAS 变量，而是单独维护一个 po/LINGUAS 文件——但并不妨碍掌握 intltool 的基本使用方法，所以关于 intltool 这里就不再赘述了。
下面说说工具以外的地方。
给 gnome applet 添加 i18n 支持，需要做到四点：
上述第 4 条搞定之后，giplet 0.2.0 就可以发布了。如果实在找不出问题就准备很 dirty 很 ugly 地把那个小 xml 文件塞回 python 代码里，拼字符串谁不会……
去年 9 月接手 giplet，初衷只是想自己用的更方便一点。没想到竟得到些许反馈。或许是因为这辈子为了糊口写了扔了太多无用的代码，只是零星几条反馈就让我很感动，觉得自己应该再做点什么。想来想去，决定加上 i18n 支持，没想到就这么一点点想法也折腾了好几天。
主要问题还是对工具链不熟。
之前为了上手 autoconf/automake，就花了不少精力。好在这方面中文入门资料质量尚可（比如 IBM 的这一篇就不错），遇到更多问题时摘 gnu 官方文档的相关章节细细咀嚼即可。只剩最后一个疑难杂症时，所幸及时读到了 m4 文档中的这一段，便悬崖勒马，很 dirty 很 ugly 地应付了事，至今未知其所以然。
Some people find m4 to be fairly addictive. They first use m4 for simple problems, then take bigger and bigger challenges, learning how to write complex sets of m4 macros along the way. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers.
如今引入 i18n，实际上也就是要熟悉另外一条开源工具链，具而言之就是 gettext 和 intltool。却未料这类资料如此之少。在代码中应用 gettext 尚有几篇中文，但如何使用 intltool 在一个 autoconf/automake 的项目中加入 i18n 支持竟连英文都鲜可搜到。这里推荐一篇，以期节省大家时间。其实这 I18N-HOWTO 本是 intltool 自己的文档，理应已在灯火阑珊处，只是不知为何 archlinux 打包时竟未收录此文件，此刻给我造成了麻烦——最权威的第一手资料，当然应该在本机文档里，这样的第一反应是没有错的。
提醒一下，这篇 howto 略显过时——如第 7 步，现在的标准做法已经不是在 configure.in 中使用 ALL_LINGUAS 变量，而是单独维护一个 po/LINGUAS 文件——但并不妨碍掌握 intltool 的基本使用方法，所以关于 intltool 这里就不再赘述了。
下面说说工具以外的地方。
给 gnome applet 添加 i18n 支持，需要做到四点：
- 代码中的字符串。
最好办，都是 gettext 解决方案，资料最多，略。 - server 文件中的字符串。
这个文件相当于 applet 的描述文件，“右键 -> 添加到面板”里的文本就来自这里。这里也好办，最终生成的 .server 文件（xml）应该包含所有语言，编译完了看一眼就知道有没有问题。相应的 Makefile.am 里不要忘了“@INTLTOOL_SERVER_RULE@”。 - 如果有的话，glade 界面中的字符串。
glade 的界面描述文件也是 xml，但不会在编译之后就把所有翻译都塞进来。有没有问题只有在运行时才知道。这里需要注意的是，在 python 里，用 gtk.glade.XML() 来创建窗口的时候，如果不指定第三个参数（即文本域），默认会使用当前的 python 文件名。如果这个文件名跟 GETTEXT_PACKAGE 不一样的话，会因为找不到文本域而匹配失败，所以最好还是手动加上。 - 如果有的话，其他 xml 文件中的字符串。
这个是最麻烦的（到现在也没完美解决）。除去 glade 之外，还有一些用于描述界面的 xml 文件也只能在运行时调试。但是它比 glade 的要简单的多——比如在 giplet 里，它只是个右键菜单——所以不是通过 gtk.glade.XML() 而是 applet.setup_menu_from_file() 创建出来的。所以出现了其他所有地方都 i18n 了，就剩一个右键菜单的情况。做了很久的排除试验也没能定位问题。这几天实在没辙了，用中文翻译当“糖衣炮弹”写信向 paul（music applet，也是个 python，i18n 的 gnome applet 项目的作者）求助了一下，但是还没有结论。
上述第 4 条搞定之后，giplet 0.2.0 就可以发布了。如果实在找不出问题就准备很 dirty 很 ugly 地把那个小 xml 文件塞回 python 代码里，拼字符串谁不会……
评论