本地化业务流程
1. 本地化指的是在翻译过程中使内容完全适应某一当地市场。
该文档描述了本地化过程以及本地化中全部的术语、问题和方法论。 对于任何想扩大对本地化认识的人，本文档可以用作本地化各个过程、功能和领域的一本参考指南。 该文档偏重事实而非个人观点，因此亦可以用作本地化课题的研究报告。 在多数IT产业看来，本地化这个术语等于翻译加上“其它的东西”。 而事实上，翻译不过是整个本地化拼图中的一部分，有时候甚至不是最重要的那部分。 那么，什么是本地化呢？ 尽管IT行业中对本地化的定义不尽相同，我们认为以下的解释很好地描述了本地化。 我们将会在本文稍后部分更详细地解释本地化，但本地化最简单的定义则是： 在翻译过程中使内容完全适应某一当地市场。 本地化不仅需要理解特定的当地市场，还需要理解围绕某特定行业和/或文化的实际内容。 本地化和翻译相互依赖，正因为如此，需要对二者多些关注和战略。 因此，该文档还试图使读者熟悉IT公司内执行本地化项目的战略相关问题。 此外，本文还旨在回答很多IT界人士经常问自己的一个问题： 完成本地化项目我们需要哪些资源和技术？
1.1谁需要本地化？
如果一家产商想要在特定市场出售一种产品，他必须提供用该国语言书写的相关产品信息，无论他卖的是极其复杂的价值10万美元的ERP系统，还是只值3个波兰兹罗提（约为人民币10元）的洗发水。 很明显，如果没有针对特定区域的译文，所有这类产品或物件都会因为不能抓住客户兴趣，从而遇到市场进入壁垒。 这是极有可能发生的。因为在交易中，任何一个有些许购买兴趣的人，如果无法阅读说明书或者弄不明白商家出售的到底是什么，很快他的购买兴趣就会消失殆尽。 在这种情况下，产商能够期盼的最好情况是：用英语开发的针对东欧市场的产品会有一些说英语的当地居民或说英语的游客愿意购买。 尽管有些物件即便没有英语手册或英语商标也能卖出去，但是多数情况下，缺少本地化营销策略的产品其收入不足抵偿成本。 不幸的是，决定是否将一个产品本地化往往取决于对这种投资的成本估计以及它可能产生的利益（营收/销售额增加），而不是基于本地化后的产品会拥有更多目标用户这样一个假设。
1.2什么是本地化？
正如前面讲到的，将一项产品或服务本地化，就是使其适应另一国家的需求和适用标准。 然而，为了完全理解“本地化”这个术语，我们首先需要理解本地化过程中的各个部分。 本地化过程： 翻译所有的术语、缩略语、标志和单位（简而言之，所有语言相关组成部分）到特定国家的语言（例如，当本地化软件的时候，我们需要翻译用户界面、在线帮助系统、提示消息以及所有的文档）。
本地化图片： 任何出现在项目资料中的图片都必须经过改编以符合目标文化和目标语言的标准。 图片中出现的所有字词都必须翻译。 所有的文化标志（旗帜、衣服等等）也必须改编。 典型的方法包括用新的图片替代已有的图片，例如，当发送给译员的“标志”中呈现的是与目标区域不同肤色的人物、某特定国家的旗帜、具地方特色的公路指示牌、甚至特定国家气候下出产的特色蔬菜时，所有这些都必须经过改编以适应目标文化。
语音本地化： 网站和各类电子出版物有一个共有的特定就是语音元素越来越多。语音本地化这个过程较之 HTML 文档这类标准翻译需要花费更多功夫。 即使简单到只有一个评论员声音的配音报道也需要一个专业的录音室、一位评论员、一位音响工程师、一位导演（对更富挑战的录音来说）以及录音后的数字声音处理。
文化适应性： 对于网站本地化来说文化适应性尤其重要。 传递给网站访客的信息必须以目标国家的文化精神来翻译。 网站的版面设计和结构等细节必须能够吸引相关文化的代表群体。 如果一个网站仅仅经过翻译，但是没有本地化，生成的结果是一个用目标国家语言表述、但被大量的访客认为很做作的网站。 很明显，文化适应性的重要性依不同的主题而不同，但是它总是有一些起码的重要性，并且无论如何都不应低估它的重要性。 有些问题恰恰是培训软件（也就是我们所说的E-learning）所特有的。 例如，所有的案例研究都必须和该国文化相关。 文本中的玩笑和轶事也必须和目标文化一致。 资料中提出的问题必须与译文的其余部分内容相符，提问的措辞方式也必须使其同原文问题难度相当。 理解所有这些元素不仅可以使你了解文章开始陈述的本地化的定义，还可以了解其重要性。
1.3 专业本地化过程的各个方面
为保证本地化项目的成功，专业的本地化过程应该是什么样子呢？ 下面的特征构成了本地化过程：
质量方针
每篇译文都需要经过目标语为母语者的检查。 翻译和审校后的译文还需要打印出来重新阅读，目的是找出在非全文查看下难以发现的错误。 认识到即使是最好的译员和审校也会犯错是很重要的。
功能测试应该得到全面执行以识别用户界面的所有缺陷。
类似地，语音录制也应该有质量控制。
资源分配
资源分配包括团队内部的以及合作完成同一项目的各团队之间的信息交换流程，无论交换的信息是关于特定的术语、项目主要方面的保留意见、或项目相关查询。
报告本地化工作的进展。
专业术语的应用。
确保每个项目都分配有顺利完工所必需的资源。
技术方针
如果使用的工具和技术对特定项目或子合同已经足够了，而使用这些工具和技术的人对此也很熟悉，那么每个同项目相关的人都能多睡几个安稳觉并且项目也会按时完成。 使用工具可以加快与下列各项相关的部分工作的自动化：
HTML 检查；
用户界面测试；
.hlp格式帮助文档测试；
.chm 格式帮助文档测试。
优化工作流及项目流程管理
应做好工作计划以避免错误繁殖的风险； 所有的任务必须计划好进度以避免被其它任务延误的风险；
只有资源分配合理才能实现目标；
计划项目工作时应以在团队之间平均分配任务量以及考虑经常出现的紧急情况为目标。
2. 专业的本地化流程
在本地化中重要的是执行流程。 若项目方法正确则一定会开发出成功的产品。 另一方面，任何在缺少细致准备的前提下执行项目的尝试都很可能对成本、交货期限或产品质量产生消极影响，最糟糕的时候对这几个方面全都有影响。 因此，战略化，聪明地战略化！ 以下是执行本地化项目的流程： 不同类型的本地化项目的不同阶段需要强调不同的东西。 根据项目本身特有的性质，有些阶段会复杂些，有些阶段要简单些。
1. 分析和评估项目规模
这无疑是整个过程中最重要的一部分，因为它会影响到后面的整个本地化过程。 错误地分析特定问题会破坏整个项目，尤其会增加成本或延长项目执行过程，更别提对质量造成的消极影响了。 衡量项目的规模我们通过拟出一个所有文件中需要翻译的文本量的详细说明。 即使在项目的这一早期阶段，我们也必须意识到哪些文件包含需要翻译的部分。 全面评估项目规模对后续的执行至关重要，因为它可以使我们为所有的组件（例如语音、图形或文本）计划全部的阶段。
2. 项目计划
项目计划的目标是：
为单个团队和团队成员分配任务和角色；
建设要使用的工具；
创建项目进度表；
开发逐级上报流程（如果遇到额外的困难我们怎么做）；
开发信息流和信息交换流程（译员、软件工程师/程序员、DTP人员和语言专员之间）；
在团队内部和合作开发同一项目的不同团队（和公司）之间开发一个沟通模型；
为单个项目任务设立最后完成期限；
为提交查询和透明的查询处理制度建设标准表格。
3. 开发支持资料
开发风格指南和译文指导手册（这些文档基于特定类型项目已有模板准备或专门为手头项目准备） 验证程序（QA）: 开发足够的验证本地化后资料（包括译员指导手册）的流程对项目最终质量至关重要。 很明显的一个例子是确保翻译过后的所有 HTML 资料中的超链接都能正常工作。 如果这一任务作为流程中的一个步骤写了下来，我们就可以保证不会将它遗漏。
4. 准备参考资料
参考资料指的是本地化项目相关人员，包括译员、审校、工程师和测试员可以获得的资料。 准备这类资料的通常原则如下： 参考资料越多越好。 为此，我们可以使用较老版本的文档、帮助字符串或软件测试。 显然，如果相关软件是一个新产品，就无法获得这些资料，则可以使用实质上相似的资料（例如相似的软件、类似主题的文档等）。 参考资料的开发应该抱着容易获取以及浏览的想法。 例如，创建100份参考文件是无用的，因为搜索100个文件来解决项目期间发现的一个问题太过耗时。 在这种情况下，相关文档应该合并为一个文档，并保留原文档/文件的信息以作进一步参考。 例如，使用SDLX软件（所有版本）整合的一个工具或Perl脚本语言可以几个 HTML 文件粘贴到一个大文件中。由于翻译记忆库和术语库是译员最容易获得的资料，它们也成为最重要的参考资料。 实际上，所有TM软件的一个特征就是将记忆库和术语库整合到翻译编辑环境中。 这是使用该信息最快捷、最方便的方式。 我们只需选中文本，点击相关的按键查看搜索结果即可。
5. 配置TM工具
正确配置TM工具的方法如下：
配置切分规则；
定义不需要翻译或编辑的文字或短语（例如，专有名词）。
6. 导入TM环境（转换为TM软件的格式）
导入TM环境就是将我们想要翻译的文件转换成TM软件的格式。
7. 预翻译（可选）
对于某一文档（例如帮助文件或软件），如果我们的翻译记忆库中有它的旧版本，我们就可以实行预翻译。 预翻译可以减少翻译成本，因为预翻译的文本只需作为项目的一部分审校即可。
8. 翻译
翻译是使用TM编辑环境进行的，同时要遵守风格指南并使用所有可获得的项目参考资料。 TM工具通过提供快捷方式以及其它节约劳动的功能增加了译员的产出。 使用TM工具还会降低翻译和审校的成本。
9. 审校
审校也需要在TM编辑环境中完成。 在审校过程中，应该尽可能地预览目标文档的格式（有些TM软件有内置的预览功能，而其它的必须导出才能以目标格式查看）。 审校也可以不断地在纸面上查看译文，检查目标文档的排版和布局。 这在翻译排版复杂的文档或 HTML 页面时很有用，例如：
审校时，我们使用以下功能来支持审校过程：
术语检查（该功能使用项目的术语库来检查翻译的文本与存储的术语是否一致）；
拼写检查（这个功能检查拼写，通常和流行的字处理软件中的拼写检查操作相似）
格式正确性检查（这个功能检查源文本的格式是否正确地转换到译文中；它是在句段水平操作的）
10. 导出为目标格式
通常是简单的从TM软件的工作格式转换为目标格式。 在Trados软件中，当处理.rtf文件时，这意味着仅仅去除为切分而插入的标记。 如果文档存储的格式更为辅助，这一操作可能导致错误，例如在Trados软件中操作FrameMaker文件时。
11. 功能测试
在功能测试阶段，检查最终翻译产品。 本地化过程中这一阶段的重要性和长短主要取决于项目的类型： 软件本地化项目需要编译和测试，若是双字节文件（.exe和.dll）在只需要测试。 对于网站本地化项目，我们检查本地化后的站点所有链接功能是否完好、正确，所有脚本语言是否运行正确，以及包含语言特定组成的元素是否都本地化了。
12. DTP桌面排版：
对于使用电子设计软件（例如Adobe FrameMaker或QuarkPress）制作的专业出版物，文档的整体外观就显得至关重要。 主要注意的细节包括字体、整个版面设计（各自的位置和题注），插图、页眉和页脚。 电子文本的版面设计包含上面所有方面以及更多。 对于每种文件格式当然有其特定的问题。
13. 更新翻译记忆库和术语库
完成功能测试过程中所有的更改后，有必要更新翻译记忆库和术语库。 这将确保未来同样的错误不会在相似的译文中出现。 我们还可以保证项目创建的参考资料是完全正确的。
3. 本地化支持技术
本章描述支持本地化过程的工具。 这些工具可以用在任何本地化或翻译项目中，从简单的翻译一个文档到本地化一个复杂的软件。
翻译记忆工具
这类工具支持翻译和审校（通过使用翻译记忆库） 要了解更多如何使用翻译记忆库，请查看本文档最后的定义。
翻译工具可以用来：
翻译几乎任何格式的文件；
统计一个或多个文件中的文本字数；
创建和编辑翻译记忆库的内容
创建和编辑术语库的内容
有很多翻译记忆工具可供选择，它们包括：
Trados,
SDLX,
Déjà vu,
Transit,
WordFast,
TransSuite 2000,
MetaTexis.
软件本地化工具
这些应用程序用来翻译包含软件组件（例如用户界面或程序提示信息）的文件。 这类应用程序包括：
SDLinsight,
Catalyst,
Passolo.
这些类型的应用程序还配置有检验功能，即检查翻译过后组件的正确性。 在很多情况下，如果翻译过后的软件不包含诸如信息与对话框大小不合适这类错误，这些功能用来检查已经足够了。
测试工具
这些应用程序用来完成用户界面、RTF或 HTML 帮助文档的测试，同时也包含网站测试的工具。 他们在功能测试阶段非常有用。 功能测试阶段的起点常常是咨询这些程序生成的错误报告。 在很多情况下，所有检查出来的问题可以通过应用程序中编辑得到解决。 使用这些应用程序并不能省去对本地化后应用程序的手动检验。 这类应用程序包括：
SDL Tool Proof,
SDL Help QA,
SDL HTMLQA.
图形编辑器
这类软件用来编辑图形文件。 最简单的图形本地化的例子大概是用一个波兰语的图形替换一个英语图形，但是文件格式是包含层的。 复杂图形的本地化往往非常耗时，而且不仅需要丰富的图形编辑器的知识还要具有艺术天赋。 当前市场上有的这类应用程序包括：
Adobe Illustrator,
Adobe Photoshop,
Corel Draw,
Paint Shop Pro.
4. 项目样例
下面是一个典型的本地化项目例子，包括本地化一个程序以及翻译文档和帮助字符串。 基本的步骤如下：
获取文件格式，检查相关问题，
选择项目工具，
项目计划识别流程，定义项目团队成员的角色，
翻译和审校，
导出为目标格式以及功能测试
4.1 项目简述
我们得到的这个本地化项目如下：
程序是用Delphi IDE生成的，
在线帮助是.chm格式的（已编译的 HTML 文件），
PDF文档是用Adobe FrameMaker创建的。 注意： 软件本地化项目中很多时候，用户界面需要翻译的字数最少。 但是，从技术角度来讲，用户界面本地化却反而是最费劲的，由于测试本地化后的界面是一个劳动密集的过程。 所有文档除了翻译外，还需要桌面排版，而在线帮助，除了翻译外，还需要功能测试。
4.2 评估项目规模和需要使用的编辑工具
必须使用合适的工具来评估项目及其子部分的规模：
软件我们有以下选项：
如果有应用程序的源代码我们可以决定是否使用TM软件或使用本地化工具翻译（注意： 并非所有的TM软件都能够用来翻译源代码文件；查阅程序手册确认）；
如果没有源代码而已编译文件（.exe，.dll……）已经本地化了，必须使用能够处理这些类型的文件并能够抽可译文本的软件。 这类软件包括SDL Insight、Passolo和Catalyst。 每种工具包括字数统计功能，当所有文件都分析过后，生成软件中可译文本的字数统计。 在我们的项目中，可译文本的总字数是5,400字。
.chm格式的在线帮助系统 我们总共有2,128个 HTML 文件组成了软件的在线帮助系统。 如果我们使用的工具内置有将项目中所有 HTML 文件合并为一个文件的功能，我们现在就可以将所有的文件导入到TM工具中。 完成导入后，项目字数统计功能将会对可译文本进行字数统计。 假设我们使用的是SDLX软件： 所有的小的 HTML 文件都被合并为一个大的文件，之后这个文件被导入到SDLX Edit工具中。 Log 文件提供所有2,128个 HTML 文件的字数统计。 我们还知道内部重复的数字，例如所有文档中重复的单词和短语。 因此，我们知道真实的翻译字数统计。
FrameMaker格式的文档：
首先.fm文件必须保存为.mif格式，这样它们才能导入到TM软件中。 然后他们必须转换为软件的编辑模块可以处理的文件格式。 大部分的这类工具都提供了一个同类型文件的批量导入功能，并把结果存在一个log文件中，这样即使翻译了大量的文档，我们也可以立刻知道真实的翻译字数统计以及内部重复量。
评估项目规模时容易出现的问题：
如果我们没有能够将所有 HTML 文件融合到一个或多个大型文件的工具，那么我们就会有大麻烦了。 逐个翻译2,128个文件是可行的，但是绝对不是最优方案。 最优方案是我们自己创建一个软件。 可以使用Perl脚本语言或使用任何软件开发环境甚至VB编辑器（或者更准确地说，VBA）都能创建的简单可执行文件，集成在MS Office套件中，或者一个带有适用流程的DLL库。
如果我们的本地化工具不能处理项目中的某一特定文件类型，也会出现问题。 这种情况下必须定义这类文件的设置。
4.3 项目计划
项目计划必须包括：
项目每阶段（翻译、审校、测试）的时间表；
项目过程中使用的参考资料的说明；
项目需要的所有必不可少的文档，例如译员、审校和工程师指示说明书，强调他们需要特别注意的问题；
关于项目术语需要遵循的流程；
如果出现问题的应急流程；
项目相关信息的沟通安排；
提交项目相关查询的标准格式；
本地化团队中每位成员在当前项目中的角色分配。
当然，这些文档中哪个是特定项目需要的、对它有帮助的，取决于项目的大小和复杂度。 对于大型的复杂项目，有必要将以上列出的所有文档尽可能以同种格式存储，这样在项目进行中，它们能够即清晰、也有益。 这样准备这些文档所花费的时间才花得值。 如果公司没有一个经验丰富的团队，也不能分析项目或准备项目计划，它可以使用本地化机构提供的咨询服务。 本地化机构常常为IT公司免费提供这类服务。
如果手上的项目庞大、技术上又很复杂（通常二者伴随出现），那么使用这类服务当然是明智的。 投资本地化技术当然有利可图： 降低翻译成本以及减少不能按时完成项目的风险。 以下的参考资料在我们的项目样例中会用到：
微软术语表，包含了在微软应用程序和操作系统中使用的术语；
一个从门户网站对齐得到的TM库，拥有和我们正在翻译的应用程序非常相似的功能；
多个和资产管理以及计划相关的术语库；
在项目中我们还会用到因特网上覆盖相关主题领域的在线词典。
4.4 执行项目
项目执行时与提前准备好的计划相一致且基于为项目开发的指示这一点很重要。 当然，在项目过程中可能需要重新审阅某些项目，例如某一特别任务的时间表。
翻译用户界面：
如果一个应用程序是用Delphi开发的，最优方案是选择一款可以处理这中文件格式的本地化工具或翻译记忆工具。 翻译完成以后，文本在相同环境下审校。
翻译帮助字符串：
如果使用的是SDLX软件，例如：
HTML Utilities选项用来合并所有的文件为六个大的 HTML 文件，每一个包含大约400个源文件；
这些文件导入到SDLX软件中（从 HTML 转为.ITD文件，即可以通过SDL Edit模块完成翻译的一种文件格式）；
功能测试：
软件编译完成后，就必须检查软件中所有窗口的外观。 最好通过使用一个能够自动检查用户界面错误（例如字符串太长或元素之间重叠）的工具开始项目的这个阶段。 下一步，测试员在指出具体软件特有问题的指导下手动测试整个应用程序. 他们工作的结果通过标准的报告格式提交给技术团队来改正这些问题。
翻译文档：
文档可以使用任何的翻译记忆软件来翻译；FrameMaker格式非常流行，所有计算机辅助翻译（CAT）工具都支持。 使用同一参考资料的审校也是在TM软件中进行的。 翻译验证的最后一步是查看全文（最好是打印出来）看看有没有错误或瑕疵。
DTP桌面排版：
项目的最后一个阶段是对文档进行最后的格式编排。 在我们的例子中，桌面排版必须使用FrameMaker软件，由于源文件是用该软件开发的。 要留意细节，例如：
使用同源文件相一致的字体，
插入本地化后的图形文件，
维护页面的版面设计，这样文档的外观才会和源文件相同。
项目样例总结：
以上描述的项目样例覆盖了本地化过程中可能遇到的情况和问题。 这里有必要指出，当第一次处理某个特别文件格式时，可能会遇到与翻译这些文件相关的特定技术问题。
5. 总结
本文档中提供的信息和例子有力地说明了本地化是一项复杂的过程，需要使用一流的技术以及一个经验丰富、乐于献身的专业团队。 本地化团队不能临时成立，例如仅仅为了一个特定的项目，因为这将会导致低质量的产品。 本地化团队成员必须查看的参考资料数量巨大，结果使得本地化过程极为耗时。 因此，高质量的本地化服务当然不会便宜，但是却物有所值。
妙文翻译公司
中文
