翻译的程序与基本翻译过程

翻译的程序

在理想的情况下（不过理想的情况很少），翻译程序包括背景资料的准备和实际翻译过程。不过，首先需要明确是个人翻译还是小组翻译。

理想情况是指有充裕的时间和足够的资料来源（图书和参考资料）来研读需要翻译的文本并把所有的问题记录下来。这样，在实际 *** 作翻译之前，这些属于理解或转换方面的问题就可以得到解决。如果同一文本已有其它译本，也应该仔细加以研究，以确定对各种问题的处理办法。在有些情况下，译前对原文和潜在问题的研究实际上要花费比翻译过程本身更多的时间，特别是当译者需要大量阅读同一作者的其它著作以及同一时期其他作者就同一主题撰写的著作和文章时，情况就更是如此。

实际翻译程序可以归纳如下：

1.快速翻译，侧重文体。有些译者认为口述的译文更新颖、更流畅。但无论译者是口述、打字、还是手写，重要的是要使译文节奏流畅；

2.初稿应该搁置一旁约一周左右。这样，修订译稿时就可以获得全新的感受，排除翻译初稿时留在耳边的余音，更加客观地评估译文；

3.认真检查译文内容，特别着重译文的准确性和连贯性。删除不必要的增补词语和补充初稿中的疏漏。特别要注意关键概念在翻译上的一致性，理顺拗口的词句；

4.修改后的译稿要再搁置几天；

5.从文体上检查译文。其实，这一步骤应该反复进行多次。朗读译文是一个非常重要的办法，因为听觉对连贯性和节奏感方面的问题比视觉要敏锐得多；

6.检查译文拼写、标点符号和格式。有些译者错误地认为，对译文内容、文体和正字法这三方面的检查可以合并起来一次完成，这种看法是大错特错的。对译文上述三个方面的检查应该分别进行；

7.译文送交我或出版商审阅。有时，在译文送审之前还须经过译文未来读者代表对译文进行检验；

8.采纳我或出版商提出的建议，尽管有些建议需要进一步考查和讨论。译者不应该被不了解文本全貌的片面意见所左右，要坚持自己对文本完整性的理解，特别是译文需要署名时更是如此。

不过，在绝大多数情况下，负责任的出版社的我会提出十分中肯的意见，对这些意见应该加以认真考虑。

上述翻译程序的八个步骤，说的是一系列符合理想的情形，但在绝大多数情况下，翻译时间很紧，需要尽快脱稿。驾轻就熟的译者往往可以把几个步骤合并在一起，但首先应该拿出一个在文体上符合要求的译稿，然后才能就准确性、连贯性和正字法对译稿进行审校。这是一条进行有效翻译的基本原则。一篇逐词直译过来的蹩脚译文，几乎无法进行重组来达到文体上的要求，但文体上合意的译文就可以很容易地‘规整起来’，使之更为准确。

小组翻译一般来说是一个完全不同的过程，它所涉及的程序也十分不同，这就要看小组成员是在编译部里合作进行翻译，还是他们各自先译出初稿，然后定期开会，讨论出一个‘一致审定’的译稿。

编译部往往拥有大量的词典和百科全书、完备的词库和若干名通晓同一译语并熟谙翻译内容所涉及的专门知识的人才。另外，大多数编译部为每个翻译小组都安排有一名经验丰富的组长行或携，遇有特殊问题，可以直接请教。在这种情况下，通常由一位译者负责初稿，后由另一位或几位译者进行校订。

许多个体职业译者几乎拥有编译部的全部有利条件，他们可以接触各种专业词典和百科全书，使用出版商或翻译中心提供的词库，请教承担翻译任务的出版商或编译部约请的翻译顾问。

然而，当翻译小组接受一部重要作品的翻译任务时，小组成员的工作程序大致如下：（1）每个成员负责翻译不同的部分；（2）阅读其他成员的译稿并提出意见； （3）小团握组成员定期开会，讨论不同看法，统一意见。这些程序常常大不相同，十分复杂。首先，很难组织一个成员之间在能力上旗鼓相当的翻译小组，人人尊重组内同行的经验和资历。在许多情况下，能力较差的成员总是想要在讨论中占上风，以掩饰自己业务能力上的弱点。其次，小组必须规定几条相对详细档伏的翻译原则。这样，意见上的分歧就可以根据这些原则来加以讨论，而不至于成为对同行的个人批评。第三，当小组里意见产生严重分歧时，需要推举一位成员充*外‘仲裁人 ’。否则，成员之间在个性方面的冲突就会严重影响工作进展；第四，聘请几位有水平的审稿人员，专门就内容是否正确和文体是否可行等两方面的问题通审全稿，这样做也是大有好处的。

基本翻译过程

四个基本翻译过程是：（1）分析原文；（2）将原语转换成译语；（3）重新调整译文；（4）约请有代表性的读者检验译文。

分析原文就是细致处理词位的所指意义和联想意义、研究句法和语篇结构。正如本书在不同章节已经指出的那样，理解和领会原文是从事无论何种翻译的基本功力。翻译中大多数的失误都是因为没有过好这一关。如果译者确实理解了原文的涵义，又能得心应手地驾驭译语，那么翻译就是一个很自然的驾轻就熟的过程。本书不惜笔墨地讲解语言的性质以及词法特征、句法特征和语篇特征，就是因为许多译者并没有意识到要在原文中发掘它的内涵。

翻译过程涉及从用原语思维到用译语思维的转换——这正是翻译中最关键的一步，这时原文的内容也就‘一步到位’。转换的明晰程度越高越好。在奈达和泰伯的著作中（Nida 和Taber，1969），根据所谓‘核心’结构对此做了详尽的阐述。

结构重组就是组织译文中的词汇特征、句法特征和语篇特征，从而使所针对的读者能够限度地理解和领会译文。对于一位优秀的译者来说，整个过程几乎是自动进行的，实际上就象我们使用母语讲话一样。

虽然这三个基本过程可以分开来讨论，但如果认为译者是分三个步骤来进行 *** 作的话，那就完全错了。这三个过程是下意识地同步进行的。水平高的译者用不着去考虑怎样把主动变为被动，把名词化的动词变为从句，或者在提到某一个人的时候，也用不着去考虑是否需要把名词变成人称代词。译者如果还常常犯愁如何重组译文的话，那他们大概是在还没有具备运用译语的必要能力之前就开始从事翻译了。

尽管检验译文与分析、转换和重组这三个过程有所不同，但就迅速暴露译文中存在的问题而言，这是一个十分重要的环节。过去，译文的检验大都是指定一名懂得原语和译语的人来进行原文和译文的比较，测定译文与原文的对应程度。这个方法的缺点是，这位懂得双语的鉴定人可能已经熟悉文本和内容的类型，用不着花多大功夫就能理解译文。对译文进行正确的评估，只能是通过检测只懂译语的读者代表的反应来实现。

最有效的检测方法有以下四种：（1）邀请几位读者代表朗读译文；（2）仔细分析朗读者的面部表情；（3）请听过译文朗读的人向没有听过朗读的人讲述内容；（4）填空检测法。

最有效的检测方式之一是请几位水平高的人来朗读译文，译者一边看着稿子，一边标记朗读时打磕巴、误读、用错词替换、重复以及语调把握不定的地方。如果两个或几个水平相当的人都卡在同一地方，这些地方明显就有问题。造成朗读不畅的问题有以下几种：如高层次的词汇，句法蹩脚，缺乏过渡词，并列的词汇中辅音群发音浊重，没有表示疑问、命令、讽刺、反语和省略的标记词。这种检测方法并不能告诉译音应该怎么去修改译文，但能够指出译文中需要修改的地方。

当不同的人朗读译文时，译者要仔细观察他们的面部表情，特别是他们的眼神，这样做是很有好处的，因为表情和眼神可以反映出他们对译文内容和形式的理解和领会的程度。细心而又善解人意的观察者很快就能发现：朗读者读懂了译文呢还是对它的内容不知所云；对译文的内容感兴趣呢还是觉得枯燥无味；读来饶有兴致呢还是认为译文的确太难而无法诵读。

对译文内容的检验，是请一个人朗读或默读译文，然后让他向其他人讲述内容。令人吃惊的是，许多人读完了却不知所云，但如果有两个或几个人在理解上犯了相同的错误，那么译文显然就需要修改。当然，如果原文本身有意要含混模糊，则可另当别论。

填空检测法也是测定译文可读性程度的有效方法。这个方法是每四个词后面空一处，再请人根据上下文要求填入恰当的词。在至少五十个空里能够填对多少词语有效地显示了转换概率的范围，从而也就测定了译文的可读性和可理解的程度。这个方法也可以变通一下，即每九个词后面空一处，再请人朗读译文，然后计算朗读者填错的地方，并提出修改意见。

与以上这些邀请读者代表参与译文检测的方法相比较，听取有经验的翻译或我的内行意见或许要更好些。他们知道语际交流的基本原则，懂得使用文字的艺术，A.莱斯利·威尔逊就是这样。他担任《恢弘》（Dimension）杂志我多年，为从事近年间德国文学佳作翻译的译者提供了重要帮助。认真读上几期就能获得关于在译语中再现原语内容与形式的精辟论述。

(一) Visual Basic

它是以Basic语言作为其基本语言的一种可视化编程工具。在中国乃至全世界都曾看到过它的身影，它曾是在中国最为流行的编程工具，到现在还占据着非常重要的地位，对于它的好坏大家都有一定的了解，这里我们也说说：VB作为一种较早出现的开发程序以其容易学习，开发效率较高，具有完善的帮助系统等优点曾影响了好几代编程人员，但是由于VB不具备跨平台这个特性，从而也决定了VB在未来的软件开发中将会逐渐地退出其历史舞台；它对组件技术的支持是基于COM和ActiveX,对于组件技术不断完善发展的今天，它也显出了它的落后性；同时VB在进行系统底层开发的时候也是相对复杂的，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；而且面向对象的特性差；网络功能和数据库功能也没有非常特出的表现，综上所述，VB作为一种可视化的开发工具由于其本身的局限性，导致了它在未来软件开发中逐步被其他工具所代替。

建议：对于袜纳首编程入门人员，可以先借助VB这个可视化环境大致了解可视化编程的特点，并且可开发与系统无关的综合应用程序。

(二) PowerBuilder

是开发MIS系统和各类数据库跨平台的首选，使用简单，容易学习，容易掌握，在代码执行效率上也有相当出色的表现。PB是一种真正的4GL语言（第四代语言），可随意直接嵌套SQL语句返回值被赋值到语句的变量中，支持语句级游标，存储过程和数据库函数，是一种类似SQLJ的规范，数据访问中具有无可比拟的灵活性。但是它在系统底层开发中犯了跟VB一样的错误，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；在网络开发中提供了较多动态生成Web页面的用户对象和服务以及系统对象，非常适合编写服务端动态Web应用，有利于商业逻辑的封装；但是用于网络通讯的支持不足；静态页面定制支持有限，使得PB在网络方面的应用也不能非常广泛。面向对象特向也不是太好。

建议：如是从事信息管理系统的开发或各类数据库的跨平台开告数发都可以选用此工具，在开发速度上也可得到一定的保障。

(三) C++Builder/Delphi

它们都是基于VCL库的可视化开发工具，它们在组件技术的支持、数据库支持、系统底层开发支持、网络开发支持、面向对象特性等各方面都有相当不错的表现，并且学习使用较为容易，充分提现了所见即所得的可视化开发方法，开发效率高。由于两者都是Borland 公司的产品，自然继承了该公司一贯以来的优良传统：代码执行效率高。但是，它们并不是毫无缺点，它们所作的最大不足之处就是他们的帮助系统在众多的编程工具中是属于比较差的。C++Builder 的VCL库是基于Object pascal(面向对象pascal),使得C++Builder在程序的调试执行上都面向落后于其他编程工具。而Delphi则是它的语言不够广泛，开发系统软件功能不足两个比较大的缺点。

建议：C++Builder/Delphi 它们在功能具有非常相似的特点，都可以用来开发数据库茄告，网络、多媒体，但是C++的语法较为灵活使用也较为广泛，而Delphi（Object Pascal）在灵活性上、功能性上以及使用人数上都不如C++。

(四) Visual C++

是基于MFC库的可视化的开发工具，从总体上说它是一个功能强大但是不便使用的一种工具。它在网络开发和多媒体开发都具有不俗的表现，帮助系统也做得非常不错（Microsoft 在细节方面的处理往往都让人觉得亲切），但是虽然是使用C++作为基本语言，但是它在面向对象特性上却不够好，主要是为了兼容C的程序，结果顾此失彼；在组件支持上也不太好，虽然说除了支持COM,ActiveX外还支持CORBA,但是没有任何IDE支持，是所有C编译器的功能, 需要CORBA中间件支持蛔畲蟮奈侍馐强?⑿?室膊桓摺?br>

建议：如果要使用VC一定要对它的MFC库非常熟悉，不然是写不好的程序的，而且要有一定的耐心，VC的入门比较难。不过掌握了它你可以在网络、系统底层、多媒体开发等领域自由驰骋。

(五) Java编程工具

目前比较出名的是Borland出的JBuilder和IBM出的Visual Age for Java,两种工具都有一定数量的是用人群。JBuilder继承了C++Builder/Delphi的特点，在可视化上做得非常不错，使用简便。由于Java本身语言的特点使得他们在网络开发中具有高人一等的表现，而且面向对象特性高，支持的组件技术也非常多，跨平台的特性也使得它在现在和未来的开发中占据越来越重要的地位。但是在系统底层开发和多媒体开发中却表现得并不让人那么满意，这个可能跟设计Java的意图有关吧。

希望采纳！！

---