传统上，翻译与文学的关系很近。说起翻译，许多人首先想到的是“文笔要好”。近年来随着信息交流的发展，实用型文本尤其是科技文献的翻译越来越显得重要，许多科技领域的从业人员也有兴趣或有动力翻译科技文献，并取得了大量成果，突出表现之一就是IT类书籍的翻译质量有了很大的提升，这背后的功臣很多都是IT界的“翻译票友”。 科技翻译是大大繁荣了，科技翻译自身的学问却没有相应的进展，各种翻译教程和经验总结仍然侧重于一般的翻译或文学翻译。然而深入了解翻译的人都知道，不同文体、不同领域的翻译，是各有特点的。比如新闻翻译追求简洁、准确、吸引眼球，文学翻译更强调完整、流畅、意境贴切。这种差异贯彻到翻译实践当中，产生了很多讲究，所以新闻才能译得像新闻，小说才能译得像小说。同样的道理，科技翻译也不能完全照搬普通翻译的做法，要想做好它，还必须了解其自身的特点。根据我的总结，科技翻译大致有以下几个特点。 第一，科技文献通常是用来讲道理的，所以译者必须准确理解文字表达的道理。 这里说的“讲道理”不是狭义的“说理”，而包括讲解原理、研究论证、实验分析等等，换句话说，科技文献的内容是可以用理性分析的客观现实，所以读者的理解也应该可以客观衡量。文艺作品没有这个特点，经常是“言有尽而意无穷”，可以“一千个读者就有一千个汉姆雷特”，科技文章则要求“有九分把握不说十分话”，必须“一千个读者只能有一个汉姆雷特”。所以，科技文献的译者不但要懂得原文，还必须准确理解原文。以前有几家出版公司的IT类翻译图书之所以被大家痛骂，很大程度上并不是因为译者的文字水平不够好，而是因为译者根本不懂也不愿意弄懂作者在说什么，这样的译文会被读者痛骂。 科学技术本身有客观标准可循，所以科技文献的意思理解起来反而比文学作品更容易，因为译者不必拘泥于原文。假设原文先讲了甲乙两个算法，然后下了比较的结论，译者如果不能确认作者的褒贬，完全可以根据之前的讲解进行逻辑推理，甚至可以亲自动手编程实践。要知道，逻辑和程序是绝不会因人而异的。推而广之，译者完全可以独立验证自己的理解是否准确，而理解准确恰恰是译文合格的前提条件。所以我建议，科技文献的译者在翻译完成之后，应当抛开原文阅读译文，想想是否能明白作者要讲解的知识、原理、规律，如果做不到，那么译文多半不合格。 第二，科技翻译的译者完全可以适当改动原文。 上文已经说过，科技文献的一大特点是其论述内容有客观标准可循，所以译者可以借助“文字之外”的信息来验证自己的理解。这可以算科技翻译的独门优势，而且这点优势相当有价值。因为科技文献的作者往往不是专门的文字工作者，不能奢求他们有很高的写作水平，某些片段可能讲解晦涩，难以理解，或者原作者并没有为译文读者考虑（实际上这种情况相当普遍），使用了一些专属于某些文化的典故、俚语。如果是文学翻译，遇到这样的问题会非常麻烦，摸不准原作者到底是什么意思。科技翻译则没有这种问题，译者一旦确认自己理解了原文的内容和逻辑，就可以大胆改动译文读者难以理解的片段，避免译文读者在同样的问题上浪费精力。 我曾在技术文章中见到作者评价某种做法的难度“和拯救麻风病人一样”。根据上下文猜测，这里大概是说难度不小，不过非要理解为难度很小似乎也说得通，因为现在麻风病似乎很少见了，也很少听说治疗很麻烦，所以我不敢确认。译者尚且如此，见不到原文的读者估计就更难以确认了。于是我专门去查了资料，原来这里作者指的是在斯里兰卡的非政府组织、慈善机构、公共关系公司、卫生部门为拯救麻风病人的进行了长期的艰苦努力，那么意思当然是难度大了。所以最终翻译为“和拯救麻风病人一样非常艰难”，这样就确保读者不会误解。 再举一个例子，有篇译文讲的是如何用正则表达式匹配独立的单词，原文是“so, if inline appeared in the sentence, the regular expression will match not in but inline”，翻译为“这样处理，如果句子中出现了inline，表达式匹配的是inline，而不是in”却不够恰当。英文本身就是以词为单位的，所以阅读原文时当然知道其中的inline、in都是指的“单词”inline、in，而不是“字符串”inline、in。但中文的词汇之间并没有形式分隔，所以读者有可能把“这句话包含inline”理解为“这句话包含字符串inline”。如果译者大胆将“单词”两个字增补进去，译为“这样处理，如果句子中出现了单词inline，表达式会匹配单词inline，而不会匹配其中的in”，这样读者就不会有误解了。 以上两处改动都出自译者之手，目的都是为了保证读者的正确理解，保证“一千个读者只有一个汉姆雷特”，且译者这么做有足够的底气这么做。当然，如果译者觉得应当尽量避免改动原文，也可以保留原文，辅以注释说明，这个道理相当简单——发布有缺陷需要用户自己打补丁的软件，与发布官方已经打好补丁的软件，显然大家都喜欢后者。 第三，在“顺”与“信”发生冲突时，科技翻译选择信而不顺。 “顺”和“信”的取舍，是老一辈翻译家非常关注的问题。所谓顺，指的是文字通顺、流畅，所谓信，指的是准确、忠于原文的形式。因为语言习惯不同，所处的文化不同等原因，翻译时难以“形神兼备”的情况是时常出现的。要译文流畅，可能就要对原文做较大改动；要尽量不改动原文，文章又无法流畅。对这个问题，不同的文体有不同的处理。 在“信”与“顺”之间，文学翻译更偏向“顺”，如the night breeze came with pleasant guitar，原意是“晚风和好听的吉他是一起来的”，但这样表达很别扭，故改为“晚风送来美妙的吉他”，这是取“顺”而弃“信”。但如果科技文章中出现the data come with noise，翻译为“数据送来了噪音”就是严重的错误，只能译为“数据是和噪音一起来的”，这是取“信”而弃“顺”。尽管看起来比较直白简陋，但很多技术文献本身就是直白简陋的，翻译时一味追求译文的“顺”，不但丧失了科技文章看重的准确信，即便从翻译本身来说，也有涂脂抹粉、文过饰非的嫌疑。 要补充的是，“信”和“顺”舍弃一定要在“信和顺无法调和”的前提下进行，“信而不顺”绝不是不动脑筋硬译的借口。即便是坚持信而不顺的鲁迅先生也说过：信而不顺，绝不是舍弃“跪下”而保留“跪在膝上”，舍弃“银河”而保留“牛奶路”。实际上，大量科技文章都是非常浅显直白的，译文对译文读者的要求不应当高过原文对原文读者的要求，尤其是不应当抬高对读者文字理解能力的要求。 第四，科技翻译时，译者应当对加倍小心应对专有名词（术语）。 专有名词是科技文章中大量用到的词汇，专用来指涉一些约定俗称的概念。因为科技行业的发展水平不同，现代科技专有名词的大部分都来自西方国家，所以必须翻译出来。物理、生物等领域的专有名词许多都是组合而成，翻译相对容易，如magnetic field翻译为“磁场”，haemoglobin翻译为“血红蛋白”（希腊文的haima“血”和拉丁文的globin“球”）。 不幸的是，IT行业的情况特殊，这个行业许多人心态很年轻，思维很开放，很多术语是从生活中借鉴而来，翻译起来反而麻烦。比如buffer和cache两个词，本来buffer指的是“逃生气垫”，cache指的是“隐匿的存放处”，引申出计算机里的“缓冲”和“缓存”是非常形象自然的。中文的“缓存”和“缓冲”属于针对具体领域专门创造的术语，虽然已经约定俗成，毕竟割断了原来的形象感，所以很多初学者见到“缓存”和“缓冲”以为是全新发明的东西，甚至会混淆这两个名字相近的概念，也需要花很多时间去记忆“缓存是透明的”，却不知道cache本来就有“隐匿存放”的意思。 可见，术语的翻译一定要加倍小心。这方面好坏例子都很明显。好的例子如表示空气污染级别的beyond index翻译为“爆表”，即便不认识beyond index的人，一看“爆表”也知道意思。坏的典型比如case-sensitive翻译为“大小写敏感”——据我观察，几乎没有初学者能想明白“大小写敏感”的什么意思，了解之后不少人还以为IT行业的术语就是这个怪调调。其实，真正的原因是这个译名造错了。查阅词典可知，sensitive除去表示“感觉上的敏锐”，还有一个意思是“有能力区别和分辨”，所以case-sensitive的真正意思应当是“能区分大小写”（“敏感”和“有能力识别”有一定联系，但区别很大：“不识好歹”不等于“好歹不敏感”，“是非分明”也不能说成“是非敏感”）。译者不够谨慎造错一个术语，会影响到无数后来者的学习。所以这样说来，我觉得cookie不翻译反而是好事，有人非要翻译为“小甜饼”反而画蛇添足，因为中文世界里大多数人都不知道“小甜饼”是什么，有什么作用，也不知道HTTP Cookie其实来自magic cookie，所以直接说cookie反而更好。 即便一些专有名词已经有了译名，译者也应当记得，这些译名一般只适用于狭窄的领域内，不是放之四海而皆准的译法。比如plug and play，大家都知道这是“即插即用”，如果在讲解程序的文章里出现，比如Having these code snippets, are you ready to plug and play? ，翻译为“即插即用”就不合适了，因为这里作者是调侃性地借鉴硬件的“即插即用”，谈的并不是硬件标准，而是“把代码直接拿过来用”的做法。所以不妨翻译为“即抄即用”，这样保留了愿意，读音也接近“即插即用”，便于读者理解，甚至原文的一点点幽默感也保留下来。如果译者想不到“即抄即用”，至少也应当在“即插即用”外面打个引号。 类似的例子还有正则表达式中的character class，许多译者一看到class，就立刻想到“类”，所以character class就翻译为“字符类”。但是“类”这个词在IT知识体系里有专门的意思，它表示某种类型的对象定义变量和方法的原型，是对现实中一类有共同特征的事物的抽象。character class翻译为“字符类”，就会让读者联想到“对象”等等一系列概念，在有的语言中甚至真的有类名叫Character，这就更容易混淆了。其实character class里的class只表示“组合/集合”，类似表示“班级”的class，所以应当翻译为“字符组”更合适。