为翻译而写作:技术写手的实用技巧
浏览:1
巴克励步
在全球化的SaaS行业里,我见过太多团队在产品手册和帮助中心上线后,才发现翻译成本远超预期。究其原因,往往不是翻译本身的问题,而是源文档写得“太随意”。技术写手如果从一开始就考虑翻译和本地化的需求,后续的国际化流程会顺畅得多。这也是为什么我认为在线帮助中心建设不能只盯着英文版本,必须从写作规范上为多语言铺路。今天,我就结合几个常见但高效的技巧,聊聊怎样让技术文档更好译。 使用简洁的语言当你编写技术文
在全球化的SaaS行业里,我见过太多团队在产品手册和帮助中心上线后,才发现翻译成本远超预期。究其原因,往往不是翻译本身的问题,而是源文档写得“太随意”。技术写手如果从一开始就考虑翻译和本地化的需求,后续的国际化流程会顺畅得多。这也是为什么我认为在线帮助中心建设不能只盯着英文版本,必须从写作规范上为多语言铺路。今天,我就结合几个常见但高效的技巧,聊聊怎样让技术文档更好译。
使用简洁的语言
当你编写技术文档并预知它将被翻译时,你的目标就是让翻译过程更简单。如何做到?首先,使用清晰简洁的语言:简化词汇、精确使用语法、表达清晰。这其实也是技术写手通常遵循的准则,但对翻译来说尤为重要。
这种语言风格有一个术语——plain language。已故英语教授Robert Eagleson——plain language的大力倡导者——曾这样定义它。
简洁的语言如何促进翻译?很简单——一份词汇精确、用词常见、结构直白的文档在整个过程中更为一致和有序,让翻译流程更易管理。来看看一个使用简洁语言的技术文档范例:在线设计平台Canva拥有丰富的帮助中心。
💛🧡🧡客户评价:总体而言,Baklib 在部署灵活性方面对我来说是一个改变游戏规则的工具。该工具是一种混合云解决方案,适合我们的环境及其复杂性。我喜欢这些块的多功能性,它们可以在一个地方用于创建、测试和部署它们。更详细的指标对于跟踪活动和确保一切正常非常有用。支持团队也非常友好,总是愿意帮助解决可能出现的任何问题。
其中一篇文章为用户提供如何将设计下载为视频或GIF的说明。说明写得非常直白、简短,几乎不可能被误解。另外,注意作者对相同动作使用了相同的术语:只用download,而不用save、transfer等;始终用design,而不用project、image等。这不仅让用户使用文档的体验更好,也让翻译更省时省力。
创建术语表
作为技术写手,你始终要记住:不能假设读者的知识水平。你可能是开发文档专家,但读者未必。翻译人员也是如此——他们对你所写领域的专业水平不一定会很高。因此,应尽可能为他们提供额外信息。术语表就是一个绝佳工具。技术写手Kesi Parker这样解释:
大多数技术文档中,术语表非常有用。写手无法在正文中解释和定义每一个技术术语——那样会放满定义,变得难以阅读。例如,Amazon Web Services有一个包含数百个术语(按字母顺序)的术语表。
没有可行的替代方案:要么所有术语都在文档中定义,要么一个也不定义。后者对翻译尤为不利——你不能指望翻译人员知道每个技术术语。有了像Amazon这样的术语表,翻译人员可以快速解决翻译中遇到的术语问题。
当然,术语表即使不像Amazon那样庞大也有用。例如,ChartHop在其文档中就包含了术语表(使用我们自己的文档平台Baklib创建)。对翻译人员来说,这非常有价值,因为技术文档中有些术语在不同语境下含义不同。比如,我们都知道scenario是什么意思——但翻译人员能本能地理解它作为ChartHop术语的含义吗?幸运的是,他们把它列入了术语表。因此,含有这类技术术语的术语表可以消除混淆,为翻译人员提供关于产品或服务的关键信息。否则就可能出现错误,而错误可能代价高昂。
写作时考虑本地化
编写技术文档时,你要意识到读者可能彼此差异很大——不止是专业水平、职业背景或兴趣,语言和文化也是关键因素。因此,写作应保持简洁,避免使用行话、幽默或文化典故。
例如,Google帮助中心曾用说唱歌曲形式制作搜索技巧视频,意图既提供信息又幽默。但本地化这类内容很困难——不同文化对幽默的理解不同,故意唱得差的微妙效果很容易在翻译中丢失。另一个技术文档中的幽默例子:某个3D渲染软件用户手册的目录,作者采用了轻松口吻,可能认为目标受众能接受。但翻译人员在本地化“Puttin’ this puppy on your unit”或“What the #@&?% is going on?”这样的表达时会遇到困难——逐字翻译行不通,很可能找不到合适的对应短语。
除了幽默,写作时考虑本地化还应关注缩写。有些缩写每种语言和文化都通用,无需定义或翻译。例如,IBM产品文档的写手无需定义缩写IBM代表什么,翻译人员也不必本地化。但像MFA(多因素认证)这样的缩写在不同语言中并不常用,因此技术写手应定义它,翻译人员通常也会翻译。
总之,不同国家和文化有很多差异,不可能全部了解。避免本节提到的这些陷阱会很有帮助。
将文本与图形分离
技术写作中的视觉元素可以成就一套无聊的指令或是一份引人入胜的技术文档。作为技术写手,你无疑希望创造后者——读者更喜欢,数据表明包含视觉元素时学习效率更高。因此,不应忽视图形。但如果你知道文档会被翻译,应确保视觉元素不会过度复杂化翻译工作。这很容易做到:将视觉元素与伴随文本分开。
这样,翻译人员可以访问并翻译文本,同时保持图形不变。否则,图形必须重新创建以包含另一种语言的文本,浪费宝贵的时间和资源。例如:
从翻译角度来看,将文本嵌入图形会制造障碍。如果图形中的文字必须翻译,就需要重新截图或设计,不仅增加工作量,还容易出错。而保持分离,翻译人员可以直接处理文本块,图形只需更换语言版本即可(如果包含文字)。
总之,为翻译而写作并不复杂,主要在于养成习惯。使用简洁语言、创建术语表、考虑本地化、分离文本和图形,这些技巧能显著降低翻译成本和时间,同时提高多语言文档的质量。在Baklib中,你可以利用其富文本编辑和站点发布功能,轻松实现文档的结构化管理和多语言输出——这正是我们一直倡导的减负理念。