Ubuntu 简体中文小组工作指南:修订间差异
(未显示1个用户的10个中间版本) | |||
第11行: | 第11行: | ||
#详细阅读本文档和全部与工作相关和要翻译内容相关的文档; | #详细阅读本文档和全部与工作相关和要翻译内容相关的文档; | ||
#最好准备一本英语词典或者使用在线词典以方便查阅,术语、缩写等请先搜索 Google、查阅 Wikipedia 文章以及 Answer.com 上的内容。 | #最好准备一本英语词典或者使用在线词典以方便查阅,术语、缩写等请先搜索 Google、查阅 Wikipedia 文章以及 Answer.com 上的内容。 | ||
#若离线翻译的话找一个好用的编辑器,Poedit、Virtaal、Emacs PO-Mode 都可以。如果要用纯文本编辑器的话请一定先记住 PO 转义字符。 | |||
= 基本要求 = | = 基本要求 = | ||
第32行: | 第33行: | ||
;<tt>\n</tt>:换行 | ;<tt>\n</tt>:换行 | ||
;<tt>\t</tt>:水平制表符 | ;<tt>\t</tt>:水平制表符 | ||
;<tt>\ | ;<tt>\\</tt>:反斜杠<tt>\</tt> | ||
;<tt>\"</tt>:直双引号<tt>"</tt> | ;<tt>\"</tt>:直双引号<tt>"</tt> | ||
第42行: | 第43行: | ||
“TRUE”和“FALSE”多出现于 gtk+ 和 Gconf,以及很多 Glade 所生成的文件中(这些文件以 .glade 为文件名结尾),不要翻译它们。如果程序找不到它们,将会出现问题。 | “TRUE”和“FALSE”多出现于 gtk+ 和 Gconf,以及很多 Glade 所生成的文件中(这些文件以 .glade 为文件名结尾),不要翻译它们。如果程序找不到它们,将会出现问题。 | ||
当你看到这些不该翻译的字串时,也应同时向 PO 文件头 <tt>Report-msgid-Bugs-To</tt> 指定的地方发送一个 Bug 报告提醒开发者检查。 | |||
== 标点的使用 == | == 标点的使用 == | ||
第48行: | 第51行: | ||
<!-- Arthur2e5::zh_variants: 换码在 CN 叫转义。--> | <!-- Arthur2e5::zh_variants: 换码在 CN 叫转义。--> | ||
#英文中的 , 在中文中可能是 | #英文中的 , 在中文中可能是{{code|,}}或者 {{code|、}}。如果上下文是一串列表,那么要按照中文习惯用顿号。 | ||
#英文中的 . 在中文中应该是 | #英文中的 . 在中文中应该是{{code|,}}、{{code|。}} 甚至 {{code|;}}。具体使用视上下文而定,多数是{{code| 。}} 。 | ||
#英文中的 \"%s\" 在 GUI 程序中应该翻译为 “%s”, 而不是 \"%s\" 或者 \“%s\”,而且后者是不符合转义序列要求的。即在 GUI 程序中`something' 和 'something' 以及 \"something\" 都应该翻译为 “某事” | #英文中的 \"%s\" 在 GUI 程序中应该翻译为 “%s”, 而不是 \"%s\" 或者 \“%s\”,而且后者是不符合转义序列要求的。即在 GUI 程序中`something' 和 'something' 以及 \"something\" 都应该翻译为 “某事” | ||
#:Request For Edit: 大家都用 GUI 编辑器了,大概也不用在'''标点'''这里提转义序列了吧。LP 网页也是直接原文显示的。况且下面都直接把 PO 格式拆掉了(比我还狠)……(2e5-deprecate-escape-display) | |||
#英文中的 \"%s\" 在 CLI 程序中应保持为 \"%s\",因为全角引号在文本界面下显示不够美观,所以使用半角双引号,即在 CLI 程序中`something' 和 'something' 以及 \"something\"都应译作\"某事\" | #英文中的 \"%s\" 在 CLI 程序中应保持为 \"%s\",因为全角引号在文本界面下显示不够美观,所以使用半角双引号,即在 CLI 程序中`something' 和 'something' 以及 \"something\"都应译作\"某事\" | ||
#英文中的 : 应该翻译为:(全角)而不是 :(半角), 而作为分隔符时(例如时间),: 保留为英文(半角)的, 因为这个时候不是标点符号 | #英文中的 : 应该翻译为:(全角)而不是 :(半角), 而作为分隔符时(例如时间),: 保留为英文(半角)的, 因为这个时候不是标点符号 | ||
#:RFE: GNOME HIG 中时间使用 Unicode "RATIO"。真的,需要有一条“尊重原文 Unicode”。(2e5-unicode-timesep-ratio) | |||
#英文中的 ( ) 应该保持不变。由于全角小括号( )很难看,也占地方,所以一律使用半角小括号 ( ) | #英文中的 ( ) 应该保持不变。由于全角小括号( )很难看,也占地方,所以一律使用半角小括号 ( ) | ||
#:RFE: 无意义的 workaround。(2e5-unicode-cjk-paren) | |||
#英文中的 ... 应该保持不变。由于翻译的时候常常难以分清哪些条目是菜单项,哪些条目是一般语句,而后者才能使用中文的省略号 ……,所以现在统一翻译为 ... | #英文中的 ... 应该保持不变。由于翻译的时候常常难以分清哪些条目是菜单项,哪些条目是一般语句,而后者才能使用中文的省略号 ……,所以现在统一翻译为 ... | ||
#:RFE: 违反 GNOME HIG 和 Inkscape。(2e5-unicode-ellipsis) | |||
#英文中的 -- 应该保持不变。由于全角破折号 —— 兼容性不好,有时显示为两个方格,所以不再使用。 | #英文中的 -- 应该保持不变。由于全角破折号 —— 兼容性不好,有时显示为两个方格,所以不再使用。 | ||
#:RFE: 无意义。支持几千个汉字不支持英文也要用的 emdash,Windows 95 都不至于吧。(2e5-unicode-emdash) | |||
#遇到 %q 标记的时候,代表此标记显示的是一段引用内容,程序运行时将自动在其两端加上双引号,故不需另加引号。 | #遇到 %q 标记的时候,代表此标记显示的是一段引用内容,程序运行时将自动在其两端加上双引号,故不需另加引号。 | ||
#:RFE: Programming Language Literal。 | |||
== 关于空格 == | == 关于空格 == | ||
第68行: | 第77行: | ||
assumed to be 1. | assumed to be 1. | ||
中文: | 中文: | ||
参数 start_num 指定开始搜索的字符位置。第一个字符序号为 1。如果省略 | 参数 start_num 指定开始搜索的字符位置。第一个字符序号为 1。如果省略 | ||
start_num,默认它为 1。 | |||
</pre> | </pre> | ||
第76行: | 第85行: | ||
对于 CLI (命令行界面) 程序,使用 monospace 等宽字体的场合: | 对于 CLI (命令行界面) 程序,使用 monospace 等宽字体的场合: | ||
* | * 旧版:<s>因为文本界面字体显示的原因,一般推荐汉字后接英文时不留空格,英文后接汉字时留一个空格,在显示的时候不会因为英文前后都有空格而造成英文前面的空余空间远大于后面造成的不美观。</s> | ||
*新意见:原意见汉字夹着英文,英文前不留空格,英文后加空格,结果英文跟前面的中文粘在一起,容易造成视觉上的混淆,而且英文两边空间不对称,那样的不对称会造成不美观。强烈建议不要为 CLI | * 新意见:原意见汉字夹着英文,英文前不留空格,英文后加空格,结果英文跟前面的中文粘在一起,容易造成视觉上的混淆,而且英文两边空间不对称,那样的不对称会造成不美观。强烈建议不要为 CLI 程序制定这样前后不一致的特例。 | ||
例如: | |||
<pre>英文:"Set LC_ALL='C' to work around the problem." | <pre>英文:"Set LC_ALL='C' to work around the problem." | ||
中文:请设置LC_ALL='C' 以避免出现问题。 # 原意见,不推荐 | 中文:请设置LC_ALL='C' 以避免出现问题。 # 原意见,不推荐 | ||
中文:请设置 LC_ALL='C' 以避免出现问题。 # 新意见,推荐改用。</pre> | 中文:请设置 LC_ALL='C' 以避免出现问题。 # 新意见,推荐改用。</pre> | ||
* 原意见:对于半角小括号,其两侧不加空格: | 可以使用正则表达式快速修整采用原意见的翻译: | ||
<pre>perl -CIOED -p -e 's/(\p{Block=CJK_Unified_Ideographs})([-A-Za-z0-9\[\(\%'\''])/$1 $2/g' foo.po > new.po | |||
mv new.po foo.po</pre> | |||
* <s>原意见:对于半角小括号,其两侧不加空格:</s> | |||
* 新意见:对于半角小括号,其两侧与文字之间要加空格,但翻译快捷键时则不加空格: | * 新意见:对于半角小括号,其两侧与文字之间要加空格,但翻译快捷键时则不加空格: | ||
第91行: | 第106行: | ||
* 原意见:对于全角双引号,其两侧不加空格: | * 原意见:对于全角双引号,其两侧不加空格: | ||
* 新意见:在现代的 Linux 系统里,因为优先以英文字体优先,双引号 (U+201C 和 U+201D) 只会以标准的半角形式显示出来,而在较旧 CJK 字体里的非标准的“全角双引号”,用户几乎没机会见到了。如果是这样,也许我们需要在按照上下文情况,在适当情况下在开引号前和关引号后添加空格。 | * 新意见:在现代的 Linux 系统里,因为优先以英文字体优先,双引号 (U+201C 和 U+201D) 只会以标准的半角形式显示出来,而在较旧 CJK 字体里的非标准的“全角双引号”,用户几乎没机会见到了。如果是这样,也许我们需要在按照上下文情况,在适当情况下在开引号前和关引号后添加空格。 | ||
**驳:这种 workaround 并不有趣,单交给 <tt>locl</tt> (i.e. HTML <tt>lang</tt>>) | **驳:这种 workaround 并不有趣,单交给 <tt>locl</tt> (i.e. HTML <tt>lang</tt>、<tt>LC_ALL</tt>) 就好,不空其实也不至于过分丑陋(甚至无意间中和了部分方引号使用者“简体中文弯引号太‘空’”的说法)。况且 fontconfig 现在都会按照每个语言进行匹配,发行版也会给中文专门写优先级。 | ||
例1:默认显示: | 例1:默认显示: | ||
第158行: | 第173行: | ||
中文:匹配规则 %2$d 的文章有 %1$d 个</pre> | 中文:匹配规则 %2$d 的文章有 %1$d 个</pre> | ||
即用 1$、2$、3$ 等符号标明参数在原文里出现的位置。同时,任何一个参数的顺序进行了调整,则在这一句译文中所有参数都必须注明原文位置,否则无法通过格式检查。 | 即用 1$、2$、3$ 等符号标明参数在原文里出现的位置。同时,任何一个参数的顺序进行了调整,则在这一句译文中所有参数都必须注明原文位置,否则无法通过格式检查。 | ||
:RFE: 直接提手册里面编程语言格式多好。话说这样插内容总觉得在贴小广告,但你们又不愿意搞讨论页我怎么办(发 20 封邮件一个个谈?)。(2e5-pos-fmt-proglang) | |||
== 注意注释 == | == 注意注释 == | ||
第167行: | 第184行: | ||
#. Note also that specifying a width as in %5b is erroneous as strftime | #. Note also that specifying a width as in %5b is erroneous as strftime | ||
#. will count bytes rather than characters in multibyte locales.</pre> | #. will count bytes rather than characters in multibyte locales.</pre> | ||
当然,有一些文件内主要是地名或国家名,开发者会省略“TRANSLATORS”直接给出提示,例如: | 当然,有一些文件内主要是地名或国家名,开发者会省略“TRANSLATORS”直接给出提示,例如: | ||
<pre>#. CN - China. (The official ISO 3166 short English name does | <pre>#. CN - China. (The official ISO 3166 short English name does | ||
#. not include "The People's Republic of".)</pre> | #. not include "The People's Republic of".)</pre> | ||
:RFE: 错误。有没有 TRANSLATORS 头和内容是什么没有直接联系,都是 xgettext 的事情。(2e5-comment-exists-translators) | |||
== 关于换行 == | == 关于换行 == | ||
第194行: | 第214行: | ||
</pre> | </pre> | ||
但是,如果有 c-format 等编程语言格式标记,或者原文中有强迫换行标记“\ | 但是,如果有 c-format 等编程语言格式标记,或者原文中有强迫换行标记“\n”,那就要手工调整译文的换行,以便能最终正确地显示在程序界面上。原则是译文行宽不大于原文行宽,否则可能译文显示超出原有区域,或者译文后面部分被截去,很难看。对于含有 HTML 标记的长译文还需要在浏览器中预览显示效果(如果您了解 HTML 基本语法的话),酌情调整行宽。例如: | ||
:RFE: 错误。PO 文件本身无论如何都不管怎么接起来的,这种完全是为了纯文本目测编辑源文件方便。另外不 wrap 的 HTML 引擎……(2e5-linebreak) | |||
<pre>英文(c-format): | <pre>英文(c-format): | ||
Error opening file '%s':\n | Error opening file '%s':\n | ||
第320行: | 第342行: | ||
= 后记 = | = 后记 = | ||
本文基于 [https://docs.google.com/View?docID=0ATMcdwxwhYuQZGM1eHJuNGtfMWZ6MjRwd2c0&revision=_latest&hgd=1 自由软件中文化工作指南(L10N)] 修改而成,是对原文的精简和针对 Launchpad 需要进行的调整。原文是以 KDE 中国站点上刊载的 [http://www.kdecn.org/l10n/method.php I18N/L10N工作流程] 为蓝本所修订的工作指南,过程中参考了 [http://groups.google.com/group/i18n-zh i18n-zh] 以及 [http://live.gnome.org/TranslationProject/ GNOME Live] 上的一些文章。 | 本文基于 [https://docs.google.com/View?docID=0ATMcdwxwhYuQZGM1eHJuNGtfMWZ6MjRwd2c0&revision=_latest&hgd=1 自由软件中文化工作指南(L10N)] 修改而成,是对原文的精简和针对 Launchpad 需要进行的调整。原文是以 KDE 中国站点上刊载的 [http://www.kdecn.org/l10n/method.php I18N/L10N工作流程] 为蓝本所修订的工作指南,过程中参考了 [http://groups.google.com/group/i18n-zh i18n-zh] 以及 [http://live.gnome.org/TranslationProject/ GNOME Live] 上的一些文章。 | ||
繁体中文翻译小组有一份基于本文档的[https://docs.google.com/document/d/1Zs4CS_ZjN-imnImq4aEsiVYih8zkIkVZTSQim13_kYg 繁体中文翻译指南],Arthur2e5 重制顺便重写过一个较常更新的 [https://repo.aosc.io/misc/l10n/zh_CN_l10n.pdf 可编辑 Hybrid-PDF 版本]。这两个分支中都可能有一些值得注意的新意见。 | |||
= 相关链接 = | = 相关链接 = | ||
第330行: | 第354行: | ||
= 联系方式 = | = 联系方式 = | ||
* Lie_Ex < | * Lie_Ex <lilith_ex (AT) 163 (DOT) com> | ||
* [[User:Happyaron|Aron Xu]] <happyaron (DOT) xu (AT) gmail (DOT) com> | * [[User:Happyaron|Aron Xu]] <happyaron (DOT) xu (AT) gmail (DOT) com> | ||
* [https://lists.ubuntu.com/mailman/listinfo/ubuntu-zh ubuntu-zh] 邮件列表 | * [https://lists.ubuntu.com/mailman/listinfo/ubuntu-zh ubuntu-zh] 邮件列表 |
2017年2月1日 (三) 15:10的最新版本
本文是 Ubuntu/Launchpad 简体中文小组的工作指南,主要针对翻译过程中的流程、格式等事项进行了说明。欢迎对本文内容进行讨论,相关的历史背景和联系方式请参阅文末。关于 Launchpad 的使用方法,请参阅 Launchpad 在线翻译指南,常见问题解答请参阅 Launchpad 在线翻译 FAQ。
由于在 Launchpad 上进行的针对 Ubuntu 发行版的翻译有相当的部分是无法直接反馈到上游社区的,而在上游社区的贡献会自动引入到 Ubuntu 中,所以在开始翻译前请考虑直接在上游进行贡献,如 GNOME,KDE 等项目小组,详情请参见文末联系方式。
准备
- 我们的原则是质量优先,不赞成翻译自己不熟悉的软件或文档;
- 详细阅读本文档和全部与工作相关和要翻译内容相关的文档;
- 最好准备一本英语词典或者使用在线词典以方便查阅,术语、缩写等请先搜索 Google、查阅 Wikipedia 文章以及 Answer.com 上的内容。
- 若离线翻译的话找一个好用的编辑器,Poedit、Virtaal、Emacs PO-Mode 都可以。如果要用纯文本编辑器的话请一定先记住 PO 转义字符。
基本要求
- 准确表述原文的意思;
- 中文应该意思清晰且符合中文表达习惯;
- 原文如果表达不清晰,中文应该意译,并且应根据上下文和注释进行推断并填补相应的信息;
- 情况 3 不能太多;
- 对同样短语的翻译,前后必须一致。
- 使用“您”而不是“你”。
- 不要使用机器翻译的成果来提交,也就是说您可以使用 Google Translate 来帮助您理解内容,但是不能不经考虑就把其自动翻译的结果放在翻译里。
格式要求
特殊字符
转义字符和取消转义
标准 gettext 格式中的转义字符同 C 语言中的基本相同,常用的有以下几个:
- \n
- 换行
- \t
- 水平制表符
- \\
- 反斜杠\
- \"
- 直双引号"
您不需要将同样数量的格式标记放在翻译中,但是如果它们之一有在原文开始或者结束位置的时候,您必须在翻译中使之包含在对应的开始或者结束之处。
如果要显示非转义字符,则需要使用 \ 来表明取消转义,如 " (半角双引号)在 PO 文件中表示字符串的开始或者结束,如果要在内容中使用该符号,则需输入 \"。于是 \"\\t\" 实际上表示字符串 "\t"。
TRUE 和 FALSE
“TRUE”和“FALSE”多出现于 gtk+ 和 Gconf,以及很多 Glade 所生成的文件中(这些文件以 .glade 为文件名结尾),不要翻译它们。如果程序找不到它们,将会出现问题。
当你看到这些不该翻译的字串时,也应同时向 PO 文件头 Report-msgid-Bugs-To 指定的地方发送一个 Bug 报告提醒开发者检查。
标点的使用
一般的原则是:除了小括号、省略号和破折号保留不变以外,都应该使用中文(全角)标点符号。英文标点符号后方常常跟随有一个半角空格,请在翻译成中文标点符号时将其去除。
- 英文中的 , 在中文中可能是
,
或者、
。如果上下文是一串列表,那么要按照中文习惯用顿号。 - 英文中的 . 在中文中应该是
,
、。
甚至;
。具体使用视上下文而定,多数是。
。 - 英文中的 \"%s\" 在 GUI 程序中应该翻译为 “%s”, 而不是 \"%s\" 或者 \“%s\”,而且后者是不符合转义序列要求的。即在 GUI 程序中`something' 和 'something' 以及 \"something\" 都应该翻译为 “某事”
- Request For Edit: 大家都用 GUI 编辑器了,大概也不用在标点这里提转义序列了吧。LP 网页也是直接原文显示的。况且下面都直接把 PO 格式拆掉了(比我还狠)……(2e5-deprecate-escape-display)
- 英文中的 \"%s\" 在 CLI 程序中应保持为 \"%s\",因为全角引号在文本界面下显示不够美观,所以使用半角双引号,即在 CLI 程序中`something' 和 'something' 以及 \"something\"都应译作\"某事\"
- 英文中的 : 应该翻译为:(全角)而不是 :(半角), 而作为分隔符时(例如时间),: 保留为英文(半角)的, 因为这个时候不是标点符号
- RFE: GNOME HIG 中时间使用 Unicode "RATIO"。真的,需要有一条“尊重原文 Unicode”。(2e5-unicode-timesep-ratio)
- 英文中的 ( ) 应该保持不变。由于全角小括号( )很难看,也占地方,所以一律使用半角小括号 ( )
- RFE: 无意义的 workaround。(2e5-unicode-cjk-paren)
- 英文中的 ... 应该保持不变。由于翻译的时候常常难以分清哪些条目是菜单项,哪些条目是一般语句,而后者才能使用中文的省略号 ……,所以现在统一翻译为 ...
- RFE: 违反 GNOME HIG 和 Inkscape。(2e5-unicode-ellipsis)
- 英文中的 -- 应该保持不变。由于全角破折号 —— 兼容性不好,有时显示为两个方格,所以不再使用。
- RFE: 无意义。支持几千个汉字不支持英文也要用的 emdash,Windows 95 都不至于吧。(2e5-unicode-emdash)
- 遇到 %q 标记的时候,代表此标记显示的是一段引用内容,程序运行时将自动在其两端加上双引号,故不需另加引号。
- RFE: Programming Language Literal。
关于空格
为了美观,通常建议在中文与英文、中文与阿拉伯数字、英文与阿拉伯数字之间加入一个半角空格。例如:
英文:Installing driver for %1 中文:正在安装 %1 的驱动程序
英文: Parameter start_num specifies the character at which to start the search. The first character is character number 1. If start_num is omitted, it is assumed to be 1. 中文: 参数 start_num 指定开始搜索的字符位置。第一个字符序号为 1。如果省略 start_num,默认它为 1。
不过,有时候有例如:“2013年6月5日
”的视觉效果就比“2013 年 6 月 5 日
”好。
对于 CLI (命令行界面) 程序,使用 monospace 等宽字体的场合:
- 旧版:
因为文本界面字体显示的原因,一般推荐汉字后接英文时不留空格,英文后接汉字时留一个空格,在显示的时候不会因为英文前后都有空格而造成英文前面的空余空间远大于后面造成的不美观。 - 新意见:原意见汉字夹着英文,英文前不留空格,英文后加空格,结果英文跟前面的中文粘在一起,容易造成视觉上的混淆,而且英文两边空间不对称,那样的不对称会造成不美观。强烈建议不要为 CLI 程序制定这样前后不一致的特例。
例如:
英文:"Set LC_ALL='C' to work around the problem." 中文:请设置LC_ALL='C' 以避免出现问题。 # 原意见,不推荐 中文:请设置 LC_ALL='C' 以避免出现问题。 # 新意见,推荐改用。
可以使用正则表达式快速修整采用原意见的翻译:
perl -CIOED -p -e 's/(\p{Block=CJK_Unified_Ideographs})([-A-Za-z0-9\[\(\%'\''])/$1 $2/g' foo.po > new.po mv new.po foo.po
原意见:对于半角小括号,其两侧不加空格:- 新意见:对于半角小括号,其两侧与文字之间要加空格,但翻译快捷键时则不加空格:
英文:Original idea and author (KDE1) 中文:原始创意和作者 (KDE1)
- 原意见:对于全角双引号,其两侧不加空格:
- 新意见:在现代的 Linux 系统里,因为优先以英文字体优先,双引号 (U+201C 和 U+201D) 只会以标准的半角形式显示出来,而在较旧 CJK 字体里的非标准的“全角双引号”,用户几乎没机会见到了。如果是这样,也许我们需要在按照上下文情况,在适当情况下在开引号前和关引号后添加空格。
- 驳:这种 workaround 并不有趣,单交给 locl (i.e. HTML lang、LC_ALL) 就好,不空其实也不至于过分丑陋(甚至无意间中和了部分方引号使用者“简体中文弯引号太‘空’”的说法)。况且 fontconfig 现在都会按照每个语言进行匹配,发行版也会给中文专门写优先级。
例1:默认显示:
英文: The APM Management subsystem seems to be disabled.\n Try executing \"apm -e 1\" (FreeBSD) and see if \n that helps.\n 中文: APM 管理子系统似乎被禁用了。试试执行“apm -e 1”(FreeBSD) 并看看是否有用。\n APM 管理子系统似乎被禁用了。试试执行 “apm -e 1” (FreeBSD) 并看看是否有用。\n
例2:强制设置 lang="zh-Hans" style="font-family: AR PL UMing CN, 宋体" 避开英数字体:
英文:
The APM Management subsystem seems to be disabled.\n
Try executing \"apm -e 1\" (FreeBSD) and see if \n
that helps.\n
中文:
APM 管理子系统似乎被禁用了。试试执行“apm -e 1”(FreeBSD) 并看看是否有用。
APM 管理子系统似乎被禁用了。试试执行 “apm -e 1” (FreeBSD) 并看看是否有用。
菜单项中快捷字符
快捷字符一律使用大写字母,用小括号括起来放到菜单文字的后面(如果有标点符号则放在标点符号的前面)。在 KDE 中,菜单快捷字符的前缀是“&”;在 GNOME 中,菜单快捷字符的前缀是“_”。但是如果翻译保留了原文的英文单词或阿拉伯数字,且该单词或数字正好是快捷键所在的单词或数字时,应保留原文的快捷键方式(如下面的第二、四个例子)。这里举几个例子:
KDE 菜单:
英文:C&lear 中文:清除(&L)
英文:&Glimmer Editor错误:Glimmer 编辑器(&G)中文:&Glimmer 编辑器
GNOME 菜单:
英文:_Setup... 中文:设置(_S)...
英文:Get _CDDB Now错误:现在读取 CDDB(_C)中文:现在读取 _CDDB
注意:以下情况的翻译有点特别。由于“复制”和“剪切”均为“编辑”菜单的条目,只有这样翻译才能保证显示正确!
英文:/_Edit 中文:/编辑(_E) 英文:/Edit/C_opy 中文:/编辑(E)/复制(_O) 英文:/Edit/C_ut 中文:/编辑(E)/剪切(_U)
翻译中参数的位置
有时候原来的参数顺序不符合中文的语法,一方面,翻译可以通过调整副词、语序等手法来符合中文习惯,另外一方面,在必要的情况下,需要改变参数的位置,例如在 KDE 中:
英文:%1 articles match rule %2 中文:匹配规则 %2 的文章有 %1 个
如果是在 GNOME 中则应该这样写:
英文:%d articles match rule %d 中文:匹配规则 %2$d 的文章有 %1$d 个
即用 1$、2$、3$ 等符号标明参数在原文里出现的位置。同时,任何一个参数的顺序进行了调整,则在这一句译文中所有参数都必须注明原文位置,否则无法通过格式检查。
- RFE: 直接提手册里面编程语言格式多好。话说这样插内容总觉得在贴小广告,但你们又不愿意搞讨论页我怎么办(发 20 封邮件一个个谈?)。(2e5-pos-fmt-proglang)
注意注释
文件中有时会有给翻译者的注释,多数情况下会有“TRANSLATORS”字样提示。通常是对所翻译内容的解释和提示,请在翻译过程中留意。例如:
#. TRANSLATORS: ls output needs to be aligned for ease of reading, #. so be wary of using variable width fields from the locale. #. Note %b is handled specially by ls and aligned correctly. #. Note also that specifying a width as in %5b is erroneous as strftime #. will count bytes rather than characters in multibyte locales.
当然,有一些文件内主要是地名或国家名,开发者会省略“TRANSLATORS”直接给出提示,例如:
#. CN - China. (The official ISO 3166 short English name does #. not include "The People's Republic of".)
- RFE: 错误。有没有 TRANSLATORS 头和内容是什么没有直接联系,都是 xgettext 的事情。(2e5-comment-exists-translators)
关于换行
对于很长的译文,就涉及到了换行问题。多数情况下没有限制,因为不影响最终的显示效果,只要阅读起来方便就行。下面几种格式都是正确的:
英文: Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor any other external PostScript viewer could be found. 中文: 预览失败:找不到 KDE 内建的 PostScript 查看器(KGhostView)或其它外部 的 PostScript 查看器。
英文: Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor any other external PostScript viewer could be found. 中文: 预览失败:找不到 KDE 内建的 PostScript 查看器(KGhostView)或其它外部的 PostScript 查看器。
英文: Preview failed: neither the internal KDE PostScript viewer (KGhostView) nor any other external PostScript viewer could be found. 中文: 预览失败:找不到 KDE 内建的 PostScript 查 看器(KGhostView)或其它外部 的 PostScript 查看器。
但是,如果有 c-format 等编程语言格式标记,或者原文中有强迫换行标记“\n”,那就要手工调整译文的换行,以便能最终正确地显示在程序界面上。原则是译文行宽不大于原文行宽,否则可能译文显示超出原有区域,或者译文后面部分被截去,很难看。对于含有 HTML 标记的长译文还需要在浏览器中预览显示效果(如果您了解 HTML 基本语法的话),酌情调整行宽。例如:
- RFE: 错误。PO 文件本身无论如何都不管怎么接起来的,这种完全是为了纯文本目测编辑源文件方便。另外不 wrap 的 HTML 引擎……(2e5-linebreak)
英文(c-format): Error opening file '%s':\n %s 中文(c-format): 打开文件“%s”出错:\n %s
英文(c-format): Parse a theme dir and generate a \n gkrellmrc_ksim file that KSim will understand \n better and exit. 中文(c-format): 解析一个主题目录生成 KSim 容易理解\n的 gkrellmrc_ksim 文件,然后退出。
多数 CLI 程序都需要手工设置换行,这个时候希望翻译者能够对翻译文件进行测试以确定每行到底应当放多少字符,尤其是翻译命令参数的时候,如果不对长句进行强制换行处理或者一味依照文本编辑器所显示的视觉上与英文原文长度相同,则很容易造成在程序实际运行中的格式非常难看。
关于对齐
对齐的问题通常出现在 CLI 程序的命令参数上,英文原文一般会使用空格进行对齐,但是空格并不能使得最终运行的程序在使用中文的情况下将文字正确对齐,所以应当使用制表符(Tab) 代替。制表符的对齐也不总是能在文本编辑器上所见即所得,也就是说在文本编辑器上已经对齐的行可能在实际运行时前后相差一个制表符的距离。
关于“translator-credits”字符串
“translator-credits”是放置程序运行过程中查看鸣谢信息时显示的翻译者条目,此项在 Launchpad 上为不可修改,只有在上游进行翻译时填写的条目才会在这里出现。
关于时间的译法
鉴于关于日期和时间的译法十分复杂,现在将国家标准中有关规定简要介绍一下,并给出推荐译法。
国标 GB/T 7408-94 《数据元和交换格式 信息交换 日期和时间表示法》
1994-12-06 发布,1995-08-01 实施 国家技术监督局发布
本标准等效采用国际标准 ISO 8601-1988《数据元和交换格式 信息交换 日期和时间表示法》
以下是最需要注意的几个要点:
- 在日期格式中不能出现空格,即“2003 年”这样的格式是不符合国标的。
- 表示日期时,必须按照年月日的顺序;年份一般用四位数字,而月、日必须使用带前导零的两位数字;必须使用“-”作为分隔符,或完全不使用分隔符。即“2004-01-03”或“20040103”来表示 2004年1月3日。
- 表示时间时,时、分、秒都必须使用两位数字,中间用“:”(半角括号)分隔,或完全不使用分隔符。小时计法采用 24 小时制,不区分上下午。
请注意以上 2~3 内容仅是ISO国际标准的一致交换需求(“机器说的话”),实际情况还应该按照语区具体习惯(“人话”)决定。时间的表示方法一般遵守strftime(3),基本就是date(1) 的表示方法,可以用man很快查到。glib另有一些拓展,可见于其文档中。以下列出其中的常用条目:
- %% 一个 % 字符
- %A 星期几(如“星期一”)
- %B 月份(如“八月”)
- %d 日期(00-31)
- %D 日期,格式等于 %m/%d/%y (例如:08/25/09)
- %F 日期,格式等于 %Y-%m-%d (例如:2009-08-25)
- %g ISO-8601 格式年份的最后两位(例如:09)
- %G ISO-8601 格式年份(例如:2009)
- %H 小时(00-23)
- %i 小时(00-12)
- %m 月份(01-12)
- %M 分钟(00-59)
- %n 换行
- %p 显示“上午”或者“下午”两个字
- %S 秒(00-60)
- %t 制表符
- %T 时间,等于 %H:%M:%S
- %x 日期(例如:12/31/99)
- %X 时间(例如:23:13:48)
- %y 年份的最后两位(例如:09)
- %Y 年份(例如:2009)
这里提供常用的对照:
原文 | 译文 |
---|---|
%a | %A |
%A, %B %e | %b%e日%A |
%a %b %e | %b%e日 (%a) |
%A, %B %d | %m月%d日%A |
%A, %B %e, %Y | %Y年%b%e日%A |
%a, %d %B %Y | %Y年%m月%d日 (%a) |
%A, %B %d, %Y | %Y年%m月%d日%A |
%d %B %Y | %Y年%m月%d日 |
%l:%M:%S %p | %p%l∶%M∶%S |
%R:%S | %R:%S |
相关工具的使用
以下部分为对 PO 文件进行操作时的一些指南,我们假定您已经安装了 GNU/Linux 基本系统,GNU gettext 工具集和 intltool 工具集,或在其他平台上安装了等价的软件。
gettext 工具集
gettext 工具集提供了一组使用 PO 文件进行翻译时的实用工具,现在对其中比较常用的几个做简短介绍。
若希望了解关于此工具的详细信息,请浏览 GNU `gettext' utilities
msgfmt - 检查格式并生成机读的 MO 文件
一般使用的格式为:
msgfmt --statistics -cv filename.po
这样将会对翻译格式进行检查,如果有格式问题则会显示错误原因并指明行号;如果检查通过则显示翻译的进度情况并在运行目录下生成一个名为 message.mo 的文件,该文件便是程序运行时所要读取的二进制翻译文件。
在提交任何 PO 文件前都请使用 msgfmt 命令对格式进行检查。
msgmerge - 合并文件
一般使用的格式为:
msgmerge --no-wrap -o newfile.po fileA.po fileB.po
这样进行的结果是将文件 A 和文件 B 进行合并,若有不相同的地方以文件 B 为准,最后输出在 newfile.po 中。
可以使用其更新选项来合并原来的 PO 文件和最新的 POT 文件:
msgmerge -U zh_CN.po example.pot
这样将会把原来的 zh_CN.po 另存为 zh_CN.po~ 并更新 zh_CN.po 为新的内容,zh_CN.po~ 作为备份文件可以直接删除。
intltool 工具集
intltool 工具集实际上是一组脚本,用以实现一些常规的翻译文件维护,其中部分命令除了支持 PO 文件外还支持 XML。一共五个命令,对于翻译者来说比较常用的是 intltool-update。这组工具多数需要在完整的源代码树中的 po/ 子目录下运行。要了解更多关于 intltool 工具的信息,请阅读它的 man 手册。 这里只介绍 intltool-update,用于更新 POT 文件并将 PO 文件与之合并。
intltool-update - 生成 POT 文件
intltool-update -p
这样将会在目录中生成一个 POT 文件。
intltool-update - 更新原有的 PO 文件
intltool-update zh_CN
这样将会自动生成新的 POT 文件并更新 zh_CN.po,最后得到的文件是更新后的 zh_CN.po,也可以使用 -o 选项来定义输出到指定文件而非更新原来的 PO 文件。
后记
本文基于 自由软件中文化工作指南(L10N) 修改而成,是对原文的精简和针对 Launchpad 需要进行的调整。原文是以 KDE 中国站点上刊载的 I18N/L10N工作流程 为蓝本所修订的工作指南,过程中参考了 i18n-zh 以及 GNOME Live 上的一些文章。
繁体中文翻译小组有一份基于本文档的繁体中文翻译指南,Arthur2e5 重制顺便重写过一个较常更新的 可编辑 Hybrid-PDF 版本。这两个分支中都可能有一些值得注意的新意见。
相关链接
联系方式
- Lie_Ex <lilith_ex (AT) 163 (DOT) com>
- Aron Xu <happyaron (DOT) xu (AT) gmail (DOT) com>
- ubuntu-zh 邮件列表
-- Aron Xu <happyaron (DOT) xu (AT) gmail (DOT) com> - 2009-09-04
本文在 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported 许可下发布。