译Q颜玉祚Q北京大学计机辅助译专业Q?/FONT>
译公司的本地化挑战
1. 本地化指的是在翻译过E中使内容完全适应某一当地市场?o:p>
该文描qC本地化过E以及本地化中全部的术语、问题和Ҏ(gu)论?/SPAN> 对于Mx大对本地化认识的人，本文可以用作本地化各个q程、功能和领域的一本参考指南?/SPAN> 该文偏重事实而非个h观点Q因此亦可以用作本地化课题的研究报告?/SPAN> 在多数IT产业看来Q本地化q个术语{于译加上“其它的东西”?/SPAN> 而事实上Q翻译不q是整个本地化拼图中的一部分Q有时候甚至不是最重要的那部分?/SPAN> 那么Q什么是本地化呢Q?/SPAN> 管IT行业中对本地化的定义不尽相同Q我们认Z下的解释很好地描qC本地化?/SPAN> 我们会(x)在本文稍后部分更详细地解释本地化Q但本地化最单的定义则是Q?/SPAN> 在翻译过E中使内容完全适应某一当地市场?/SPAN> 本地化不仅需要理解特定的当地市场Q还需要理解围l某特定行业?或文化的实际内容?/SPAN> 本地化和译怺依赖Q正因ؓ(f)如此Q需要对二者多些关注和战略?/SPAN> 因此Q该文q试图读者熟(zhn)IT公司内执行本地化目的战略相关问题?/SPAN> 此外Q本文还旨在回答很多IT界h士经帔R自己的一个问题：(x) 完成本地化项目我们需要哪些资源和技术？
1.1谁需要本地化Q?o:p>
如果一家商想要在特定市场出售一U?/SPAN>Q?/SPAN>他必L供用该国语言书写的相关品信?/SPAN>Q?/SPAN>无论他卖的是极其复杂的h(hun)?/SPAN>10万美元的ERPpȝQ?/SPAN>q是只?/SPAN>3?/SPAN>波兰兹罗?/SPAN>Q?/SPAN>Uؓ(f)人民?/SPAN>10元）的洗发水?/SPAN> 很明显，如果没有针对特定区域的译文，所有这cM品或物g都会(x)因ؓ(f)不能抓住客户兴趣Q从而遇到市入壁垒?/SPAN> q是极有可能发生的。因为在交易中，M一个有些许购买兴趣的hQ如果无法阅读说明书或者弄不明白商家出售的到底是什么，很快他的购买兴趣׃(x)消失D尽?/SPAN> 在这U情况下Q商能够期盼的最好情冉|Q用p开发的针对东欧市场的品会(x)有一些说p的当地居民或说英语的游客愿意购买?/SPAN> 管有些物g即便没有p手册或英语商标也能卖出去Q但是多数情况下Q缺本地化营销{略的品其收入不抵偿成本?/SPAN> 不幸的是Q决定是否将一个品本地化往往取决于对q种投资的成本估计以及它可能产生的利益（营收/销售额增加Q，而不是基?STRONG>本地化后的品会(x)拥有更多目标用户q样一个假设?/SPAN>
1.2什么是本地化？
正如前面讲到?/SPAN>Q?/SPAN>一品或服务本地?/SPAN>Q?/SPAN>是使其适应另一国家的需求和适用标准?/SPAN> 然而，Z完全理解“本地化”这个术语，我们首先需要理解本地化q程中的各个部分?/SPAN> 本地化过E：(x) 译所有的术语、羃略语、标志和单位Q简而言之，所有语a相关l成部分Q到特定国家的语aQ例如，当本地化软g的时候，我们需要翻译用L(fng)面、在U帮助系l、提C消息以及所有的文Q?/SPAN>
- 本地化图片：(x) M出现在项目资料中的图片都必须l过改编以符合目标文化和目标语言的标准?/SPAN> 囄中出现的所有字词都必须译?/SPAN> 所有的文化标志Q旗帜、衣服等{）也必L~?/SPAN> 典型的方法包括用新的囄替代已有的图片，例如Q当发送给译员的“标志”中呈现的是与目标区域不同肤色的人物、某特定国家的旗帜、具地方特色的公路指C牌、甚至特定国家气候下Z的特色蔬菜时Q所有这些都必须l过改编以适应目标文化?/SPAN>
- 语音本地化：(x) |站和各cȝ(sh)子出版物有一个共有的特定是语音元素来多。语x地化q个q程较之 HTML 文q类标准译需要花Ҏ(gu)多功夫?/SPAN> 即ɽ单到只有一个评论员声音的配x道也需要一个专业的录音室、一位评论员、一位音响工E师、一位导演（Ҏ(gu)富挑战的录音来说Q以及录韛_的数字声韛_理?/SPAN>
- 文化适应性：(x) 对于|站本地化来说文化适应性尤光要?/SPAN> 传递给|站访客的信息必M目标国家的文化精来译?/SPAN> |站的版面设计和l构{细节必能够吸引相x化的代表体?/SPAN> 如果一个网站仅仅经q翻译，但是没有本地化，生成的结果是一个用目标国家语言表述、但被大量的访客认ؓ(f)很做作的|站?/SPAN> 很明显，文化适应性的重要性依不同的主题而不同，但是它L有一些v码的重要性，q且无论如何都不应低估它的重要性?/SPAN> 有些问题恰恰是培训YӞ也就是我们所说的E-learningQ所Ҏ(gu)的?/SPAN> 例如Q所有的案例研究都必d该国文化相关?/SPAN> 文本中的玩笑和轶事也必须和目标文化一致?/SPAN> 资料中提出的问题必须与译文的其余部分内容相符Q提问的措辞方式也必M其同原文问题隑ֺ相当?/SPAN> 理解所有这些元素不仅可以你了解文章开始陈q的本地化的定义Q还可以了解光要性?/SPAN>
1.3 专业本地化过E的各个斚w
Z证本地化目的成?/SPAN>Q?/SPAN>专业的本地化q程应该是什么样子呢Q?/SPAN> 下面的特征构成了本地化过E?/SPAN>Q?/SPAN>
质量斚w
每篇译文都需要经q目标语为母语者的查?/SPAN> 译和审校后的译文还需要打印出来重新阅?/SPAN>Q?/SPAN>目的是找出在非全文查看下难以发现的错误?/SPAN> 认识到即使是最好的译员和审校也?x)犯错是很重要的?/SPAN>
- 功能试应该得到全面执行以识别用L(fng)面的所有缺陗?/SPAN>
- cM圎ͼ语音录制也应该有质量控制?/SPAN>
资源分配
- 资源分配包括团队内部的以及合作完成同一目的各团队之间的信息交换流E?/SPAN>Q?/SPAN>无论交换的信息是关于特定的术语、项目主要方面的保留意见、或目相关查询?/SPAN>
- 报告本地化工作的q展?/SPAN>
- 专业术语的应用?/SPAN>
- 保每个目都分配有利完工所必需的资源?/SPAN>
技术方?o:p>
如果使用的工具和技术对特定目或子合同已经_了，而用这些工具和技术的人对此也很熟(zhn)，那么每个同项目相关的人都能多睡几个安Eq且目也会(x)按时完成?/SPAN> 使用工具可以加快与下列各相关的部分工作的自动化Q?/SPAN>
- HTML 查；
- 用户界面试Q?/SPAN>
- .hlp格式帮助文试Q?/SPAN>
- .chm 格式帮助文档试?/SPAN>
优化工作及目程理
- 应做好工作计划以避免错误J殖的风险； 所有的d必须计划好进度以避免被其它Q务g误的风险Q?/SPAN>
- 只有资源分配合理才能实现目标Q?/SPAN>
- 计划目工作时应以在团队之间q_分配d量以及考虑l常出现的紧急情况ؓ(f)目标?/SPAN>
2. 专业的本地化程
在本地化中重要的是执行流E?/SPAN> 若项目方法正则一定会(x)开发出成功的品?/SPAN> 另一斚wQQ何在~少l致准备的前提下执行目的尝试都很可能对成本、交货期限或产品质量产生消极影响Q最p糕的时候对q几个方面全都有影响?/SPAN> 因此Q战略化Q聪明地战略化！ 以下是执行本地化目的流E：(x) 不同cd的本地化目的不同阶D需要强调不同的东西?/SPAN> Ҏ(gu)目本nҎ(gu)的性质Q有些阶D会(x)复杂些，有些阶段要简单些?/SPAN>
1. 分析和评估项目规?o:p>
q无疑是整个q程中最重要的一部分Q?/SPAN>因ؓ(f)它会(x)影响到后面的整个本地化过E?/SPAN> 错误地分析特定问题会(x)破坏整个目Q尤其会(x)增加成本或g镉K目执行过E，更别提对质量造成的消极媄响了?/SPAN> 衡量目的规模我们通过拟出一个所有文件中需要翻译的文本量的详细说明?/SPAN> 即在项目的q一早期阶段Q我们也必须意识到哪些文件包含需要翻译的部分?/SPAN> 全面评估目规模对后l的执行臛_重要Q因为它可以使我们ؓ(f)所有的lgQ例如语韟뀁图形或文本Q计划全部的阶段?/SPAN>
2. 目计划
目计划的目标是Q?/SPAN>
- 为单个团队和团队成员分配d和角Ԍ
- 要用的工具Q?/SPAN>
- 创徏目q度表；
- 开发逐上报程Q如果遇到额外的困难我们怎么做）Q?/SPAN>
- 开发信息流和信息交换流E?/SPAN>Q?/SPAN>译员、Y件工E师/E序员?/SPAN>DTP人员和语a专员之间Q；
- 在团队内部和合作开发同一目的不同团队（和公司）之间开发一个沟通模型；
- 为单个项目Q务设立最后完成期限；
- 为提交查询和透明的查询处理制度徏设标准表根{?/SPAN>
3. 开发支持资?o:p>
开发风格指南和译文指导手册Q这些文基于特定类型项目已有模板准备或专门为手头项目准备） 验证E序QQAQ? 开发够的验证本地化后资料Q包括译员指导手册）的流E对目最l质量至关重要?/SPAN> 很明昄一个例子是保译q后的所?HTML 资料中的链接都能正常工作?/SPAN> 如果q一d作ؓ(f)程中的一个步骤写了下来，我们可以保证不?x)将它遗漏?/SPAN>
4. 准备参考资?o:p>
参考资料指的是本地化项目相关h员，包括译员、审校、工E师和测试员可以获得的资料?/SPAN> 准备q类资料的通常原则如下Q?/SPAN> 参考资料越多越好?/SPAN> 为此Q我们可以用较老版本的文、帮助字W串或Y件测试?/SPAN> 昄Q如果相兌Y件是一个新产品Q就无法获得q些资料Q则可以使用实质上相似的资料Q例如相似的软g、类g题的文{）?/SPAN> 参考资料的开发应该抱着Ҏ(gu)获取以及览的想法?/SPAN> 例如Q创?00份参考文件是无用的，因ؓ(f)搜烦100个文件来解决目期间发现的一个问题太q耗时?/SPAN> 在这U情况下Q相x应该合qؓ(f)一个文档，q保留原文/文g的信息以作进一步参考?/SPAN> 例如Q用SDLX软gQ所有版本）整合的一个工hPerl脚本语言可以几个 HTML 文g_脓(chung)C个大文g中。由于翻译记忆库和术语库是译员最Ҏ(gu)获得的资?/SPAN>Q?/SPAN>它们也成为最重要的参考资料?/SPAN> 实际上，所有TM软g的一个特征就是将记忆库和术语库整合到译~辑环境中?/SPAN> q是使用该信息最快捷、最方便的方式?/SPAN> 我们只需选中文本Q点ȝ关的按键查看搜烦l果卛_?/SPAN>
5. 配置TM工具
正确配置TM工具的方法如?/SPAN>Q?/SPAN>
- 配置切分规则Q?/SPAN>
- 定义不需要翻译或~辑的文字或短语Q例如，专有名词Q?/SPAN>
6. 导入TM环境Q{换ؓ(f)TM软g的格式）
导入TM环境?yu)是我们想要翻译的文g转换成TM软g的格式?/SPAN>
7. 预翻译（可选）
对于某一文档Q例如帮助文件或软gQ，如果我们的翻译记忆库中有它的旧版本，我们可以实行预译?/SPAN> 预翻译可以减翻译成本，因ؓ(f)预翻译的文本只需作ؓ(f)目的一部分审校卛_?/SPAN>
8. 译
译是用TM~辑环境q行的，同时要遵守风格指南ƈ使用所有可获得的项目参考资料?/SPAN> TM工具通过提供快捷方式以及其它节约力_的功能增加了译员的出?/SPAN> 使用TM工具q会(x)降低译和审校的成本?/SPAN>
9. 审校
审校也需要在TM~辑环境中完成?/SPAN> 在审校过E中Q应该尽可能地预览目标文的格式Q有些TM软g有内|的预览功能Q而其它的必须导出才能以目标格式查看）?/SPAN> 审校也可以不断地在纸面上查看译文Q?/SPAN>查目标文的排版和布局?/SPAN> q在译排版复杂的文档或 HTML 面时很有用Q?/SPAN>例如Q?/SPAN>
审校?/SPAN>Q?/SPAN>我们使用以下功能来支持审校过E?/SPAN>Q?/SPAN>
- 术语查（该功能用项目的术语库来查翻译的文本与存储的术语是否一_(d)Q?/SPAN>
- 拼写查（q个功能查拼写，通常和流行的字处理Y件中的拼写检查操作相|
- 格式正确性检查（q个功能查源文本的格式是否正地转换到译文中Q它是在句段水^操作的）
10. 导出为目标格?o:p>
通常是简单的从TM软g的工作格式{换ؓ(f)目标格式?/SPAN> 在Trados软g中，当处?rtf文gӞq意味着仅仅去除为切分而插入的标记?/SPAN> 如果文存储的格式更助，q一操作可能D错误Q例如在Trados软g中操作FrameMaker文g时?/SPAN>
11. 功能试
在功能测试阶D，查最l翻译品?/SPAN> 本地化过E中q一阶段的重要性和长短主要取决于项目的cdQ?/SPAN> 软g本地化项目需要编译和试Q若是双字节文gQ?exe?dllQ在只需要测试?/SPAN> 对于|站本地化项目，我们查本地化后的站点所有链接功能是否完好、正，所有脚本语a是否q行正确Q以及包含语a特定l成的元素是否都本地化了?/SPAN>
12. DTP桌面排版Q?o:p>
对于使用?sh)子设计软gQ例如Adobe FrameMaker或QuarkPressQ制作的专业出版物，文的整体外观就昑־臛_重要?/SPAN> 主要注意的细节包括字体、整个版面设计（各自的位|和题注Q，插图、页眉和脚?/SPAN> ?sh)?/SPAN>文本的版面设计包含上面所有方面以及更多?/SPAN> 对于每种文g格式当然有其特定的问题?/SPAN>
13. 更新译记忆库和术语?o:p>
完成功能试q程中所有的更改后，有必要更新翻译记忆库和术语库?/SPAN> q将保未来同样的错误不?x)在怼的译文中出现?/SPAN> 我们q可以保证项目创建的参考资料是完全正确的?/SPAN>
3. 本地化支持技?o:p>
本章描述支持本地化过E的工具?/SPAN> q些工具可以用在M本地化或译目中，从简单的译一个文到本地化一个复杂的软g?/SPAN>
译记忆工具
q类工具支持译和审校（通过使用译记忆库） 要了解更多如何用翻译记忆库Q请查看本文最后的定义?/SPAN>
译工具可以用来Q?/SPAN>
- 译几乎M格式的文Ӟ
- l计一个或多个文g中的文本字数Q?/SPAN>
- 创徏和编辑翻译记忆库的内?/SPAN>
- 创徏和编辑术语库的内?/SPAN>
- 有很多翻译记忆工具可供选择Q它们包括：(x)
- Trados,
- SDLX,
- Déjà vu,
- Transit,
- WordFast,
- TransSuite 2000,
- MetaTexis.
软g本地化工?o:p>
q些应用E序用来译包含软glgQ例如用L(fng)面或E序提示信息Q的文g?/SPAN> q类应用E序包括Q?/SPAN>
- SDLinsight,
- Catalyst,
- Passolo.
q些cd的应用程序还配置有检验功能，x查翻译过后组件的正确性?/SPAN> 在很多情况下Q如果翻译过后的软g不包含诸如信息与对话框大不合适这c错误，q些功能用来查已l够了?/SPAN>
试工具
q些应用E序用来完成用户界面?/SPAN>RTF?/SPAN> HTML 帮助文档的测?/SPAN>Q?/SPAN>同时也包含网站测试的工具?/SPAN> 他们在功能测试阶D非常有用?/SPAN> 功能试阶段的v点常常是咨询q些E序生成的错误报告?/SPAN> 在很多情况下Q所有检查出来的问题可以通过应用E序中编辑得到解冟?/SPAN> 使用q些应用E序q不能省d本地化后应用E序的手动检验?/SPAN> q类应用E序包括Q?/SPAN>
- SDL Tool Proof,
- SDL Help QA,
- SDL HTMLQA.
囑Ş~辑?o:p>
q类软g用来~辑囑Ş文g?/SPAN> 最单的囑Ş本地化的例子大概是用一个L兰语的图形替换一个英语图形，但是文g格式是包含层的?/SPAN> 复杂囑Ş的本地化往往非常耗时Q而且不仅需要丰富的囑Ş~辑器的知识q要h艺术天赋?/SPAN> 当前市场上有的这cd用程序包括：(x)
- Adobe Illustrator,
- Adobe Photoshop,
- Corel Draw,
- Paint Shop Pro.
4. 目样例
下面是一个典型的本地化项目例子，包括本地化一个程序以及翻译文和帮助字符丌Ӏ?/SPAN> 基本的步骤如下：(x)
- 获取文g格式Q检查相关问题，
- 选择目工具Q?/SPAN>
- 目计划识别程Q定义项目团队成员的角色Q?/SPAN>
- 译和审校，
- 导出为目标格式以及功能测?/SPAN>
4.1 目q?o:p>
我们得到的这个本地化目如下Q?/SPAN>
- E序是用Delphi IDE生成?/SPAN>Q?/SPAN>
- 在线帮助?chm格式的（已编译的 HTML 文gQ，
- PDF文档是用Adobe FrameMaker创徏的?/SPAN> 注意Q?/SPAN> 软g本地化项目中很多时候，用户界面需要翻译的字数最?/SPAN> 但是Q从技术角度来Ԍ用户界面本地化却反而是最费劲的，׃试本地化后的界面是一个劳动密集的q程?/SPAN> 所有文除了翻译外Q还需要桌面排版，而在U帮助，除了译外，q需要功能测试?/SPAN>
4.2 评估目规模和需要用的~辑工具
必须使用合适的工具来评估项目及其子部分的规模：(x)
- 软g我们有以下选项Q?/SPAN>
- 如果有应用程序的源代码我们可以决定是否用TM软g或用本地化工具译Q注意：(x) q所有的TM软g都能够用来翻译源代码文gQ查阅程序手册确认）Q?/SPAN>
- 如果没有源代码而已~译文gQ?exeQ?dll……）已经本地化了Q必M用能够处理这些类型的文gq能够抽可译文本的Y件?/SPAN> q类软g包括SDL Insight、Passolo和Catalyst?/SPAN> 每种工具包括字数l计功能Q当所有文仉分析q后Q生成Y件中可译文本的字数统计?/SPAN> 在我们的目中，可译文本的d数是5,400字?/SPAN>
- .chm格式的在U帮助系l?/SPAN> 我们d?/SPAN>2,128?/SPAN> HTML 文gl成了Y件的在线帮助pȝ?/SPAN> 如果我们使用的工具内|有项目中所?HTML 文g合ƈZ个文件的功能Q我们现在就可以所有的文g导入到TM工具中?/SPAN> 完成导入后，目字数l计功能会(x)对可译文本进行字数统计?/SPAN> 假设我们使用的是SDLX软gQ?/SPAN> 所有的的 HTML 文g都被合ƈZ个大的文Ӟ之后q个文g被导入到SDLX Edit工具中?/SPAN> Log 文g提供所?,128?HTML 文g的字数统计?/SPAN> 我们q知道内部重复的数字Q例如所有文中重复的单词和短语?/SPAN> 因此Q我们知道真实的译字数l计?/SPAN>
- FrameMaker格式的文：(x)
首先.fm文g必须保存?mif格式Q这样它们才能导入到TM软g中?/SPAN> 然后他们必须转换Y件的~辑模块可以处理的文件格式?/SPAN> 大部分的q类工具都提供了一个同cd文g的批量导入功能，q把l果存在一个log文g中，q样即ɾ译了大量的文Q我们也可以立刻知道真实的翻译字数统计以及内部重复量?/SPAN>
评估目规模时容易出现的问题Q?o:p>
- 如果我们没有能够所?/SPAN> HTML 文g融合C个或多个大型文g的工?/SPAN>Q?/SPAN>那么我们׃(x)有大ȝ了?/SPAN> 逐个译2,128个文件是可行的，但是l对不是最优方案?/SPAN> 最优方案是我们自己创徏一个Y件?/SPAN> 可以使用Perl脚本语言或用Q何Y件开发环境甚至VB~辑器（或者更准确地说QVBAQ都能创建的单可执行文gQ集成在MS Office套g中，或者一个带有适用程的DLL库?/SPAN>
- 如果我们的本地化工具不能处理目中的某一特定文gcdQ?/SPAN>也会(x)出现问题?/SPAN> q种情况下必d义这cL件的讄?/SPAN>
4.3 目计划
目计划必须包括Q?/SPAN>
- 目每阶D（译、审校、测试）的时间表Q?/SPAN>
- 目q程中用的参考资料的说明Q?/SPAN>
- 目需要的所有必不可的文档Q例如译员、审校和工程师指C明书Q强调他们需要特别注意的问题Q?/SPAN>
- 关于目术语需要遵循的程Q?/SPAN>
- 如果出现问题的应急流E；
- 目相关信息的沟通安排；
- 提交目相关查询的标准格式；
- 本地化团队中每位成员在当前项目中的角色分配?/SPAN>
当然Q这些文中哪个是特定项目需要的、对它有帮助的，取决于项目的大小和复杂度?/SPAN> 对于大型的复杂项目，有必要将以上列出的所有文档尽可能以同U格式存储，q样在项目进行中Q它们能够即清晰、也有益?/SPAN> q样准备q些文所p的时间才花得倹{?/SPAN> 如果公司没有一个经验丰富的团队Q也不能分析目或准备项目计划，它可以用本地化机构提供的咨询服务?/SPAN> 本地化机构常ؓ(f)IT公司免费提供q类服务?/SPAN>
如果手上的项目庞大、技术上又很复杂Q通常二者伴随出玎ͼQ那么用这cL务当然是明智的?/SPAN> 投资本地化技术当然有利可图：(x) 降低译成本以及减少不能按时完成目的风险?/SPAN> 以下的参考资料在我们的项目样例中?x)用刎ͼ?x)
- 微Y术语表，包含了在微Y应用E序和操作系l中使用的术语；
- 一个从门户|站寚w得到?/SPAN>TM?/SPAN>Q?/SPAN>拥有和我们正在翻译的应用E序非常怼的功?/SPAN>Q?/SPAN>
- 多个和资产管理以及计划相关的术语库；
- 在项目中我们q会(x)用到因特|上覆盖相关主题领域的在U词典?/SPAN>
4.4 执行目
目执行时与提前准备好的计划怸致且Z为项目开发的指示q一点很重要?/SPAN> 当然Q在目q程中可能需要重新审阅某些项目，例如某一特别d的时间表?/SPAN>
译用户界面Q?o:p>
如果一个应用程序是用Delphi开发的Q最优方案是选择一Ƒ֏以处理这中文件格式的本地化工h译记忆工具?/SPAN> 译完成以后Q文本在相同环境下审校?/SPAN>
译帮助字符Ԍ(x)
如果使用的是SDLX软gQ例如：(x)
- HTML Utilities选项用来合ƈ所有的文g为六个大?/SPAN> HTML 文gQ?/SPAN>每一个包含大U?/SPAN>400个源文gQ?/SPAN>
- q些文g导入?/SPAN>SDLX软g?/SPAN>Q?/SPAN>?/SPAN> HTML 转ؓ(f).ITD文gQ?/SPAN>卛_以通过SDL Edit模块完成译的一U文件格?/SPAN>Q；
功能试Q?o:p>
软g~译完成后，必L查Y件中所有窗口的外观?/SPAN> 最好通过使用一个能够自动检查用L(fng)面错误（例如字符串太长或元素之间重叠Q的工具开始项目的q个阶段?/SPAN> 下一步，试员在指出具体软gҎ(gu)问题的指g手动试整个应用E序. 他们工作的结果通过标准的报告格式提交给技术团队来Ҏ(gu)q些问题?/SPAN>
译文档Q?o:p>
文可以使用M的翻译记忆Y件来译QFrameMaker格式非常行Q所有计机辅助译QCATQ工具都支持?/SPAN> 使用同一参考资料的审校也是在TM软g中进行的?/SPAN> 译验证的最后一步是查看全文Q最好是打印出来Q看看有没有错误或瑕c?/SPAN>
DTP桌面排版Q?o:p>
目的最后一个阶D|Ҏ(gu)进行最后的格式~排?/SPAN> 在我们的例子中，桌面排版必须使用FrameMaker软gQ由于源文g是用该Y件开发的?/SPAN> 要留意细节，例如Q?/SPAN>
- 使用同源文g怸致的字体Q?/SPAN>
- 插入本地化后的图形文Ӟ
- l护面的版面设计，q样文的外观才?x)和源文件相同?/SPAN>
目样例ȝQ?o:p>
以上描述的项目样例覆盖了本地化过E中可能遇到的情况和问题?/SPAN> q里有必要指出，当第一ơ处理某个特别文件格式时Q可能会(x)遇到与翻译这些文件相关的特定技术问题?/SPAN>
5. ȝ
本文档中提供的信息和例子有力地说明了本地化是一复杂的q程Q?/SPAN>需要用一的技术以及一个经验丰富、乐于献w的专业团队?/SPAN> 本地化团队不能(f)时成立，例如仅仅Z一个特定的目Q因会(x)D低质量的产品?/SPAN> 本地化团队成员必L看的参考资料数量巨大，l果使得本地化过E极时?/SPAN> 因此Q高质量的本地化服务当然不会(x)便宜Q但是却物有所倹{?/SPAN>
Translation Company’s Localization Challenges
1. Localization is the full adaptation of content for a local market
during the translation process
This document describes the localization process, as well as all the technologies, problems and methodological issues involved with localization. It should be used as a reference guide to the various processes, functions and areas of localization for anyone seeking to expand their knowledge over the subject. It is more of a factual document than that of opinion, and should be used as a study on the topic of localization. As far as most of the IT industry is concerned, the term “localization?means translation plus “some other things? In fact, translation is no more than one part of the entire localization jigsaw puzzle, sometimes not even the most important one. So what is localization? Though the definition varies somewhat throughout the industry, we believe that the following explanation describes localization fairly well. We will try to explain it in further detail later on in the document however, the “simplest?definition of localization is: the full adaptation of content for a local market during the translation process. Localization requires the understanding not only of specific local markets, but the understanding of actual content surrounding a given industry and/or culture. Localization and translation are codependent and because of that, they require much focus and strategy. As such, this document also attempts to familiarize the reader with issues related to the strategy of executing localization projects within IT companies. Furthermore, this text aims to answer the question that many people in IT frequently ask themselves: What resources and technologies do we need to carry out localization projects?
1.1 Who needs localization?
If a producer wishes to sell a product in a given market, he has to provide relevant product information in the language spoken in that country, regardless of whether his product is a complex ERP system worth $100,000 or a hair shampoo priced at PLN 3. Obviously, if a region specific translation is not available, all such products or items will loose consumer interest and encounter market entrance barriers. This can occur because anyone remotely interested in a purchase, would be immediately discouraged from buying the product if he were unable to read the instructions manual or even figure out what the item is. The best that the producer could hope for in such cases would be that the product marketed in English to an Eastern-European region, would find some English speaking residents of the region or English speaking tourists tempted to purchase it. Although it is true that some items could sell even without English manuals or English labels, it is hardly likely that revenues would exceed costs incurred in most cases where the product did not have a localized marketing campaign. Unfortunately decisions as to whether or not to localize a given product tend to be based on the estimated cost of such ventures and the benefits (increased revenues/sales) they would generate, instead of on the assumption that localized products will find a larger target audience.
1.2 What is localization?
As stated previously, when one localizes a product/service, he adapts it to the requirements and standards applicable in another country. However, in order to understand the term “localization?fully, we first need to understand all of the parts of the localization process. Localization process: Translation of all terms, abbreviations, symbols and units (in short, all language specific components) into the language of a given country (for example, when dealing with software, we translate the user interface, online help, messages that may be displayed, and all documentation).
- Localization of graphics: any graphics appearing in the project material must be adapted to conform to standards in the target culture and language. All words in graphic files must be translated. The same goes for all cultural symbols (flags, clothes, etc.). This typically involves replacing the existing graphics with new ones, e.g. when the “symbols?sent for translation represent people of different skin color from the target region, flags of a given country, characteristic road signs, or even vegetation characteristic for the climate prevailing in a given country, all of these have to be adapted to fit the target culture.
- Audio localization: web sites and all kinds of electronically published materials feature an increasing number of audio elements. Audio localization is a process that requires substantially more work compared to standard translation of an html document. Even a simple voice-over with the voice of a single commentator requires a professional recording studio, a commentator, a sound engineer, a director (for more challenging recordings) and digital sound processing after the recording.
- Cultural adaptation: This is particularly important for Web site localization. The message addressed to visitors to the site must be translated in the spirit of the culture of the target country. The details of the site’s layout and its composition must appeal to representatives of the relevant culture. If a Web site is translated without being localized, what is generated is a site in the language of the target country, which will be perceived as artificial by a great number of visitors. Obviously, the importance of cultural adaptation varies from subject to subject, but it is always of at least some significance and should not be underestimated at any cost. Coincidentally, certain issues are specific to training applications (what is known as e-learning). For example, all case studies must relate to the country’s culture. Jokes and anecdotes contained in the text must also be consistent with the target culture. Questions posed in the material must correspond to the rest of the translated content and be worded in such a way that the degree of difficulty is comparable to that of the questions featured in the original. Understanding all of these elements allows one to understand both the previously stated definition of localization as well as its importance.
1.3 Aspects of the professional localization process
What should the professional localization process be like to ensure the success of localization projects? The following features make up the localization process:
Quality orientation
A native speaker of the target language should check each translation. Following the translation and proofreading, the translated text must be re-read in hard copy to identify errors that are hard to detect without looking at the translation as a whole. It is important to realize that even the best translators and proofreaders can make mistakes.
- Functional testing should be performed thoroughly to identify all shortcomings of the user interface.
- Similarly, there should also be quality control for audio recordings.
Resources allocation
- This includes procedures for information exchange within the localization team and among various teams co-operating on the same project, whether relating to specific terminology, reservations about substantive aspects of the project, or project-related inquiries.
- Reporting on the progress of the localization work.
- Application of specific terminology.
- Ensuring that each projects has all the necessary resources devoted to successfully complete it.
Technology orientation
If tools and technologies adequate to the specific project or subcontract are used, and used by people familiar with them, then everyone involved will sleep easier and be sure that it will be wrapped up on time. Some of the tools that facilitate the automation of some parts of the work relate to:
- HTML validation,
- UI tests (user interface),
- tests for help files in .hlp format,
- tests for help files in .chm format,
Optimization of workflow and project procedure management
- The work should be planned so as to avoid the risk of error propagation. All tasks should be scheduled in such a way as to avoid the risk of being held up by other tasks.
- Objectives will not be achieved unless all resources are allocated rationally.
- The project work should be planned with the aim of distributing the workload equally among the teams involved and making allowances for the contingencies that often arise.
2. Professional localization procedure
What matters in localization is the execution procedure. The right approach to the project is bound to result in the development of a successful product. On the other hand, any attempt to execute the project without careful preparation is likely to have a negative impact on costs, deadlines or product quality, and in a worst-case scenario on all of them. So, strategize, and strategize smart! Below is a procedure for executing a localization project. Different emphasis should be placed on different stages for different kinds of localization projects. Depending on the specific nature of the projects, some stages will be more complex while other may be less complicated.
1. Analysis and assessment of the project’s size (Sizing)
This is undoubtedly the most important part of the entire process as it affects all the subsequent stages of the localization process. Mis-analysis of specific issues can jeopardize the whole project, substantially raise the costs involved or prolong the project execution process, not to mention the negative impact that it can have on quality. The size of the project is determined by drawing up a detailed specification of the amount of text to be translated for all the files. Even at this early stage of the project we have to be aware which files contain components for translation. A thorough assessment of the size of the project is crucial for its subsequent execution as it enables us to plan all the stages for all the components such as audio, graphics or text.
2. Project plan
The purpose of a project plan is to:
- allocate tasks and roles to individual teams and team members,
- establish the tools to be used,
- create a project schedule,
- develop escalation procedures (what do we do when faced with additional difficulties),
- develop procedures for information flow and exchange (between translators, software engineers/ programmers, DTP personnel and audio specialists)
- develop a communication model within and between the various teams (and firms) co-operating on the same project,
- set deadlines for completing individual project tasks,
- establish standard forms for submitting inquiries and transparent rules for processing them.
3. Development of support materials
Development of stylistic guidelines and instructions for translators (such documents can be prepared on the basis of existing templates for a given type of project or specifically for the project at hand). Verification procedures (QA): development of adequate procedures for verifying localized material (including instructions for translators) is crucial to the final quality of the project. For example something as obvious as making sure that all hyperlinks in the translated HTML material work properly. If this task is written down as a step in the procedure, we can be sure it won’t be forgotten.
4. Preparation of reference materials
Reference materials are materials available to everyone involved in the localization project, whether translators, proofreaders, engineers or testers. The general principles of preparing such materials are as follows: The more reference materials are prepared the better. To that end, we can use older versions of documents, help strings or software tests. Obviously, should such materials not be available, where the relevant software is a new product, materials similar in substance can be used (such as similar applications, documents on similar subjects, etc.), All reference materials should be developed with ease of access and browsing in mind. For example, creating 100 reference files will prove useless, as searching through 100 files to clear up a problem identified in the course of the project is too time-consuming. In this case, relevant documents should be combined into one, with information on source documents/files kept for further reference. For example, HTML files may be pasted into one large file using a tool incorporated in the SDLX software (all versions) or Perl script. Translation Memory translation and terminology databases are the most important reference materials as they are the easiest for translators to access. Virtually all TM applications feature a translation memory and terminology database integrated with the editing environment for translating. This is the fastest and most convenient way to use this information. We simply block text, and by clicking the relevant key view the search results.
5. TM tool configuration
The proper way to configure a TM tool is as follows:
- Configure the segmentation rules,
- Define words and phrases not to be translated or edited (e.g. proper names).
6. Importing into the TM environment (conversion into the TM application format)
Importing into the TM environment means converting the file we want to translate into the TM application format.
7. Pre-translation (Optional)
Pre-translation is performed if we have a translation memory containing the previous version of a document, for example, or help files or software. Pre-translation brings down the cost of translation, because text that is pre-translated only has to be proofed as part of the project.
8. Translation
The translation is executed using the Translation Memory editing environment, in accordance with stylistic guidelines and using all available reference materials for the project. The functionalities of TM tools increase translator output by providing shortcuts and other labor saving features. Use of TM tools also cuts the costs of both translation and proofreading.
9. Proofreading
Proofreading also needs to be carried out in the Translation Memory editing environment. During the proofreading process, the format of the target document should be previewed as far as possible (some TM applications have a built-in preview function, while in others files have to be exported to be viewed in the target format).The proofreader can also view the translated text on paper to see the formatting and layout of the target document on an on-going basis. This is useful when translating documents with complex formatting or HTML pages, for example:
When proofreading we use the following functions that are available to support the proofreading process:
- Terminology check (this function uses the project’s terminology base to check that the text has been translated consistently with the stored terminology),
- Spell check (this function checks spelling and usually operates in a similar way to spell checks in popular word processors).
- Formatting correctness check (this function checks that the formatting of the source text has been correctly transferred to the translation; it operates at segment level).
10. Exporting to the target format
This is usually a simple conversion from the working format of the TM application to the target format. In the Trados application and when working with .rtf files, this means simply removing markers inserted for segmentation purposes. In the case of documents saved in a more complex format, this operation may not be error-free, for example when working with FrameMaker files in the Trados application.
11. Functional testing
At the functional testing stage, the end-translated product is checked. The importance and length of this stage of the localization process is determined primarily by the type of the project: software localization projects require compilation and testing, or testing alone in the case of binary files (.exe and .dll). for Website localization projects, we check that all links function properly, all scripts on the site run correctly following localization, and all elements containing language-specific components have been localized.
12. DTP
For professional publications prepared using electronic design software, such as Adobe FrameMaker or QuarkPress, the appearance of the document as a whole is of crucial importance. Attention should be paid to details as fonts, the entire layout (respective location and captions), illustrations, headers and footers. The electronic layout of the text contains all these aspects and many more. There are certain specific issues typical for each file format.
13. Updating translation memory and terminology database
After all changes have been made in the course of functional testing, the translation memory and terminology databases have to be updated. This will ensure that the same mistakes are avoided in similar translations in the future. We can also be sure that the reference materials that can be created from the project will be error-free.
3. Localization support technology
This chapter describes the tools that support the localization process. These tools can be used for any localization or translation project, from a simple translation of a document to the localization of complex software.
Translation Memory tools
These types of tools support translation and proofreading (with the use of TM databases). To learn more about how to use translation memory databases, please consult the definitions at the end of the document.
Translation tools can be used to:
- translate files in virtually any format,
- do a word count of text to be translated in one or more files,
- create and edit the content of Translation Memory ?TM
- create and edit the content of Terminology Databases ?TDB There is a large number of translation applications available on the market. These include:
- Trados,
- SDLX,
- Déjà vu,
- Transit,
- WordFast,
- TransSuite 2000,
- MetaTexis.
Software localization tools
These are applications for translating files containing software components such as the user interface or application messages. Such applications include:
- SDLinsight,
- Catalyst,
- Passolo.
These types of applications are also equipped with functions for validating (checking the correctness of) translated components. In many cases, these functions are sufficient for checking that the translated software does not contain errors such as messages that do not fit in dialog boxes.
Tools for testing
These applications are used to carry out tests on the user interface, RTF or HTML help texts, and also contain tools for Web site testing. They are useful at the functional testing stage. The starting point for functional testing is usually the consultation of error reports generated by these applications. In most cases, all detected problems can be repaired by means of the editor in the application. Use of these applications does not render manual verification of the localized application redundant. Such applications include:
- SDL Tool Proof,
- SDL Help QA,
- SDL HTMLQA.
Graphic editors
This type of software is used for editing graphic files. The simplest example of graphics localization could be replacing the English caption with a Polish one in the format of the file that contains layers. Localization of complex graphics tends to be extremely time consuming and requires not only excellent knowledge of graphic editors but also artistic talent. Such applications currently available on the market include:
- Adobe Illustrator,
- Adobe Photoshop,
- Corel Draw,
- Paint Shop Pro.
4. Sample project
Below is an example of a typical localization project, which includes the localization of a program as well as the translation of the documentation and help strings. The basic steps are as follows:
- File types are obtained and specific related issues are examined,
- Selection of project tools,
- Project plan identifying the procedures and defining the roles of each member of the project team,
- Translation and proofreading,
- Export to the target format and functionality tests.
4.1 The project in brief
The localization project we obtained was as follows:
- the program was created using the Delphi IDE,
- the online help is in .chm format (compiled html files),
- the PDF documentation was created in Adobe FrameMaker. Note: many times in software localization projects the user interface has the lowest word count for translation. Contrastingly, the UI localization is the most demanding task from a technical point of view, as testing the localized interface is usually a labor-intensive process. All documentation in addition to being translated will require DTP, while online help, in addition to being translated, will also have to be functionality tested.
4.2 Evaluation of project size and adaptation of tools to be used
Suitable tools must be used to evaluate the size of the project and its subparts:
- For software we have the following options:
- if the source code of the application is available we can decide whether to translate the software in a TM application or using a localization tool (note: not all TM applications can be used to translate source code files; consult the program manual to check),
- if the source code is not available and compiled files (.exe, .dll, ? have to be localized, an application must be used that can handle these types of files and will be able to extract translatable text. Applications of this type include SDL Insight, Passolo and Catalyst. Each of these tools includes a word count functionality, which, after all files have been analyzed, generates the word count of translatable text in the software. In our project, the total word count of translatable text is 5,400.
- Online help in .chm format We have a total of 2,128 HTML files that make up the application’s online help. If we are using a tool with a built-in functionality for merging all the HTML files in the project into one, we can now import all the files into the TM tool. After importing them into the TM application, the project word count functionality will give a word count of translatable text. Let’s assume that we are using the SDLX application: all the small HTML files are merged into one large file, after which the file is imported into the SDLX Edit Tool. The log file provides a word count for all 2,128 HTML files. We also know the number of internal repetitions, i.e. words and phrases that are repeated in all the documents. Thus we know the actual translation word count.
- Documentation in the FrameMaker format:
First the .fm files must be saved in .mif format so that they can be imported into the TM application. Then they must be converted to a file format that the application’s editor module can handle. Most tools of this type provide a batch import functionality for files of the same type and save the results into a log file, so that even if large numbers of documents are to be translated, we immediately know the actual translation word count and the number of internal repetitions.
Problems that can arise when evaluating the size of the project:
- If we do not have an application that can fuse all the HTML files into one or more larger files, then we have a serious problem. Translating 2,128 files one by one is feasible, but it is certainly not the optimum solution. The answer is to create an application ourselves. This can be a PERL script, for example, or a simple executable that can be created using any software development environment or even the visual basic editor (or, more accurately, VBA ?Visual Basic for Applications) integrated with the Microsoft Office suite or a DLL library with the applicable procedures.
- Problems can also arise with specific file types if our localization tool does not handle a particular file type within the project. In this case all settings for files of this type must be defined.
4.3 Project plan
The project plan must include:
- the time frame for each stage of the project (translation, proofreading, testing),
- specification of reference materials to be used during the project,
- all necessary documents needed for the project, such as instructions for translators, proofreaders and engineers, emphasizing issues to which particular attention must be paid,
- procedures to be followed with regard to project terminology,
- contingency procedures in case of problems,
- a communication arrangement for project related information,
- standard forms for submitting project related inquiries,
- assignment of roles for each member of the localization team for the specific project at hand.
Which of these documents will be required and helpful in a specific project depends, of course, on its size and complexity. For large, complex projects it is worth preparing all the documents listed above in as simple a format as possible, so that they are clear and helpful when the project is underway. Then the time devoted to the preparation of these documents will be time well spent. If the company does not have an experienced team and is not in a position to analyze the project or prepare a project plan, it can use the consulting services of a localization agency. Localization agencies often provide these services to IT companies free of charge.
It is certainly advisable to use them if the project in hand is large and technically complex (both often go together). Investing into localization expertise will certainly be profitable: lower costs of the translation and avoiding the risk of failing to keep a project deadline. The following reference materials will be used in our sample project:
- the Microsoft glossary, containing terminology used in Microsoft applications and operating systems,
- a TM database aligned from translations of a portal with a functionality very similar to the application we are translating,
- databases of terminology related to asset management and planning,
- during the project we will also be using online dictionaries available on the Internet covering related subject areas.
4.4 Execution of project
It is important that the project be carried out in accordance with the plan prepared in advance and on the basis of the instructions developed for the project. During the project the need may, of course, arise to review some of these items, such as the time frame for a particular task.
Translation of the user interface:
If an application is developed in Borland Delphi, the optimum solution is to use either a localization tool or a TM tool capable of handling this file format. After translation, the text is proofread in the same environment.
Translation of help strings:
If the SDLX application is used, for example:
- the HTML Utilities option is used to merge all the files into six large HTML files, containing approximately 400 source files each,
- these files are imported into the SDLX application (converted from HTML into .ITD, i.e. a file format in which the translations can be carried out using the SDL Edit module)
Functionality tests:
Once the application is compiled, the appearance of all the windows in the application must be checked. It is best to begin this stage of the project by using a tool that can automatically detect UI faults, such as strings that are too long or elements that overlap. Next, the entire application is manually tested by testers with instructions that point to issues specific to a particular application. The results of their work are forwarded in standard report format to the technical teams that rectify any problems.
Translation of documentation:
Documentation can be translated with the use of any Translation Memory application; FrameMaker format is sufficiently popular and is supported by all Computer Aided Translation tools. Proofreading, using the same reference materials, is also done in the TM application. The final step of verification of the translation is a review of the whole translation (preferably in hard copy) to spot errors or defects.
DTP:
The last stage of the project is the final formatting of the documentation. In our example, the FrameMaker application must be used for DTP, as the original documents were developed in this format. Attention must be paid to all details, such as:
- using fonts that correspond to those used in the source document,
- inserting localized image files,
- maintaining page layout so that the appearance of the document is the same as the original.
Summary of the sample project:
The sample project described above covers the issues and problems that can be encountered during localization. It is important to point out here that when handling a particular file format for the first time, specific technical problems connected with translating these files are to be expected.
5. Conclusions
The information and examples provided in this document leave no doubt that localization is a complex process that calls for the use of state-of-the-art technologies and a team of experienced and devoted specialists. Localization teams cannot be set up ad hoc, for example for a particular project only, as that will lead to low quality outcomes. The volume of reference materials that members of localization teams must review is truly huge, resulting often in a very time consuming process. As such, quality localization services are certainly not cheap, but well worth the money spent.
SourceQhttp://www.argostranslations.com/articles/localization_challenges/