前几天Junwen同学翻译了Android设计指南的网页，由于他用的SourceForge的Web空间访问限额有限，我在自己的服务器上给他做了一个镜象站点。于是就想到了多镜象站点同步以及本地化语言版本与上游英文版网页之间的同步问题，正好我是GNU.org的中文翻译组的一员，在这里跟大家简单分享一下GNU网站的本地化框架，也算是补交了去年在NJLUG活动中曾经承诺过的一份作业。
以前，GNU网站的本地化是由各本地化翻译小组手工完成维护的，翻译组协调人确定要翻译的页面，翻译组成员自己从GNU网站或CVS上下载html网页，直接在网页上进行翻译，然后把html网页提交到翻译组的CVS中，经过审阅后，由具有GNU网站提交权限的人直接把html文件提交到GNU网站上。
这种简单的做法带来的问题主要有两个：
- 本地化版本的维护问题。由于全部是手工操作，很容易出现本地化版本与英文原始版本之间不同步的问题，而且这样的不同步很难被发现和跟踪。
- 网站改版的问题。当英文版网站进行大规模网页页面结构化调整时，即使页面上文字内容没有变，所有的翻译版本都需要全部手工进行更新。
大约是2008年开始，GNU开发了GNUnited Nation，简称GNUN，作为GNU网站本地化框架。GNUN实质上是一些脚本、DTD和Makefile，通过这些脚本，对GNU的网页自动进行各种必要的字符串提取、替换和合法性验证。
GNUN的实现基于在自由软件本地化中广为使用的gettext，GNUN从原始的英文HTML网页中提取需要翻译的字符串，生成gettext的.pot文件，各语言翻译组基于.pot文件翻译形成对应各自的语言的.po文件，最后GNUN系统再依据这些po文件生成相应语言版本的本地化网页。
.---<--- * Original ARTICLE.html | | .---> ARTICLE.pot ---> * ARTICLE.LANG.po --->---. `---+ | `--->---. .------<----------------------------' | | | `---. | +---> Translated ARTICLE.LANG.html `-------'
这是GNUN的工作流程图，其中需要人工干预的只有图中打星号的两个步骤，其它都可以自动化完成。
- 编写原始ARTICLE.html：由GNU的Web维护小组完成。
- 翻译ARTICLE.LANG.po文件：由GNU各语言翻译组完成。
对于翻译组，GNUN框架中也提供了很轻量级的脚本用于从合并更新.po文件和自动检查.po文件的翻译进度，用起来很方便。
其实，从现在的眼光看，用gettext做网页的本地化也并不是什么新鲜的事儿，比如大家现在在用的WordPress就是这样处理的。不过，你有没有注意到GNUN跟WordPress中gettext的用法的不同呢？
在WordPress（或其它大部分用gettext的软件项目）中，要翻译的字符串资源常常会用类似于_(“”)这样的形式来标记，这样xgettext工具才能从中正确的提取出需要的翻译的资源，当然也是为了程序编译后运行起来时真正能把字符串完成翻译。而GNU的那些静态HTML网页上并没有也不方便用这样的标记去标记所有的字符串，GNUN实际上是一个特别针对GNU网站做的框架，它直接通过一些预定义的固定规则去处理GNU网页上的内容，在已知网页内容架构的情况下，跟据HTML页面中各标签本身的语意，去提取字符串内容。.po文件翻译好后，也是由固定的脚本直接把字符串替换回原始的网页，从而实现页面翻译。所以，暂时GNUN其实并不能成为一个通用的网站本地化框架，目前它只能用在GNU的网站上。但是这样的一套处理思路，也许在有些特定的情况下还是值得借鉴的。
