闲谈软件翻译

Date:  2015/10/5   Sort:  编程开发 1810 Views / 0 Comments 
    做了一个月的软件翻译,谈谈感受。
    软件的翻译文本,可以说是用户认识软件的第一扇窗。由于大多数软件的初始语言是英语,而英语的语法、用语习惯与汉语有很大差异,所以对原文字符的翻译并不总是能展现作者的原意(事实上语言之间究竟有没有通译性,这个问题仍然有待讨论)。一般而言,翻译有“直译”和“意译”之分,前者强调语法结构的一致性,后者更注重目标语言的易读性。个人更倾向于后者。
    一开始做翻译的动机是看到一些程序的选项帮助(-h或--help显示的内容)以及交互提示信息翻译得别扭,要么直译显得生硬,要么专业性词汇没有被准确翻译。这个问题对于GUI程序或许还不那么严重,但对于CUI程序就非常麻烦了,尤其是一些系统管理工具,措辞上的一点偏差可能会导致完全不同的结果。如常见的“key”(键/密钥/声调)、“pass”(步骤/传递/通过)、“image”(图像/镜像)、“volume”(卷/体积/音量)等。还有一些专业词汇如“hash”(哈希/散列)、“copy”(拷贝/复制)、“bug”(错误/缺陷/虫子)、“rebase”(将更改重定位/变基),究竟采用音译词(较通用)还是意译词(较专业)还是不翻译,也让人纠结。
    另一种麻烦的情况是批量信息的显示。GUI程序一般会设计特定的结构(如列表框)来显示成组数据,而CUI程序往往使用printf中的格式限定符。但是如果作者忽略了语言之间的语法差异,就会导致很难翻译的情况出现。例如Pidgin中聊天室主题的显示格式为“Topic for %s set by %s at %s on %s”,po文件中没有上下文信息,所以只能根据英语中介词的用法推测每个“%s”代表什么;即便能推测出来,转换成中文又得费一番力气:如果用被动式,则不符合中文用语习惯;如果用主动式,则整个句子又显得太长(“%2$s 于 %3$s %4$s 设置了 %1$s 的主题”)。又如e2fsprogs中为错误信息设计了com_err()函数,但此函数在构造输出信息时默认将出错位置(“while doing sth.”,应译为“做某事时”)放在错误内容(“Error XXX”,应译为“出现错误”)后面,并且这两个参数被分为两个消息字符串,导致无法按照用语习惯输出中文,只能非常别扭地将前者改为“于做某事时”。
    GUI程序的翻译大多与菜单、对话框有关,但也有少数涉及到本地化问题,如默认文件名。这里想吐槽一下Windows:用过英文版Windows的应该知道,“新建文件夹”的原文是“New Folder”,其实直译为“新文件夹”或“新目录”就行了,但是当年微软中文团队在翻译时偏偏找了个这么长的名字;而且从语法角度来说,“New Folder”是偏正结构,而“新建文件夹”则是动宾短语,二者不能等价。不过既然国人已经接受了这个说法,并且还形成了一种名为“新建文件夹”的特殊文化,那还是保留为好,不然又会出现Win10中“此电脑”的闹剧(参见http://www.ithome.com/html/win10/138316.htm)。
    值得一提的是如今被很多系统采纳的桌面搜索功能,这对于拼写输入的语言(即需要通过键盘上字符的组合来得到高级字符的语言)来说有时显得鸡肋。多数Linux发行版中仅仅通过判断文件/项目名中的英文字符来搜索;Windows XP在explorer中加入了对首字汉语音序的支持,但仍然无法通过简单的按键组合来定位到指定文件。这当中固然有设计考虑不周的原因,也有文化偏见的成分:“此功能非拼音语言使用者不能用”。个人就被迫为此将常用文件夹名改成了英文,无形中便被语言的霸权所禁锢。(有关语言优越性的问题,参见http://www.zhihu.com/question/19568043http://www.zhihu.com/question/19687443)。

转载本站文章请注明,转载自:WTZ的小博[ http://wiblog.net/]
知识共享许可协议 本作品采用知识共享署名 4.0 国际许可协议进行许可。

更多