中国语言服务行业规范.doc

1、中国语言服务行业规范本地化服务报价规范（预发布版）2013 年 8 月 26 日前言中国翻译协会是包括翻译与本地化服务、语言教学与培训 、语言技术工具开发、语言相关咨询业务在内的语言服务行业的全国性组织。制定中国语言服务行业规范，推 动行业有序健康发展，是中国翻译协会的工作内容之一。本地化服务报价规范分为规范框架和规范内容两个部分，规范框架是对该规范适用范围和结构的介绍。规范内容是 该规范的主体，分 为以下四个部分：软件界面本地化文档本地化单价与翻译记忆库匹配率的关系本地化服务报价模型本规范由中国翻译协会本地化服务委员会编写，由中国翻译协会发布。本规范主要起草单位：中国翻译协会、中国翻 译协会

2、本地化服 务委员会。本规范主要起草人：林怀谦、蔺 熠、黄翔、崔启亮、陈圣权、陶慧、黄长奇、杨颖波、魏 泽斌。本规范计划于2013年10月31日首次发布。说明：如果您对本规范有任何意见和建议，请写邮件到 gavintaclsc.org，或者新浪微博 本地化服务委员会 TACLSC本地化服务报价规范框架1. 适用范围：本规范定 义 本 地 化 服 务 报 价 相 关 的 任 务 与 报 价 方 式 ， 以 软 件 用 户 界 面 和 文 档 本 地 化报 价 为 处 理 对 象 ， 分为“软件用户界面本地化服务报价项定义” ， “文档本地化服务报价项定义” ， “单价与翻译记忆库匹配率的关系”和“

3、本地化服务报价模型”四个部分。本规范适用于产品的本地化服务报价。2. 软件界面本地化1) 文件翻译前/后处理2) 翻译3) 调整对话框4) 本地化软件编译5) 界面测试6) 语言质量测试7) 本地化功能测试8) 缺陷修复、确认测试及回归验证9) 术语及翻译记忆库维护10) 项目管理11) 报价模型3. 文档本地化（手册、联机帮助、Web 内容以及电子课件）1) 文件翻译前/后处理2) 翻译及可读性检查3) 软件界面拍图及图形编辑4) 桌面排版5) 联机帮助编译及格式检查6) 内容发布及格式检查7) 软件界面一致性检查8) 交叉引用一致性检查9) 缺陷修复、确认测试及回归验证10) 术语及翻译记

4、忆库维护11) 项目管理12) 添加字幕13) 语音本地化14) 多媒体本地化工程15) 报价模型4. 单价与翻译记忆库匹配率的关系针对常见的翻译记忆软件，使用翻译记忆库对源语言文件进行内容分析，得到相应的折算报价比率。以上每项均从“定义、所包含的具体任务、定价机制（按字数、小时、百分比(%) 等） ”三个方面进行解释。软件用户界面本地化服务报价项定义任务 任务定义 任务描述 定价机制文件翻译前/后处理File pre-process and post-process文件翻译前后处理属于本地化工程的一部分，在翻译前后，由本地化工程师对文件进行必要工程处理的过程。经处理后的文件既可使用适当的本地

5、化工具进行翻译，以充分利用这些工具的高效性与经济性，同时又能保证与源语言文件相同的结构与格式，以便其能够进行正确地编译及运行。前处理：- 分析资源包，挑选出需要翻译的文件。- 选择适当的本地化工程/翻译工具。- 针对选定的工具，定义配置文件，确保需要翻译的字符串可以在工具中翻译，并将不需要翻译的内容保护起来，以不被修改。- 对文件格式进行必要的转换，创建翻译包；- 确定工作范围以及工作项，并根据情况基于上一版本文件或翻译记忆库分析文件，统计工作量。后处理：- 将已翻译好的文件转换回原始格式。- 根据项目要求，进行编码设置或转换。- 检查文件名及文件夹结构，确保与源语言文件一致；或根据特定要求进

6、行必要的更改。按所花费的小时数计费。翻译Translation使用适当的计算机辅助翻译工具，将软件界面字符串由一种语言转换为另一种语言，并使翻译后的字符串符合目标语言的要求与风格的过程。该任务一般由本地化公司内部或外部译员执行。包含以下五项活动：- 翻译：使用适当的工具翻译用户界面字符串，且本过程中必须遵循客户要求及行业术语，符合目标语言的格式、文化风俗等方面的要求。- 校对：对已完成翻译的文件进行检查并更正发现的问题。- 可读性检查：对已完成翻译与校对的文件进行全面检查，包括检查静态字符串文本的流畅性，验证术语遵从性与一致性，核对热键的正确性等。- 内部质量保证检查：在翻译/校对过程中或提交

7、文件给客户之前，由质检人员按一定比例抽检。然后，根据检查结果采取必要的措施，如更正发现的问题或者返工。- 根据客户方反馈修改：客户方检查语言质量并给出反馈意见后，翻译人员根据反馈意见修改文件。按加权字数计费。关于模糊匹配的换算关系，请参阅“单价与翻译记忆库匹配率的关系”。用户界面布局调整UI Layout Resizing对资源文件中的静态对话框进行格式检查和调整，使其控件的大小、位置、样式等适合翻译后的文字，以确保文字显示完整美观的过程。- 根据资源文件的类型选择适用的工具或软件。- 对所有对话框应用目标语言所要求的字体。- 打开每个静态对话框，检查其中的所有控件是否存在以下问题：控件未对齐

8、、控件或文字重叠、文字被截断或显示不完整、文字换行不正确或其他任何版式问题。- 发现任何问题时，通过拖动控件、调整控件大小、修改坐标值、缩短翻译等方式进行修复。按所花费的小时数计费。本地化软件编译Localized Software Building以源语言软件程序为基础设置编译环境，使用翻译后的资源文件创建目标语言软件安装包的过程。本地化软件编译的具体实现与源程序的开发过程密切相关，通常由客户提供详细的编译指导文档。主要工作包括（但不限于）： - 设置编译环境：包括安装编译所需要的各种应用程序，设置操作系统环境变量，复制编译源语言软件时使用的文件结构，并进行必要的修改（如文件路径、语言代码、

9、脚本代码或批处理文件等）。- 置入目标语言的资源文件后执行编译。如果编译不能成功完成，则需要检查编译环境以及翻译后的文件；待问题修复好重新运行编译。- 检查编译的软件。如果发现了问题（例如由于资源文件编码不对导致的乱码），需要修复问题后重新执行编译。按所花费的小时数计费。界面测试Cosmetic Testing对本地化产品执行的界面外观检验的过程，主要检查界面上的文字和控件布局是否美观，并且是否呈现了所有预期内容。软件界面的主要组成元素包括窗口、对话框、菜单、工具栏、状态栏、屏幕提示文字等。由于本地化后的文字与原始开发语言的文字相比在大小和长度上都有所变化，为了确保本地化后软件界面的准确性与美

10、观，测试人员需要检查：- 各种元素上的文字是否显示完整，包括标点符号、热键等。- 各种控件的排列是否整齐，大小是否一致。- 各种控件的显示是否方便用户操作。- 与源语言界面相比，是否有缺少的控件或内容。- 是否所有可本地化的文字都已本地化。执行可视化测试，既可以按照测试用例逐个按所花费的小时数计费。界面进行测试，也可以直接检查截屏的界面图片。发现问题时，需要在相应界面图片上做出说明并将问题记录在缺陷报告或缺陷管理数据库中；同时需要提供重现操作步骤，以方便在修复问题后进行验证。语言质量测试Linguistic Testing对本地化产品执行的确保语言准确性的测试过程。该过程通常由熟悉软件产品的语

11、言专家执行，检查本地化软件中文字的语言质量是否达到要求。主要工作是检查本地化软件界面内容的语言质量，包括准确性、专业性、完整性、一致性、可读性：- 界面文字是否准确描述了相关的操作。- 术语是否符合专业/行业的习惯用法或客户要求。- 文字表达是否符合本地化语言的表达习惯。- 字符串语义是否完整，是否有语义被截断或衔接不上的情况（通常是由于翻译时未能正确处理组合字符串或由于变量指代不明导致翻译不正确所致）。- 术语或表达是否一致。- 提示信息或错误消息中对界面的引用与实际界面是否一致。- 是否有漏翻译的内容。- 是否有过度翻译的内容，例如不该翻译的产品名。执行语言质量测试，既可以按照测试用例逐个

12、界面进行测试，也可以直接检查截屏的界面图片。如果在本地化软件环境中按照测试用例执行，还需要搭建测试环境。而且，为了保证语言测试的质量，测试人员在测试之前必须阅读和熟悉相关的软件术语表，了解软件翻译的规范与要求。发现问题时，需要将问题记录在缺陷报告或缺陷管理数据库中，同时提供以下信息：- 当前翻译（方便修复问题时定位到正确的按所花费的小时数计费。位置）。- 建议的翻译。- 重现问题的详细操作步骤（方便修复问题后在新版本中进行验证）。- 界面图片。本地化功能测试Localization Functional Testing对本地化产品进行功能性测试，确保本地化后的产品符合当地标准或惯例，并保证各项

13、原有功能无损坏或缺失。在执行本地化功能测试之前，需要针对源语言软件创建测试用例。在测试用例中，列出了需要的测试环境，需要执行的测试步骤以及每一步操作后应该显示的界面或实现的功能。首先，测试人员需要根据测试要求准备本地化测试环境。对于本地化测试来说，需要同时准备本地化测试语言环境与源语言测试环境。然后，测试人员在本地化软件环境中按照测试用例进行测试，检查在执行相应操作后是否能显示如源语言软件中相同的界面，或实现如源语言软件中一样的功能。测试的内容包括（但不限于）：- 本地化软件是否能够正常安装与卸载。- 所有菜单或按钮功能是否正常。- 所有热键/快捷键功能是否正常。- 排序结果是否符合本地化语言

14、的习惯。- 是否支持本地化语言的数据格式（日期、时间、姓名、度量衡、地址、电话号码、邮政编码、纸张格式等）。- 是否支持本地化语言文字的输入、编辑、显示和保存。- 是否支持对本地化语言文字的搜索。发现本地化功能错误后，需要在源语言软件上进行相同的测试，以确定是本地化功能错误还是源软件的设计错误。如果同时进行多种本地化语言的测试，在一种语言上的功能错误还需要在其他语言版本上进行相同的测试，以确定该错误是单一语言特有还是多种本地化版本共有的错误。发现问题时，需要将问题记录在缺陷报告或缺陷管理数据库中，同时提供以下信息：- 测试时所用的环境（包括操作系统版本、相关的软件版本等）。- 重现问题的详细操

15、作步骤。- 预期结果与实际结果。- 相关附件（软件界面截屏、相关的日志文件或其他需要使用的文件）。按所花费的小时数计费。缺陷修复、确认测试及回归验证Bug Fixing and Regression Testing遵循一定的流程和方法，对所报告的各种缺陷进行修复，然后在新编译的软件中验证缺陷是否已被正确修复以及是否引入新缺陷的过程。对于界面外观测试、语言质量测试和本地化功能测试过程中报告的缺陷，需要进行调查和修复。对于界面外观和语言质量相关的缺陷，一般由本地化团队直接在本地化的资源文件中进行修复；如果找不到相应的界面或文字，则需要将报告指回给客户方的测试组长或开发团队。对于功能相关的缺陷，一般

16、由客户方测试组长或开发团队处理；如果调查后发现是由于本地化翻译或工程所导致的问题，缺陷将会指回给本地化团队。本地化团队在软件资源文件中修复缺陷后，需要更新缺陷记录并提供以下信息：- 受影响的文件（及字符串的资源标识）。- 交付修复后文件的日期（以便确定哪个版本的软件将包含修复的内容）。如果未能修复缺陷，也需要更新缺陷记录并提供相应说明。在软件资源文件中修复缺陷后，需要重新执行编译并生成新的本地化软件版本。然后测试人员执行确认测试和回归测试，即在新版本中，按照缺陷报告中提供的重现操作步骤去验证缺陷是否已被正确修复以及是否引入新缺陷。按所花费的小时数计费。术语表及翻译记忆库维护Glossary a

17、nd TM Maintain 在整个项目周期内，对术语表和翻译记忆库进行的一系列维护和更新活动，包括（但不限于）：项目初期创建术语表及翻译记忆库；在项目执行过程中，随着项目信息的更新来相应更新术语表及翻译记库；在项目结束时整理并归档术语表及翻译记忆库。术语表的创建与维护：- 如果客户没有提供术语表，需要基于软件资源文件或文档，筛选关键术语，生成源语言术语列表。该列表中通常包含源语言术语、术语定义或相关上下文、词性、来源等信息。- 根据术语列表中的信息以及相关的参考文档，将术语由源语言翻译为目标语言。- 提交客户审核后，根据客户反馈修改并形成最终的术语列表。- 翻译过程中持续识别新的术语，并定期

18、重复以上步骤（添加术语 - 翻译 - 提交客户审核 - 确定最终翻译），并将新确定的术语添加到术语列表中。- 根据客户在校对文档或执行测试过程中对术语提出的反馈更新术语列表。- 项目结束时，整理术语表并随项目文件归档。及时、准确地维护术语表可以确保这些术语在所有内容中保持一致。翻译记忆库的创建与维护：- 根据客户要求使用旧版本的翻译记忆库或创建全新的翻译记忆库。- 项目执行过程中，定期通过清理最新双语文件的操作更新翻译记忆库。- 根据客户反馈，修改双语文件并更新到翻译记忆库中。- 如果不能通过双语文件进行更新，也可以直接修改翻译记忆库。- 如果需要全局修改某个术语或句式，可以将翻译记忆库的内容

19、导出为文本文件；在外部修改完成后再重新导回翻译记忆库。- 项目结束时，确保客户反馈或缺陷报告中的所有语言相关的修改都已反映在翻译记忆库中，然后随项目归档翻译记忆库。词汇表与翻译记忆库的有效维护可以确保这些信息在将来更新项目中的成功复用。按所花费的小时数计费。搭建测试环境Testing Environment Setup根据客户方对测试环境的要求，安装并配置硬件、系统软件、数据库软件、应用软件环境，确保软件测试环境与客户要求完全一致。搭建测试环境是软件测试中的一个重要阶段，该环境的适合与否会严重影响测试结果的真实性和正确性。测试环境搭建主要包括下面几个要素：1) 确定测试环境的组成：- 所需计算

20、机数量、计算机硬件配置要求。- 部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、Web 服务器及其他相关组件。- 用来保存测试工作中生成的各种文档和数据的服务器所必需的操作系统、数据库管理系统等。- 测试中所需要使用的网络环境。2) 管理测试环境- 设置专门的测试环境管理员角色。- 记录测试环境管理所需的各种文档。3) 测试环境访问权限的管理- 为每个访问测试环境的相关人员设置单独的用户名和密码。4) 测试环境的备份和恢复- 测试环境必须是可恢复的，应当在测试环境发生重大变动时进行完整的备份。按所花费的小时数计费。编写测试用例Test Case Creation测试用例是一种描述

21、具体测试步骤的文档，其中将描述测试的输入参数、条件及配置、操作步骤、预期的输出结果等，使测试人员判断被测软件的工作是否正常。设计、编写和执行测试用例是测试活动中重要的组成部分，测试用例例通常由测试用例管理系统或工具进行管理。编写测试用例通常应遵循下列原则：1) 最大程度地覆盖软件系统的功能需求和风险。测试工程师应在测试计划编写完成之后，在开发阶段编写测试用例，参考需求规格说明书、软件功能点和风险对每个功能点和风险进行操作上的细化，尽可能趋向最大需求和风险覆盖率。2) 测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应有准确定义。3) 测试用例的设计应包括各种类型的测试用例。在设计测试用例时，除满足系统基本功能需求外，还应考虑各种异常情况、边界情况和承受压力的能力等。4) 测试用例的管理。使用测试用例管理系统对测试用例进行管理。通常一个好的测试案例应具备以下特性：- 具有高的发现错误的概率- 没有冗余测试和冗余的步骤- 测试是“最佳类别”- 既不太简单也不太复杂- 案例可重用和易于跟踪- 确保系统能够满足功能需求按所花费的小时数计费。