Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

  • Mood:
  • Music:

给 fedora-cn 邮件列表的信,有关 docs-common

Hi, all

我需要记录一下 fedora docs-common 更新后,对 fedora-cn 的翻译过程有哪些影响,虽然现在翻译工作进展很缓慢,但是总比不记录要好 :)

fedora 的文档是 docbook xml 格式的。经过前段时间的调整后,在 cvs 中的结构是这样,每个文档主题在自己的单独的目录中,这个目录中除了文档特有的文件之外,还有一个 Makefile,这个 Makefile 非常简单,只记录了要生成的语言列表,以及文档的名称,其他的处理步骤都放在了 ../docs-common/Makefile.common 中,当然,一个特定的文档也可能添加自己的依赖关系和处理步骤,不过目前还没有。例如,yum-software-management/Makefile 是这样

LANGUAGES       = en zh_CN
DOCBASE           = yum-software-management
include  ../docs-common/Makefile.common

对于文档撰写者,这样简单了许多。对文档撰写者的要求是,每个 xml 文件的文件名都必须以语言结尾。也就是说,英文的文档必然是 *-en.xml 的样式,而我们翻译的结果也必然都是 *-zh_CN.xml,这是基本的约定。

这样的约定带来的结果就是
1. extract.sh 和 merge.sh 可以更简单了,并且这两个脚本可以不加修改的用在所有文档中了。脚本存在还是有必要的,因为 xml entities 的原因,必须将实体引用的 & 转换之后才能再使用 xml2po 处理。现在这两个脚本不必每次都导入 cvs 了,算是工作轻松了许多 :)

//  extract.sh
#!/bin/sh
TLANG=zh_CN

# extract
for i in `ls *-en.xml`; do
        POTFILE=`basename $i .xml`
        POTFILE=${POTFILE%-en}.pot
        XMLFILE=`basename $i`
        echo $XMLFILE '-->' $POTFILE
        sed -i".orig" -e "s/\&/\&/g" $i
        xml2po -k -o $POTFILE $i >/dev/null 2>&1
        mv $i.orig $i
done;

# merge
msgcat *.pot > $TLANG.pot
msgmerge -U translation/$TLANG.po $TLANG.pot
msgfmt --statistics translation/$TLANG.po

// =========================

// merge.sh
#!/bin/sh
TLANG=zh_CN

# merge
for i in `ls *-en.xml`; do
        POTFILE=`basename $i .xml`
        POTFILE=${POTFILE%-en}.pot
        XMLFILE=`basename $i .xml`
        XMLFILE=${XMLFILE%-en}-$TLANG.xml
        echo $POTFILE '-->' $XMLFILE
        sed -i".orig" -e "s/\&/\&/g" $i
        xml2po -k -p translation/$TLANG.po $i > $XMLFILE
        mv $i.orig $i
        sed -i -e "s/\&/\&/g" $XMLFILE
done;

当然,如果不使用 xml2po 来导出 po 文件,这个脚本和这套处理步骤也没有意义。各个翻译团队用的工具实际是各不相同的。

使用时注意路径。为了方便操作不同的 cvs,zh_CN.po 和待翻译的 xml 没有放在相同的目录,而是放在 translation 子目录下。extract.sh 和 merge.sh 默认对这个目录下的 zh_CN.po 进行操作。中间生成的 pot 文件和 *-zh_CN.xml 文件仍然是和待翻译的 xml 在同一个目录中,make 编译的结果也在待翻译的 xml 目录中,但是不会影响 cvs。

2. 还是和 xml2po 以及实体引用有关。造成麻烦的是 DTD 中的实体。每篇文档都有一个主文档,在其中定义了 % FEDORA-ENTITIES-EN 为对 docs-common/common/fedora-entities-en.ent 的引用,然后用 %FEDORA-ENTITIES-EN; 进行替换。这样,主文档中的实体定义就可以非常简洁,方便文档撰写者。但是,在 xml2po 的合并处理中会进行这个实体的替换,因此在执行了 merge.sh 之后必须手动编辑这个主文件,把替换的结果删掉,重新加入 %FEDORA-ENTITIES-EN 这一行。虽然不是很困难,但是每次 make 编译前都需要做这个操作确实有些麻烦。这是 xml2po 的缺陷。

3. 和上述命名约定有关,每个 xml 的文件名是以 -en 结尾的。因此在主文档中,如果定义了各个章节的实体,那么在 make 编译前必须把这些实体替换为 -zh_CN。
也可以在 merge 中增加判断,不对主文档进行操作。但是主文档中也包含了待翻译的信息,。。。。也许应该只做一次操作,加一个小小的判断。也许应该采用更仔细的操作。


大致的情况就是这样。使用 extract.sh 得到待翻译的内容,和已有的翻译 zh_CN.po 合并,然后翻译待翻译内容,最后用 merge.sh 合并。合并之后,进行上面说的两项手动处理之后,就可以 make 编译了。默认的目标是制作一个很大的一页的 HTML,一个拆分成多页的 HTML 并放在一个子目录下,和一个 tar.gz 打包。在 tar.gz 打包中包含拆分方式的所有内容,因此可以直接上传到网站和论坛上。


BTW, http://fedora.gro.clinux.org 的网页按照 fedoraproject.org 的样式更新过了。我们没有资源和精力维护自己的 wiki 和论坛,但是应当充分利用已有的资源。fedoraproject.org 的 wiki 对中文支持得很好。http://fedora.linuxsir.org 和 LinuxSir.Org 的 fedora 论坛都是无价的资源。
我想我对 fedora 的认识有点模糊,也许需要仔细思考一段时间了。


--
bbbush ^_^

对于翻译过程中遇到的这几个 xml2po 问题,还望懂行的人教我!fundawang 老大不知道为什么不去 LinuxSir.Org 了,呜呜呜~~

Tags: gnu
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments