“ 作为《图数据库实战》的译者之一,分享一下技术翻译的一些心得。”
前段时间,和叶伟民Billy、高俊宁Raymond、周一行一起聊了一下技术翻译那些事儿。这里把我对技术翻译的一些心得和大家分享一下。
我和叶伟民Billy去年合作翻译了《图数据库实战》,现在也在合作翻译另一本关于AI方面的书。也算是踏入了技术翻译圈。
01
—
翻译是一次二次创作
虽然技术翻译不同于文学翻译,必须把原文的意思完整、准确、清晰地表达出来。
但有些时候,原文作者会引用一些谚语,这些谚语对于原语言和文化有意义,对于中文读者就没有意思了。
所以需要充分理解语境和语义,作一些本地化的发挥。
当然,对于技术类书籍,这样的情况不多,但也是有的。
在英语中,有些语句很长,特别是很喜欢通过which和that构成长句,这样的句子直译起来很别扭,我会根据理解用中文重新表达出来。
另外,有些很小的细节也特别困扰人。比如在《图数据库实战》中,会有question和problem这两个词,它们都能被直译成“问题”,但此问题非彼问题。
这些看起来非常简单的词语,却很难在中文找到与原文一致的确切表达,我们在question到底应该被翻译成“问题”还是“疑问”,很难拿捏。有些时候,要通过结合上下文进行定夺,不能一概而论。
所以充分理解原文很重要。当然,翻译也是一次很好的学习过程,等于把被翻译的书完全吃透了一遍。
02
—
翻译与写书
我写过两本书,翻译过一本书,两种体验是挺不一样的。
写书是完全的自我创作过程,需要大量自己的灵感。
虽然在立项的过程中,书的大纲已经基本上有了,但这个骨架很多时候还是需要丰富的。
写书最怕的是虎头蛇尾,开始的时候思如涌泉,到了后面不知道怎么收尾,甚至需要凑字数,这也是为什么有些作者写了好几年都无法交稿。
据说最惨痛的教训是,一个作者精耕了几年,交稿时,他所写的那个技术已经下架了,没有出版意义了。
所以写书是一种对出版社的有风险的承诺,在立项那一刻,能否完成是未知数。但一般出版社给的时间比较宽裕,主动权反而更多在作者身上。
翻译不会有内容焦虑。但是交稿时间有严格要求,而且不宽裕。对于做业余翻译的来说,时间上会有一些挑战。
技术书籍的翻译,不光是要翻译意思,自己要对内容,通常是一种新的技术,要有充分的理解,这也是一个有挑战的学习过程。当然,好处是顺手把这项新技术给学了。
总体上,翻译和写书不同的是,它是一定能完成的任务,只是不同的水平和投入会产生质量的差别。
03
—
敏捷翻译?
我们只花了三个月完成了《图数据库实战》近17万字的初稿,应该算是很快的。我们用了一点敏捷的原则。
首先,要确定每个周末都要投入时间进去;
其次,通过头两周“测速”,看看一个周末能完成多少进度,进而可以推算要多少个周末能完成;
最后,这样就可以做出一个计划,按照推算,可以在交稿前四周完成,后面就有可以继续完善的空间了。
有了这样的计划,就可以继续套用“先完成再完美”的原则:
前半段的目标是完成,尽快地完成,一直闷头翻,对于一些难翻的部分先标记跳过,达到可以交稿的最低要求;
后半段的目标是完善,重新阅读和调整,啃掉前面标记难翻的部分。
04
—
技术翻译的收益
作为非职业的选手,写书的机会可遇不可求,灵感也不是时时有。
但翻译的机会则多的是,几乎所有英语不错的技术人都能参与。
我和我的外籍老板聊天时,他不是很明白为什么会有技术翻译这个行当。我解释了两点:
大部分中国的技术人员不会啃英文原版书,不是每个人都有英语阅读能力,就算有,也没那个兴趣和精力;
英文原版书非常贵,中文翻译版是英文原版价格的1/3到1/2,对中国读者更友好。
对于中国这么一个大市场,技术翻译的机会还是非常多的。
所以,对IT从业人员来说,有这样的机会,愿意投入的,都应该参与,这是在工作以外,提升自己在整个业内知名度的一个途径,也是为自己带来更多机会的一种背书。
一起卷起来吧!
觉得文章不错,顺手点个“点赞”、“在看”或转发给朋友们吧。
相关阅读:
关于作者
刘华(Kenneth)
著有书籍《猎豹行动:硝烟中的敏捷转型之旅》《软件交付那些事儿》
《图数据库实战》中文译者之一。
世界500强银行DevOps与云平台中国区总监
敏捷、精益、DevOps专家
公众号“敏于思 捷于行”博主
精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈、Docker、Kubernetes
曾在QCon、GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100等论坛发表主题演讲
阿里云、谷歌云认证架构师
关注公众号看其他原创作品
敏于思 捷于行
坚持原创高质量软件交付相关文章
觉得好看,点个“点赞”、“在看”或转发给朋友们,欢迎你留言。