传统上，翻译与文学的关系很近。说起翻译，许多人首先想到的是“文笔要好”。近年来随着信息交流的发展，实用型文本尤其是科技文献的翻译越来越显得重要，许多科技领域的从业人员也有兴趣或有动力翻译科技文献，并取得了大量成果，突出表现之一就是IT类书籍的翻译质量有了很大的提升，这背后的功臣很多都是IT界的“翻译票友”。
科技翻译是大大繁荣了，科技翻译自身的学问却没有相应的进展，各种翻译教程和经验总结仍然侧重于一般的翻译或文学翻译。然而深入了解翻译的人都知道，不同文体、不同领域的翻译是各有特点的。可惜，关于翻译还有不少遗留的执念，比如言必称“信、雅、达”，虽然这个标准早已证明不切实际。
为什么？因为翻译必须量体裁衣，脱不开与原文的关系。“信、雅、达”绝不是适合一切文章的标准，所以翻译时也应当贴合原文。
比如新闻翻译追求简洁、准确、吸引眼球，文学翻译更强调完整、流畅、意境贴切。这种差异贯彻到翻译实践当中，产生了很多讲究，所以新闻才能译得像新闻，小说才能译得像小说。同样的道理，科技翻译也不能完全照搬普通翻译的做法，要想做好它，还必须了解其自身的特点。根据我的总结，科技翻译大致有以下几个特点。
第一，科技文献通常是用来讲道理的，所以译者必须准确理解文字表达的道理。
这里说的“讲道理”不是狭义的“说理”，而包括讲解原理、研究论证、实验分析等等，换句话说，科技文献的内容是可以用理性分析的客观现实，所以读者的理解也应该可以客观衡量。文艺作品没有这个特点，经常是“言有尽而意无穷”，可以“一千个读者就有一千个汉姆雷特”，科技文章则要求“有九分把握不说十分话”，必须“一千个读者只能有一个汉姆雷特”。
因此，科技文献的译者不但要懂得原文，还必须准确理解原文。以前有几家出版公司的IT类翻译图书之所以被大家痛骂，很大程度上并不是因为译者的文字水平不够好，而是因为译者根本不懂也不愿意弄懂作者在说什么，这样的译文会被读者痛骂。
科学技术本身有客观标准可循，所以科技文献的意思理解起来反而比文学作品更容易，因为译者不必拘泥于原文。假设原文先讲了甲乙两个算法，然后下了比较的结论，但只是说
一个算法比另一个好几倍
单纯从文字来看，很难知道到底是哪个好，哪个不好，但这个问题难不住科技翻译的译者，因为他可以亲自动手编程实践。要知道，逻辑和程序是绝不会因人而异的。如果确认原文意思之后，按下面这样表达，读者理解起来就容易多了
A算法比B算法好几倍
推而广之，译者完全可以独立验证自己的理解是否准确，而理解准确恰恰是译文合格的前提条件。
类似的例子还有：
乔布斯是很有能力的工程师，和沃兹尼亚克不可相提并论
“不可相提并论”当然是说两者大不相同，但这里到底要表达的是什么意思呢，谁的水平更高？在我看来，如果一定要读者熟悉苹果早期的创业故事，才能读懂这个句子，那么译者是不合格的。译者完全可以也应当根据自己对背景知识的了解，澄清这一点，改译为
乔布斯也是很有能力的工程师，但远比沃兹尼亚克逊色
多说一点，这个例子我只是看了译文觉得有点别扭，翻了原文才知道“不可相提并论”的原文是not in the same league，本身就有“远远不如”的意思。严格说起来，译文在这里是有瑕疵的，起码原文的转折意思没有翻译出来，哪怕原文多加一个“但”，理解起来也容易些。
因此我建议，科技文献的译者在翻译完成之后，应当抛开原文来读读，想想是否能明白作者要讲解的知识、原理、规律。如果做不到，那么译文多半不合格。
第二，科技翻译的译者完全可以适当改动原文。
上文已经说过，科技文献的一大特点是其论述内容有客观标准可循，所以译者可以借助“文字之外”的信息来验证自己的理解。这可以算科技翻译的独门优势，而且这点优势相当有价值。因为科技文献的作者往往不是专门的文字工作者，不能奢求他们有很高的写作水平，某些片段可能讲解晦涩，难以理解，或者原作者并没有为译文读者考虑（实际上这种情况相当普遍），使用了一些专属于某些文化的典故、俚语。
如果是文学翻译，遇到这样的问题会非常麻烦，摸不准原作者到底是什么意思。科技翻译则没有这种问题，译者一旦确认自己理解了原文的内容和逻辑，就可以大胆改动译文读者难以理解的片段，避免译文读者在同样的问题上浪费精力。
我曾在技术文章中见到作者评价
某种做法的难度和拯救麻风病人一样
根据上下文猜测，这里大概是说难度不小，不过非要理解为难度很小似乎也说得通，因为现在麻风病似乎很少见了，也很少听说治疗很麻烦，所以我不敢确认。译者尚且如此，见不到原文的读者估计就更难以确认了。
于是我专门去查了资料，原来这里作者指的是在斯里兰卡的非政府组织、慈善机构、公共关系公司、卫生部门为拯救麻风病人的进行了长期的艰苦努力，那么意思当然是难度大了。所以最终翻译为
和拯救麻风病人一样非常艰难
再举一个例子，有篇译文讲的是如何用正则表达式匹配独立的单词，原文有
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，翻译为“数据送来了噪音”就是严重的错误，只能译为“数据是和噪音混在一起来的”，这是取“信”而弃“顺”。
尽管看起来比较直白简陋，但很多技术文献本身就是直白简陋的，翻译时一味追求译文的“顺”，不但丧失了科技文章看重的准确信，即便从翻译本身来说，也有涂脂抹粉、文过饰非的嫌疑。
要补充的是，“信”和“顺”舍弃一定要在 “信和顺无法调和” 的前提下进行——“信而不顺”绝不是不动脑筋硬译的借口。即便是坚持“信而不顺”的鲁迅先生也说过：信而不顺，绝不是舍弃 “跪下” 而保留 “用膝盖站立” ，不是舍弃 “银河” 而保留 “牛奶路” 。同样我们也可以说，“信而不顺”不是舍弃 “创刊” 而保留 “发行了第一期” ，也不是舍弃 “火箭筒” 而保留 “火箭推进榴弹发射器” 。
实际上，大量科技文章都是非常浅显直白的，译文对译文读者的要求不应当高过原文对原文读者的要求，尤其是不应当人为抬高对读者文字理解能力的要求。
第四，科技翻译时，译者应当对译文专业领域有所了解。
这方面最明显的例子就是关于武器的。众所周知，英文里的“枪”和“炮”都可以用gun，比如机枪是machine gun，加农炮是cannon gun。简单说，在英文里gun有许多种，“枪”和“炮”都是之一。然而在中文里，“枪”和“炮”的定义是截然分明的：口径在20mm以下的是“枪”，口径在20mm以上的叫“炮”。所以正常来说，你看到的应该是 7.62mm步枪，12.7mm机枪，20mm机关炮，75mm榴弹炮等等。
大概是不少译者不具备这种背景知识，所以翻译时经常搞错。英美国家一般使用英制单位而不是公制单位，所以口径描述一般用 .30 或者 .50 。其中 .30 对应“0.30英寸”也就是7.62mm， .50 对应“0.50英寸”也就是12.7mm。但是查阅相关译文，经常出现“30mm步枪”和“50毫米机枪”的说法。
如果不熟悉.30或者.50的单位，把英寸和毫米搞混尚且情有可原，但“30mm步枪”和“50mm机枪”的说法就充分显示了译者对专业领域缺乏认知。即便不知道超过20mm口径应当叫“炮”，按常识推断，枪弹一般是食指粗细，30mm口径有两三指粗，成年人单手通常只能握住一发，步枪能不能发射这种弹药？弹匣需要多大？普通士兵能携带多少发这样的弹药？依靠常识不难发现其中的问题。
不要以为军事领域的单词很偏门，一般不会遇到。实际上如果你留意身边的译文乃至报道，就会发现这样的错误比比皆是。
在前几天的新西兰枪手事件爆发后，许多报道都提到“枪手腿上绑了很多杂志”。枪手要去行凶，杂志不能防弹，只能让行动更笨拙，为何会这样？原来是译者缺乏军事知识，只知道magazine是“杂志”，却不知道它也表示“弹匣”。
第五，科技翻译也需要了解基本文化知识。
我们经常说，好的专业文章也可以写得“深入浅出”。要做到这一点，免不了借用一些日常生活中的经验和例子。但是，不同文化的生活经验可能是相差迥异的，如果译者缺乏基本的了解，就很可能犯错。
比如一篇以网络通讯为主题的文章，借用了无线电通讯的场景来讲解。在美国，也许私人电台、无线电步话机很普遍，所以这种讲解是很生动的。但是中国的情况与此不同，读者和译者可能并没有太多的切身经验，这时候就要加倍小心。遗憾的是，译文里就出现了
罗杰，准备发送下一批数据
好玩的是，之前和之后都没有出现过“罗杰”这个人名。这个其实不用看原文就知道，“罗杰”的英文是roger，因为在句子开头，所以首字母大写，被译者误以为是人名。但是，如果留意过无线电通话就会知道，roger并不是人名，它的意思就是“收到”，是无线电通话中很常用的说法，所以正确的译文应当是
收到，准备发送下一批数据
再比如，一篇协商系统的文章里有这么个场景：主持节点询问所有参与节点，是否有反对意见。如果没有反对意见，那么主持节点就会说：
通过…通过…完成了
读者看到这里明显会觉得奇怪，既然通过是确定的，为何要一再说“通过”，最后明明没开始，为何说“完成了”？查阅原文，主持节点的信息是going…going…gone，这其实是借用了拍卖官在一锤定音之前喊的“第一次……第二次……第三次，成交！”，所以对应的译文应当是
第一次…第二次…定了！
另外一个常见的翻译错误是人名。英文里经常有一些人名是代引号的，译者大概不知道这是什么意思，就直接照原样翻译过来了。类似下面这样：
the commander is Virgil Ivan "Gus" Grissom
指令长是维吉尔·伊万·“格斯”·格里索姆
the captain is Bernard “Bud” Kauderer
艇长是伯纳德·“巴德”·科德罗
这都是不妥的，读者会看得莫名其妙。因为正常人的名字不会打引号，父母给小孩取名时也不会弄一个带引号的名字。
那么这里的引号是什么意思呢？其实它就是“昵称”、“诨名”、“爱称”，通常是非正式但流行的称呼，就等于我们熟悉的“大刘”、“老张”、“建平”之类。Virgil Ivan "Gus" Grissom是美国首批七位宇航员之一，如果你留意过相关的纪录片或者电影，会发现大家都叫他Gus，虽然他正式的名字是Virgil Ivan Grissom。
the commander is Virgil Ivan "Gus" Grissom
指令长是“格斯”——维吉尔·伊万·格里索姆
the captain is Bernard “Bud” Kauderer
艇长是伯纳德·科德罗，大家都叫他“巴德”
另一个常见的例子是Colonel，虽然首字母大写，但它不是人名而是军衔，也就是“上校“。可是据网友考证，新华社的报道在前后十六年间，都把它翻译为“科洛内尔”，所以世界各国都有“科洛内尔”占据重要位置：
菲律宾军方发言人科洛内尔·布埃纳文图拉·帕斯夸尔说…（2005年报道）
军方发言人科洛内尔·乔纳森·旁斯说…（2009年报道）
科洛内尔·艾哈迈德·阿卜杜勒拉扎克主管也门哈德拉毛省军事情报（2013年报道）
均来自新华社报道
译者如果平时没有留意过这些文化细节，单纯比照原文的文字，就容易犯下这类错误。不过它们也不难避免，如果译者足够留心，会发现“罗杰”也好，“通过…通过…完成了”也好，单纯从文章来说也不通，和描述的场景冲突。如果能发现这点，对着原文多查资料，也可以避免这类问题。
第六，科技翻译时，译者应当对加倍小心应对专有名词（术语）。
专有名词是科技文章中大量用到的词汇，专用来指涉一些约定俗称的概念。因为科技行业的发展水平不同，现代科技专有名词的大部分都来自西方国家，所以必须翻译出来。物理、生物等领域的专有名词许多都是组合而成，翻译相对容易，如magnetic field翻译为“磁场”，haemoglobin翻译为“血红蛋白”（希腊文的haima“血”和拉丁文的globin“球”）。
不幸的是，IT行业的情况特殊，这个行业许多人心态很年轻，思维很开放，很多术语是从生活中借鉴而来，翻译起来反而麻烦。比如buffer和cache两个词，本来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翻译为 “字符类” ，就会让读者联想到“对象”等等一系列概念，在Java语言中甚至真的有类名叫Character，这就更容易混淆了。其实character class里的class只表示“组合/集合”，类似表示“班级”的class，所以应当翻译为 “字符组” 更合适。
总的来说，我认为科技翻译的特点就是如此。它不会要求译者有极高的文学造诣，但并不意味着放低了对译者的要求。无论是从逻辑的严密、歧义的避免上，还是背景知识的理解和术语的准确性上，科技翻译都有更高的要求，而且许多时候有成文、成型的习俗和规范，不像文学翻译有那么多自由发挥的空间。
不过我相信，这些要求对负责任的译者来说不是问题——须知道，科技行业工作，本身也离不开严谨、细致的工作习惯。