技术翻译答客问之一

来源:互联网 发布:实施国家大数据战略 编辑:程序博客网 时间:2024/04/19 22:23
在JavaEye上看到Yulimin列出了许多与Hibernate/EJB/JPA相关的术语表,我估计他是在为翻译Java Persistence with Hibernate一书准备。负责态度令人敬佩,非常高兴我们找到了这么好的译者。

我即兴回复了如下文字。之后感觉可能对所有技术翻译还有些用,就贴在这里了。

从事计算机图书翻译审读方面的工作已经差不多10年了,文字的积累却很少,惭愧。


-----------------------------------------------------
术语的确定非常重要,也是目前我们工作的难点,因为太多词没有标准。但有几个原则和惯例,请参考。具体问题,我们再p2p地详细沟通。

1.原则上能翻译的都要翻译,缩写词(CSS,XML,JSP,EJB等)、约定俗成已经广泛以英文为主的(applet比较典型)、没有通译的专有名词、代码元素(各种包名/类名/方法名/字段名/属性名)除外。Java环境中不译的主要有:Bean,servlet,applet等。

2.术语的确定,统一比具体环境下的贴切表达更重要。只要是一个含义,通篇最好用一个对应译名,这样更方便读者。同一个CSS,不要一会儿CSS,一会儿层叠样式表,一会儿级联样式表。

3.有国家标准的(主要是国家科技名词术语委员会发布的词汇表,但是数量有限,此外还有各种具体的国家标准,都有相关领域的词汇表)遵守标准。只有极少数例外,比如国标将Email定为电子函件,因为罕见,我们没有采用(但邮电社版权页上还是遵守的,可见社里严谨,也许有些过了,呵呵)。

4.没有国家标准的,以约定俗成为主。比较传统的词汇可以参考清华大学章鸿猷先生编的词典,章先生我合作过,比较严谨,而且研究术语多年。但他本身是银行搞大型机的,加之离开一线时间较长,关注面比较广,比较新的词汇就不太可靠了。较新的词汇,可以在几种常见备选中选择,原则是从已有标准或者已有约定俗成译法的相关词汇出发,这样能够形成自洽的体系,方便读者。最后的选择方式,就是比较Google搜索结果数量了。多者为王。

5.对于尚无通行译法的术语,第一次出现时,都加注英文。这样就比较稳妥了。

下面是对上面列表中一些术语的意见,供你参考。
O/R Mapping 对象/关系映射

hash 应该译为散列,这是国家标准,请遵循。老译法“哈希”是误以为人名了。

session译为会话应该没有什么问题。除非是代码之一部分。

lazy-initialized      延迟加载?initialize似乎永远都应该译为初始化。

listener      监听-->监听器

production      如果后跟代码,应该译为产品代码。

export      发布-->导出,更为通行,而且看中文就能想到英文。发布一般对应release, publish等等。

application context译为应用程序上下文或者应用上下文。context都译为上下文,已经通行。

convention-over-configuration       惯例优先?单看中文恐怕想不到英文原文的。建议更忠实一些。

mandatory      必须的-->必需的,前者是副词。

数据库中的join有国家标准的,好像是联结,但有些记不清了,请与编辑核实。

class hierarchy 类分层结构-->类层次,或者类层次结构,与inheritance hierarchy译法统一。

fetch 用抓取还是获取,统一即可。

数据库中的schema有国家标准,模式。虽然与pattern重合,但是在数据库图书中一般不会冲突。可以遵循。

method应该译为方法。译为成员函数概念不错,但是在Java中好像不存在函数这样的字眼。参见我们出版的Gosling Java程序设计语言。constructor译为构造器。本来我喜欢庸构造方法,可是Gosling的书中解释constructor时明确说it is not a method。只好如此了。

entity译为实体,没有问题。bean可以不译。

OO和数据库中field都可以译为字段,没有问题,在图形界面中text field的field可以译为文本域。column译为列,与字段同义。

请注意侯捷先生的术语习惯与大陆通行的基本不同,他创造的不少译法虽然优于我们,但是读者不接受,毫无办法。印象中,只有泛型一词通行。
原创粉丝点击