刚才很费事地跟一哥们解释完attribute和property的区别。觉得这种事情耗费很大力气很冤枉——两者本来就没有什么可比性，就是因为中文翻译过来含混不清，导致很多人犯迷糊。（C#中我比较倾向于大多数程序员默认的：attribute叫特性，property叫属性。虽然这种翻译也不是太好，从字面看还是区别不大，但是起码没有含混地都统一叫做“属性”。中文MSDN很多时候把这两个词都混称为“属性”，不知道坑害了多少初学者。）

另外XML中的attribute，大多数人统一的叫法为“属性”。这又会迷惑很多人——C#中不是叫“特性”吗？。但是大家应经用惯了，用烂了，已经是既成事实，就没办法改变。我也只能随大溜。这样，碰到有打破砂锅问到底精神的新手，就又要费事解释半天。

所以我就想，如果最初的翻译者有一点严谨和务实态度，就不会导致现在的问题出现。

随即想到影响翻译质量的几个原因：

1.把感情色彩强加到翻译过来的东西上。

比如电影《Spider Man》，翻译过来变成《蜘蛛侠》了，我当时觉得，“蜘蛛侠”多好听啊，台湾译成“蜘蛛人”才难听。后来看了整个系列特别是第三部，才明白“蜘蛛侠”这样的翻译完全曲解了导演的本意，导演想表述的就是一普通大男孩的成长经历：为了报复，放走劫匪，却间接害死养大自己的uncle，他会陷于爱情不能自拔，他不会处理挚友的关系，最后挚友为他而死，他会在成名后飘飘欲仙，慢慢变坏，创下大祸，最后幸运地及时醒悟，悬崖勒马。。。翻译成“侠”的人，肯定是没有细细体会电影的主题，凭个人好恶随便翻译。试想，英文中那么多表达侠义和英雄的词语，为什么导演偏要叫个某某man呢？

　　类似的有《Fantastic Four》-神奇四侠 《iron man》-钢铁侠 《Blade Runner》-银翼杀手。。。很庆幸的是《super man》没有翻译成《超侠》，呵呵

2.译者水平问题

最经典的是“自行车”，港台叫“脚踏车”。估计当时咱大陆那个年代，翻译的人没见过机车摩托之类的，以为已经是所见的最先进的东西了，就叫自行车了。。。后来把汽车，摩托车，电动车都气死了。

《The day after tomorrow》--翻译成《后天》。。。估计译者思考：明天之后的那天，不就是后天吗？于是乎，大笔一挥，《后天》出炉了。

这里有个程序员可能感觉有趣的例子：

瞿杰翻译的《 wpf unleashed 》 （博主注——作者后来有勘误，但这不应该是“失误”，而是他写的时侯根本没有理解清楚）
WPF introduces a new type of property called a dependency property, used throughout the
platform to enable styling, automatic data binding, animation, and more. You might first
meet this concept with skepticism, as it complicates the picture of .NET types having
simple fields, properties, methods, and events. But after you understand the problems
that dependency properties solve, you will likely accept them as a welcome addition.
瞿杰译文如下：
WPF引入了一个新的属性类型叫作依赖属性，整个WPF平台中都会使用到它，用来实现样式化、自动数据绑定、动画等。你可能在怀疑论（skepticism）中第一次遇到这个概念，它使得.NET类型图变得很复杂，其中有简单的字段、属性、方法和事件。但是在你理解依赖属性解决的问题之后，很有可能会把它们作为一种“不错的添加剂”。

跟原文对照，不仅有低级错误（红字标注），意思更是相差甚大，联系上下文，正确的翻译应该如下：

WPF引入了一种新型的属性：Dependency Property(依赖属性).这个属性贯穿WPF的始终。它提供了对样式，自动数据绑定，动画等特性的支持。第一次遇到这个概念时，您可能会对它的合理性产生怀疑：DP的出现破坏了.NET类型的简单性,例如.NET原有的成员，属性，方法和事件都是非常简洁的(fields, properties,methods and events).但当您了解到DP所解决的问题之后，你就会接受它了。

3. 态度不严谨。

　　很多专业词汇，是需要严格推敲的，比如前面说的attribute和property，用随便的态度来应付翻译，是对读者最大的伤害。MSDN中文版上很多文章就是，怎样一个垃圾了得。还有很多出版社和译者，唯利是图，几个星期就搞定一本深奥的专业著作，结果必然是词不达意，漏洞百出。

　　很多国内程序员看书就只看英文原版，开发就只用原版VS，就是这个原因。

4.汉语本身的弱点

　　人无完人，同样，一门语言也是。我们总是嘲笑英文的枯燥古板。但是汉语也有自身的弱点，学过语言学的朋友们可能都知道，我们程序员也经常会遇到——汉语在表达严谨逻辑和科学论述，量化抽象等方面存在先天缺陷 ：

　　1 汉语的名词没有冠词   
　　2 汉语的句子成分不清晰  经常使用拆分结构 介词重赘
　　3 汉语的从句不清晰 没有从句的标志词     
　　4 汉语的动词没有时态结构 导致第3条毛病（因为无法判断一个动词究竟是谓语动词还是非谓语动词）   
　　5 汉语的构词和句子成分混淆     

简言之，汉语没有严格的语法。英文等符号系统的最大优点是， 抛弃一切与探索主题无关的枝节，紧紧扣紧主题， 使得探索有所发现；汉语正好相反，加上历史原因，儒家影响，极尽华丽渲染枝节，淹没主题，当这个习惯发展到极致，就是衰败。

所以，大部分情况是，我们能写出好诗，但是写不出好的科学论文。

当然，汉语想做到精确表达也不是不可以，只是比较困难。前提是作者得拥有深厚的汉语功底，而读者得拥有深厚的理解能力，不幸的是，我们没有那么多精力去先把大伙培养成语言学家，然后再培养成数学家或者物理学家或者计算机专家。我们大部分人并不能准确严密地用汉语表达出我们的逻辑。

很多计算机书籍的译者经常要面临一个问题就是，一个英文的结构紧凑的长句，里面有很多介词、冠词和不同时态，翻译成中文过来，你不得不用很多简单的“的”来连贯起来，结果表达很失败，如果拆分开来，又破坏了原来的紧凑联系。往往无所适从。

写了这么多不好的，说说好的吧，比如大陆翻译的“网络”，就比港台的“网路”形象且准确得多。还有，无论有什么缺点，汉语永远是世界上最美妙的语言之一，无可辩驳。想象一下你陶醉在诗词歌赋中，感叹于滨临书画，脚生花木的美妙吧！

```````刚才有个匿名骂人的评论，被我删掉了。再次声明，我喜欢汉语，台湾是中国不可分割的一部分！说缺点不意味着我卖国。台湾的很多翻译也很烂，但是这不是我文章的重点，谢谢了！

~~~~~~虽然本意不是如此，但是毕竟引发了很多人说我“崇尚港台”，天地良心，我只是个人意见，有错误或者有观点大家不认同是很正常的，大家完全可以反驳，但是骂人是绝对不对的。

~~~~~~关于瞿杰的回复，老实说我就看了个开头，没仔细看。我要说的是，我也不是翻译工作者，我只是一名读者，站在读者的角度说的。读者永远是对的，因为他花钱买书了，他应该得到与他的付出相符的收益。翻译工作是很累，很辛苦，但是那不是借口。你不应该让读者去关心你们译者和出版社之间的权益纠纷或者内部矛盾，读者只关心翻译质量和他买的这本书到底值不值。做过项目开发的朋友都知道，如果项目遇到困难而失败，不要向客户诉苦，那是你们内部的事情，客户只要结果，that‘s the deal 。

我会删掉引起争论的几句，谢谢指教。（再次声明，只删除关于引发台湾讨论的那两句话，其他的绝对不删除，供大家讨论）

另外专门给某人准备了文明礼仪的课程，敬请学习：http://www.cnblogs.com/PatrickChen/archive/2008/12/12/1353749.html