Bilingual articles
IT Websites
Resources
IT (4)
计算机翻译之基本技巧
软件本地化行业有很多经常使用的行业术语，非行业人士或刚刚进入该行业的新人，常常对这些术语感到困惑。另外，软件本地化行业属于信息行业，随着信息技术的迅速发展，不断产生新的术语，所以，即使有多年本地化行业经验的专业人士，也需要跟踪和学习这些新的术语。
本文列举最常用的本地化术语，其中一些也大量用在普通信息技术行业。对这些常用的术语，进行简明的解释，给出对应的英文。
热键(hot key)。菜单命令和对话框选项中带有下划线的字母或数字。通过按下Alt键和下划线的字母或数字，可以机或命令和选项。
超文本标示语言(Hypertext Markup Language)。SGML语言的子集。定义了一组标示符控制页面内容的显示方式。
输入方法编辑器(Input Method Editor-IME)。通过按下键盘的多个键完成输入本地化文字的应用工具。对于汉字，常用的有微软拼音输入法，标准输入法，五笔字形输入法等。
国际化(internationalization-i18n)。在程序设计和文档开发过程中，功能和代码设计能处理多种语言和文化传统，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。
国际化测试(international testing)。软件国际化的支持和可本地化能力的测试方法。
日文汉字(Kanji)。来自汉字的单个日文字，有些与当前的汉字书写完全相同，但按照日文发音。
启动会议(kick-off meeting)。新的本地化项目正式开始前的会议，一般由原软件开发商和本地化服务商中的项目组主要代表人员参加。主要讨论项目计划，各方责任，提交结果，联系方式等与项目紧密相关的内容。
分层图像(layered graphic)。为了便于翻译，可以翻译的文字单独存放在文字层的图像。
重复利用(leverage)。在翻译/本地化过程中，以前已经翻译的内容再利用和循环使用的方法。
语言测试(linguistic testing)。对本地化的产品执行与语言有关的内容的测试活动。
本地化行业标准组织(Localization Industry Standard Association-LISA)。1990年在瑞士成立，成为本地化和国际化行业的首要协会，目前已经加入的会员超过400多家。LISA的目标是促进本地化和国际化行业的发展，提供机制和服务，使公司间能够交换和共享与本地化、国际化和相关主体相关的流程、工具、技术和商务模型信息。
本地化(localization-l10n)。将一个产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。
本地化工具包(localization kit)。由软件开发商提供的包好文件、工具和指导文档的系列文件集。本地化项目开始前，软件开发商提供给本地化服务商。
本地化测试(localization testing)。对本地化的软件进行语言和用户界面测试，以保证软件本地化质量的活动。
本地化服务商(localization vendor)。提供本地化服务的机构，包含软件翻译、软件工程、测试和项目管理等活动。
机器翻译(machine translation-MT)。利用术语表、语法和句法等技术，自动实现从一种人类语言到另一种语言的翻译的方法和技术。
标识语言(markup language)。与文字结合的标识和标签集合，应用程序（例如HTML网页浏览器）将处理这些标识并以正确的形式显示出来。
多字节字符集(multi-byte character set)。每个字符用单个字节或两个字节表示的字符集。
多语言服务商(multi-language vendor-MLV)。提供多种语言软件本地化能力的服务商。大多数多语言服务商主要集中在多语言项目的项目管理上，它们在全球范围内由多个分公司和合作伙伴。
国家语言支持(national language support-NLS)。允许用户设置区域等软件功能。识别用户使用的语言、日期和时间格式等信息。也包括支持键盘布局和特定语言的字体。
外包(outsourcing)。对软件本地化而言，将某些本地化任务交付给第三方的活动。源软件开发商将软件本地化项目交付给本地化服务商，很多本地化服务商，将翻译工作交给自由翻译人员。
便携式文档格式(Portable Document Format-PDF)。由Adobe公司开发的基于PostScript标准的文件格式。PDF文件可以由其他软件创建，主要用于电子文档的发布。
伪翻译(pseudo translation)。将软件中的可以翻译的字符串用长的本地化的字符代替的自动或手工处理的过程，主要用于发现编译和执行本地化文件时潜在的问题。
质量保证(quality assurance-QA)。保证最终产品质量的步骤和流程。
报价单(Request for quotation-RFQ)。软件开发商发送给本地化服务商的包含项目内容和报价的报价单。
投入回报率(Return of Investment-ROI)。判别项目投入费用和受益回报的指标。
调整(resizing)。调整翻译后的对话框的元素，如按钮、列表框、静态控件等的大小和位置，保证翻译后的字符的显示完整和美观。
资源动态链接库(Resource-only .dll )。包含可以本地化的资源，例如，菜单、对话框、图标、屏幕提示字符的动态链接库。
屏幕捕捉(screen capture, screenshot)。使用图像截取软件截获菜单和对话框等软件界面的过程。
想要扩大用户群？将游戏产品本地化以适应目标市场是一个极好的办法。下面我们提供一些顺利完成游戏本地化的技巧。
译前准备
• 找一个不错的、讲英语的剧本写作员
如果游戏内容需要翻译成好几种语言，最好使用英语作为原文资料，因为几乎所有的译员都接受以英语为原文的翻译。如果原文资料不是英语的，可以先将其翻译成英语，然后才转译到你的目标语言。在本地化过程中总是存在误解蔓延的风险，因此从最开始就采用一位不错的、讲英语的剧本写作员有助于避免这类问题的发生。
• 在发送翻译之前先审校剧本
英语剧本是其它所有翻译的原文，因此有必要事先对它作全面的审校。审校包括拼写检查和语法检查，检查术语是否一致、注释是否恰当、有无可能造成的误解以及在其它语言中不能引人发笑的笑话。
• 使用一致的角色名/场景名/物件名/界面名
保证对话、屏幕文本和手册中术语的一致性是非常重要的。它可以保证统一性，方便翻译并有助于避免出现误解。
• 语言特有的笑话翻译效果不好
翻译笑话从来都不轻松，遇到有双关语/俏皮话以及其它语言特有的笑话或出处时尤其如此。因此，如有可能，避免出现这类笑话——否则，至少记住你得让每个笑话都引得所有目标语用户哈哈大笑！
• 检查台词长度
如果游戏为某句台词设置了最大字符数，请告知译员。尽管用原文表述的这句台词可能不会超过最大长度，但是在译文中很可能就会超过，因为即使表达同一个意思，有些语言就是用词更多。还要注意对话中的台词是否有最长限时。
• 原文错误将按目标语言数量倍增
原文剧本中出现的任何错误都会在需要本地化的所有目标语言中反映出来。因此，在发送翻译之前确保原文资料准确无误肯定是一个好主意!
协助译员
• 译员可能没见过游戏
记住：译员可能没有见过真实的游戏。因此给特定台词（在单独的一列中）添加尽可能多的信息以帮助译员在恰当语境中更好地理解台词。如有可能，提供一个游戏的测试版，这样译员可以在正确的语境中看到台词。
• 提供指引
如上所述，提供游戏的测试版可以帮助译员理解资料的正确语境。假如你不能提供测试版，有可能的话提供物件/人物的图像和描述。截图也是使译员对上下文产生直观感觉的一个好办法。
• 正式还是非正式？
在有些语言中，正式的称呼和口吻与非正式的差别很大。你所希望的目标风格并不总是能在原文资料中一目了然地体现出来，因此让译员或翻译公司知道你想要何种风格。
在本地化过程中
• 较大批量地提交更改
如果在翻译进行的同时原文资料总是在不断更新（不建议这么做，但是有时不可避免），较大批量地提交对原文资料的更改或更新可以保持较低的翻译成本。
• 对于单独的翻译批量：创建一个术语列表
如果屏幕文本、玩家手册、对话、包装不是一次性全部发送翻译，做一个常用物件/场地/措辞的术语列表是不错的主意。在第一轮翻译过程中，译员确定术语列表中术语的译文。在后续的翻译中，这个列表可以用作参考资料。这样做可以确保译文中术语的一致性。
声音表演小贴士
• 使用模拟发声
将英语模拟发声录下来可以帮助你了解游戏中的对话是如何进行的。使用模拟发声还可以使你确保对话中的某句台词表达恰当。在找来配音演员之前，将这些记录下来——当配音演员开始念台词录音时，批准通过的模拟发声可以作为一个指导。
• 为你的剧本添加感叹台词
为了让游戏角色生动起来，给每个角色添加一些感叹台词常常是一个不错的办法——即使你起初可能觉得根本不需要它们。给这些额外的台词录音并不会增加多少开支——但是如果后来你才决定把它们添加进去，可能不仅花费更多，也更耗时，如果你要再次找配音演员来给这些额外的台词录音的话。
• 维持角色
为确保未来作品中的一致性，最好记录下你给当前作品使用的配音演员。这可以保证同一角色的声音在所有产品中听起来都一样。
有人说，本地化翻译项目不好做，一些内容晦涩难懂，而且规矩太多，忙在应付规范上的时间不比做翻译的时间还要少；也有人说，本地化翻译项目很好做，有些项目直接敲字就可以了，瓶颈在于打字速度。其实，这两种说法都一定程度反映了本地化项目的特点和存在的问题。
本地化的内容晦涩难懂？
大多是针对初入门者或非理工类出身的翻译人员而言的。这里并不是说本地化这类技术翻译必须要有理工类的背景，而是强调技术知识对于本地化翻译的重要性。当然，翻译任何内容都需要一定的知识面，可能来自社会，来自生活，或者是个人学习的结果，只不过，合格的本地化翻译在专业知识方面要求会更高一些，需要个人不断的学习和积累。笔者有个朋友是英语专业出身，算是文科了，从事本地化后，他系统地自学了计算机基础知识、编程语言、计算机网络等很多内容，现在是非常出色的资深本地化翻译。
本地化翻译的规矩太多？
软件本地化翻译的需求最初来源于软件的本地化需要，所以自然就会借鉴很多软件工程的项目管理方式和经验，再加上软件本地化在美国和欧洲做的比较早，他们的语言之间具有近似性，这两个特点促成制定了很多软件本地化的流程规范和翻译规范。具体到翻译层面，项目中会有很多 style guide 内容，新手适应这些规范需要一定的时间，而要从事这个领域的翻译，就必须要了解这些规范。很多项目字数可能不多，而需要阅读的 style guide 内容可能会有上百页。当然对于老手，可以凭借经验则其要点，而对于新手，需要一个适应过程。
另一方面，规矩多多，对于翻译这项创意性的工作也是一种束缚，有的时候甚至会扼杀创造性，妨碍翻译内容的准确表达，让翻译工作和翻译内容都索然无味。这也就需要大家有“带着脚铐跳舞”的心理准备，遵守规范的同时要掌握一个度 —— 遵守规范和翻译标准是第一位，在这个基础上再尽量寻求灵活性。
本地化项目“简单”？
有句老话“难者不会，会者不难”，如果译者的计算机知识还不错，对规范比较了解，英语也不差，翻译一般的文档当然是没有问题，有的文档确实就是只需敲字而无需过脑，因为其内容可能已烂熟于胸了。不过，小处也可以见功夫。以常见的软件使用指南中的操作步骤为例，可以说比较简单，但是要真正翻译得准确流畅，让读者清楚明了，还是需要下一点功夫。
这里要强调的就是，本地化翻译的一个通病在于翻译时缺少上下文连贯性，看似简单的翻译，如果不注意前后的衔接，也可能让读者不知所云。这可能是拜 Trados 断句之所赐，但也体现了翻译人员不注重上下文的问题。任何简单的工作都有出彩之处，扫地也可以扫出花来。翻译更是如此，没有最好，只有更好。当然翻译公司大多并不会注重你的“更好”，你只需合乎规范就可以了，正如版主 thinkcell 曾经的经典评论：“本地化翻译是不求有功，但求无过”，这是题外话了，暂且不谈。
结论
一个合格的软件本地化翻译，需要掌握一定的 IT 知识；需要熟悉各种规范，能快速适应新的规范；翻译过程中能够注重上下文的连贯性，需要有点钻牛角尖的专业精神；当然，英文和中文表达也要足够好。
External links
Translation Skills
Share this!
