现在汉化得也很多了，但是由于汉化本身分成很多个版块跟人，所以，就会存在同样的词条翻译成不同的问题。

谁负责在所有 po 文件中校对是否所有相同词条都被翻译成相同的内容呢？（典型的例子是人名地名）。

吾辈。

我制作了一个工具，能够做到下面的事情：

1。检查所有 .po 文件中的冲突翻译，也就是msgid相同，但msgstr不同的，例如目前(Normal)这个词在不同的战役中就有五种不同翻译。

2。根据一个指定的 msgid ，在所有 .po 文件中查询现有翻译。这样新写翻译的时候就有了查询的依据。（数据现在是有了，如果有必要，这个理论上可以自动生成一个表格，但是需要整理成合适的格式。）

3。按逗号拆分所有小人物人名，用于条目 2 的单独查询。

现在可以在 googlecode 的那个 hg 仓库中运行，
经查询，不按逗号拆分时，有169处冲突翻译，按逗号拆分时，有458处冲突翻译。

整理这几百处冲突翻译是个系统工程，但是在这个工程完成之前，既然有了检查工具，我们至少应该保证每次提交新的翻译时，冲突数量不会增加。

如果把我的 google 帐户 pan.shizhu 增加进去，我可以提交相关代码到 hg 仓库。这样你的检查就有了依据。

谢谢哈~好的~

已经添加了pan.shizhu的写入权限。

使用gtranslator，把文字加入数据库。

以前的版主 sylecn 专门搞整合。

引用:

原帖由 luojie-dune 于 2010-7-27 12:34 发表
使用gtranslator，把文字加入数据库。
以前的版主 sylecn 专门搞整合。

办法自然是有很多的，不过显然以前大家都没有用，不然不会现在有如此之多（458个）的冲突。

我已经上传了程序 cloudidust 看看，有什么想法的，可以再讨论。

在Windows下程序输出有乱码，我做了一下修改，以后win下用GBK(cp936)输出，linux下用UTF8输出。

此外发现翻译里有GBK不能编码的字符存在（主要是部分没有翻译过的人名里的重音字母）。

修改后的checkref.py已经同步到google code了。

引用:

原帖由 CloudiDust 于 2010-7-27 19:00 发表
在Windows下程序输出有乱码，我做了一下修改，以后win下用GBK(cp936)输出，linux下用UTF8输出。
此外发现翻译里有GBK不能编码的字符存在（主要是部分没有翻译过的人名里的重音字母）。
修改后的checkref.py已经同步到google  ...

其实 Windows 下可考虑输出为 little endian 的 ucs2 编码，这是 windows 的内部编码，GBK 编码在 windows 处理时貌似都是转换过的。 ucs2le 编码是可以用记事本直接打开的。这样可以处理不能编码的问题。

当然，如果仅仅是要处理不能编码的问题，可以考虑编码成 GB18030，因为 GB18030 是可以完全兼容所有 unicode 编码字符的。

嗯，UTF16-LE确实是内部编码来着，其实这个修改原意是想让控制台输出不要乱码，我的习惯是Win下用NP++开纯文本文件所以重定向之后无所谓了……

记得UTF编码族如果要让记事本正常打开的话得有BOM才行。

引用:

原帖由 CloudiDust 于 2010-8-11 23:29 发表
嗯，UTF16-LE确实是内部编码来着，其实这个修改原意是想让控制台输出不要乱码，我的习惯是Win下用NP++开纯文本文件所以重定向之后无所谓了……
记得UTF编码族如果要让记事本正常打开的话得有BOM才行。 ...

windows 的控制台只能接受GBK和GB18030，所以如果有 print 输出就必须是 GBK 和 GB18030。事实上用 GB18030 要更好，因为某些 Unicode 无法编码成 GBK。而用 GB18030 的话，大多数可以被正常编码，虽然某些字符因为字库原因无法显示，但是至少不会出现编码错误。

如果输出到文件的话，可以是 UCS－2LE，在 Windows 中，唯一一种不需要 BOM 的 unicode 编码就是 UCS－2LE。其他的都需要BOM。