[提要]
- 本地化的困局
- 解困之道
- XLIFF结构解读
- XLIFF为本地化带来了什么
- 最佳实践
XLIFF是由软件开发商、本地化服务提供商、本地化工具提供商等团体共同倡议和设计，由OASIS标准组织发布的用于本地化数据交换的格式标准。它基于XML技术制定软件资源文件格式的转换规格，其目的在于提高软件的本地化作业效率。
本地化的困局
软件开发技术的不断发展，软件规模和软件功能的不断增强，不但增加了本地化处理过程的复杂程度，而且降低了本地化工程的处理效率，对软件的本地化过程带来严峻挑战。
首先，多种资源文件格式增加了处理难度。本地化行业人士面对如此众多的资源文件格式常常陷入迷茫的困局。对于一个大型软件本地化项目，需要进行本地化的文件格式多达十几种，其中大部分属于通用格式文件，例如，Java 资源文件（.Properties），Windows 资源文件（.RC），HTML 文件，XML文件等，但是也有一些属于软件开发商专有的文件类型，对专有类型的文件的本地化是经常困扰本地化人士的难题。
其次，软件数据交换成为瓶颈。软件本地化过程需要处理的文件，经常需要经过多次传递和格式转换处理，而每次传递过程产生的文件数据格式都不相同，为了本地化过程管理，要保证数据可以存储和跟踪不同传递阶段的内容发生了哪些改变。随着本地化工具的日益普及及其在大范围内的普遍应用，为了充分利用已经本地化的文件内容，提高处理效率，保证一致性，数据互可交换的需求随之产生。由于缺少行业文件数据标准，不同软件开发商和本地化工具处理后的数据缺乏兼容性，造成重用以前翻译过的内容比较困难。
再次，软件版本控制成为难题。由于软件市场的竞争日益激烈，源语言软件和本地化的软件发布间隔日益缩短（甚至同步发布），因此，全球化软件的开发和本地化过程是同步实现的，即边开发边进行本地化。由于源软件不断推出中间版本，本地化服务商需要保证得到和实现最新版本的文件进行本地化，因此软件版本控制成为一个重要内容。
最后，本地化参与者核心竞争力受到制约。缺乏文件数据格式的统一标准，也使软件开发商和本地化工具提供商深受影响。对于软件开发商他们的核心竞争力在于不断实现功能强大的专业软件，但是由于缺乏文件交换的标准，他们经常要为自己开发的新格式文件定制开发解析工具或过滤工具，并且要培训本地化服务商关于如何使用这些专用工具。本地化工具提供商的核心竞争力在于不断提供高效、方便的本地化工具，但是面对众多的资源文件格式，不得不耗费不少时间提供文件解析功能，需要开发各种插件、宏、过滤器处理特殊类型的资源文件。
很显然，在本地化行业不断发展的今天，缺少本地化过程文件数据交换格式的标准已经成为行业短板，并且困扰着整个本地化过程，已经阻碍了整个本地化行业的继续发展。
解困之道
如果将1990年“本地化行业标准协会(LISA)”成立，标志着软件本地化行业的正式形成，那么本地化行业至今已经走过了十多个念头，从时间跨度看这显然是个新兴的行业。
中国有句谚语：“不立规矩，难成方圆”。在当今信息时代，行业标准成为推动行业健康发展的持久动力。本地化行业的不成熟导致了标准的缺失，而标准的缺失又阻碍了这个行业的更快发展。特别是随着XML等软件规范的出现，为Web应用提供了巨大空间，而全球一体化的发展趋势促进了软件全球化和软件本地化的进一步发展。
市场需求的推动永远是新技术、新标准产生的直接动力。为了破解多格式文件本地化处理的困局，来自本地化行业相关团体的专业之士，为着共同的目标，聚集在一起，讨论和制定了本地化数据交换的标准，由此直接导致了了XLIFF标准的诞生。
公元2000年10月，来自Oracle，Novell，Sun和IBM/Lotus公司的代表聚在一起，成立了一个松散的“数据定义组”（Data Definition Group），后来改为正式的名称XLIFF（XML Localization Interchange File Format），开始定义本地化数据交换的规格。随后Alchemy Software Development, Moravia IT, RWS Group 和Lionbridge等公司也陆续加入到讨论组中。
讨论组的工作目标是制定可扩展的多语言本地化数据交换的规范，允许任何软件开发商根据该规范创建单一数据交换格式的文件，这些单一数据交换格式的文件能够向任何本地化服务商提交，并且能够被本地化服务商易于理解和有效处理。因此，制定的格式规范必须不依赖于任何特定工具软件，具有标准化和支持本地化处理的全部过程。另外，规范必须完全支持软件通用数据格式，并且具有足够的开放性，以便本地化专业工具开发商开发各种专有数据格式的实现程序。
最开始的时候这个小组使用Yahoo! eGroup展开讨论。为了吸引更多的人士参与，这个网络讨论组向任何人自由开放，但是只有受邀请者才能参加会议讨论。经过小组成员的努力，他们于2001年5月发布了XLIFF的第一版草稿规范。
为了增强团体结构和工作流程的集中性，该小组于2001年秋决定寻找一个具有良好组织结构的标准机构，以便更系统的制定本地化数据交换的标准。经过与OASIS （Organization for the Advancement of Structured Information Standards），W3C（World Wide Web Consortium）和LISA（Localization Industry Standard Association）等组织的接触和比较，XLIFF小组终于在2001年12月选定OASIS作为正式制定和发布XLIFF标准的机构。OASIS致力于XML的研究，XLIFF小组的很多公司也都是OASIS的成员，而且OASIS也乐意提供全系列的支持服务，双方的合作一拍即合。
随后OASIS成立了专门的XLIFF技术委员会（XLIFF TC），并于2002年一月召开了第一次技术会议。XLIFF技术委员会随后审阅了XLIFF 1.0的规格文件，于2002年4月15日批准和发布了XLIFF 1.0标准。
在XLIFF 1.0标准发布后，XLIFF技术委员会并没有停止研究的步伐，他们继续在1.0版本的基础上进行增强和修正，并于2003 年 10 月 31 日发布了XLIFF 1.1标准。
XLIFF标准将需要本地化的文本从繁杂的文件格式中分离出来，相同的源文件可以使用多种不同的工具软件进行本地化处理，而且可以在处理的过程中添加一些注释等的文字，存储有助于本地化处理的数据信息。XLIFF标准的发布，使得软件本地化数据交换的格式趋向统一，使很多本地化工程师从选择、学习和使用众多的定制工具的困境中解脱出来。
XLIFF结构解读
XLIFF 是一种存储抽取的文本并且在本地化多个处理过程进行数据传递的格式规范。它的基本原理是从源文件中抽取与本地化相关的数据，并对这些抽取出来的需要本地化的数据进行本地化处理，然后再与源文件中不需要本地化的数据合并成与源文件相同的格式文件。
采用XLIFF标准后，软件开发商利用过滤器将原来的文件转换为XLIFF格式，将其交给本地化服务商进行本地化的翻译，收到翻译过的文件以后，再使用同样的过滤器恢复为原来的文件格式。
源文件经过抽取后，那些不需要本地化的数据存放在“框架（Skeleton）”文件中，在 XILFF 标准中，框架文件可以以独立的文件存在，以保证不会因翻译过程而被改动。当然，在实际的操作过程中，为简便起见，也经常将框架文件直接存储在 XLIFF 文档中。如果将框架文件存储在文档中，一般可简单地采用 CDATA 部分来封装它的主体；或者如果框架文件是二进制的，则可以采用 Base64 编码将其插入到文档中。
XLIFF 基于 OpenTag 所定义的原则（OpenTag 是一个更早的用于抽取文本的 XML 应用），同时借用了 OpenTag 的一些标记。此外，它还增加了一些创新特性，比如项目信息、预翻译及历史记录、版本管理、二进制对象等。相对于OpenTag而言，XLIFF更为精确（不允许以不同方式定义同样的内容），也具有更好的互操作性。
从XLIFF的文档结构分析，XLIFF基于XML规范，以“XML”声明开始。XML后是XML文档自身，包括在<xliff> 元素中。XLIFF文档可以包括一个或多个部分，每个部分被包含在一个对应的<file>元素内。每个<file>元素由<header>元素和<body>元素组成，<header>元素包括<file>元素的元数据（meta-data），例如，项目数据（联系信息、项目阶段、引用对象的指针和框架文件的信息等）。<body>元素包括从<file>元素中抽取的可翻译的数据，它们是XLIFF文件的主要组成元素。这些可以本地化的数据包含在多个<trans-unit>元素中，而每一个<trans-unit>元素包括由<source>和<target> 成对组成的元素中。XLIFF 文件可以描述成翻译单元（trans-unit）的集合,每个翻译单元包含从原始文档中抽取的一个句子或者一个段落，原始文本放在 <source> 元素中，译员需要用适当的翻译文本填充 <target> 元素。多个<trans-unit>元素可以成组地包含在<group>元素中。
除此之外，
XLIFF通过<phase>元素保存文件不同处理阶段的信息，<phase> 元素包含有关工具、日期、用户等等的信息，以便在项目进行过程中为不同用户提供强大的预翻译和版本管理接口，每个<target>元素可以包含<phase-name>属性（attribute），并与特定阶段相关联。由机器翻译（MT）、计算机辅助翻译（CAT）和以前项目中的继承下来的翻译结果可以使用<alt-trans>元素增加到<trans-unit>元素中。如果 <alt-trans> 元素中的翻译是正确的，则译员必须接受建议的文本。二进制数据（例如图像、鼠标指针、图标等）包含在<bin-unit>元素中，该元素包含 <bin-source> 和 <bin-target> 元素，对象类型在 <bin-unit> 元素的 mime-type 属性中指定。<bin-unit>元素被包含在相关联的<trans-unit>元素中。二进制数据对象可以直接嵌入在
XLIFF 文档中，也可以采用引用外部文件的方式，
XLIFF 甚至可以进行适当的调用，以选择编辑对象所需的相关应用程序。
关于内嵌（Inline）代码，
XLIFF支持两个主要的标记机制，以便在 <source> 和 <target> 元素中使用内嵌代码：封装机制和取代机制。封装机制是在
XLIFF 标记中包含本地代码。<bpt> 和 <ept> 元素用于封装成对代码；<it> 元素用于任何成对代码的孤立部分；而 <ph> 元素用于任何其他独立代码。如果在封装的本地代码序列中含有任何文本（例如，XHTML 中 <img> 元素中的 alt 属性的文本），则可以使用 <sub> 元素分隔这些文本。取代机制将每个本地代码抽取到框架文件中，然后使用占位符元素加以替换。<g> 替换成对代码，而 <x/> 标记任何独立代码。此外，<bx/> 和 <ex/> 为交叠且无法用 <g> 元素标记的成对代。
XLIFF为本地化带来了什么？
随着软件本地化的发展，缺少数据交换的标准成为阻碍本地化流程和效率的突出问题。由本地化行业的各界人士（软件开发商、本地化服务商和工具提供商等）发起和制定的基于XML规范的XLIFF标准，确实为本地化行业带来了革命性变革。
XLIFF为软件开发商和本地化服务商增强了多种本地化工具之间的互操作性，简化了本地化流程，帮助确定可能导致本地化项目推迟和增加成本的特定问题，从而有助于提高本地化效率，降低本地化处理成本。
具体而言，XLIFF对于软件开发商、本地化服务商和工具提供商都带来了众多益处。
从软件开发商的角度分析，采用XLIFF标准，首先可以减少处理专有文件格式的本地化服务商的依赖。这是因为XLIFF是行业标准格式，不依赖于具体的本地化服务商，而仅要求本地化服务商具有XLIFF处理能力即可，因此，软件开发商可以减少对本地化服务商的培训和技术支持要求；其次，降低了处理各种本地化文件类型的复杂程度。软件开发商只需要将不同类型的源文件整体打包生成一个或几个单一的XLIFF格式的项目文件，其中可以包含位图、图标等二进制对象，然后发送给本地化服务商；再次，方便控制本地化内容。将需要本地化的数据从源文件中完全过滤出来，对于某些需要特殊本地化处理的数据添加标示和注释，还可以随时跟踪数据在不同的处理阶段的改变情况，提高对本地化数据处理的控制能力。
对本地化服务商而言，XLIFF 将源文件类型的格式转变任务从本地化服务商转移给软件开发商，本地化服务商只要选择熟悉的少数本地化工具对同一个格式的XLIFF文件进行处理即可，从而降低了本地化工程中处理不同类型源文件的复杂程度。译者可以集中经历进行文本翻译，本地化工程师只要获得源软件的格式转换器就可以容易的处理XLIFF标准格式文件，而不需要关心所处理的文件原来是什么格式的。另外，XLIFF可以使用标识（tag）和属性（attribute）标明文件本地化过程中比较重要的部分，例如，添加注释、锁定某些不需要本地化的数据，可以跟踪不同处理过程中特定数据的改变和翻译状态，提供本地化处理过程的数据字数统计和其他度量。XLIFF通过本地化全部过程的支持，可以提高本地化质量。最后，由于XLIFF基于XML的开放标准，可以方便的找到一些生成XLIFF格式的开源工具软件。
作为本地化工具提供商，XLIFF为其提供了一个通用的平台进行开发，从开发多种文件格式的过滤和解析工具的复杂耗时的工作中解放出来，从而将主要精力投身于本地化过程中核心功能特征的开发，例如增强资源文件的重复利用，检查和验证本地化的数据。有助于它们集中精力提供功能更强、操作更方便、类型更多的本地化工具；其次，随着XLIFF在本地化行业的推广和应用，对能够处理XLIFF格式的专业本地化工具提出了更大的需要，增加了本地化工具开发商的发展空间，从而扩大市场份额；再次，由于XLIFF是本地化行业的数据交换标准，定义了本地化过程中各个属性（例如，注释、锁定、源和目标段等），从而降低了解析这些内容的技术难度；最后，由于XLIFF文件包含了全部需要本地化的数据，因此采用专业本地化工具可以保证对所有需要本地化的数据进行处理，并且可以充分继承XML规范的其他优点，例如，支持不同格式的编码、平台无关性、可以使用已经开发的解析工具和浏览器等。
XLIFF之所以能够给本地化带来如此有益的功能，主要在于它是由本地化行业的专家结合本地化流程的需要量身定制的行业标准，另外XLIFF基于公共规范XML设计，具有简便性、跨平台、扩展性、国际化和集成Web服务等特征。
最佳实践
作为本地化行业的多格式文件处理的行业标准，自从XLIFF 1.0版本发布后，已经引起本地化行业的关注，XLIFF成为本地化行业会议的案例研讨和工具演示的主题，并且在本地化项目中进行了很多卓有成效的应用，越来越多的本地化专业工具提供XLIFF的支持能力（例如，Alchemy Software,PASS Engineering等），更多的软件开发商（例如，IBM,Sun等）和本地化服务商（例如，Bowne Global Solutions等）开始采用XLIFF 1.1标准。
从这些不同本地化工具对XLIFF支持的方式和范围上看，主要分为两类：第一类是对XLIFF的内在集成支持，第二类是对XML格式的内在支持。基于XLIFF的内在集成支持的本地化工具可以正确识别XLIFF的各个元素和属性，处理全部XLIFF的数据，这是支持XLIFF标准的最佳方式；基于XML解析支持的工具，通过正确解析XML规范的元素提供对XLIFF的支持，采用这种方式，虽然可以处理需要本地化的数据（例如，<target>元素），但是不能提供对XLIFF的完整解析和支持，因此不能应用XLIFF的许多优点，是一种不彻底的支持方式。
采用XLIFF格式进行本地化的一般过程是：软件开发商将需要本地化的各种数据格式文件，利用软件开发商开发的转换工具转化成XLIFF格式文件，然后传递给本地化服务商处理，本地化服务商利用支持XLIFF格式的专用本地化工具进行本地化处理，然后将完成的内容以XLIFF的格式提交给软件开发商，软件开发商再利用转换工具转化将XLIFF文件还原为原始数据格式。在本地化的处理过程中，如果更新或添加了任何新的数据格式，软件开发商需要在原来的XLIFF文件基础上重新生成XLIFF文件，然后再次传递给本地化服务商。
此处列举IBM和Bowne Global Solutions（保捷环球）两家公司互相协作采用XLIFF 1.0实现Lotus Domino/Notes 软件本地化的成功案例。IBM开发了名为“Lotus Domino Global WorkBench (DGW)”的管理翻译的Domino/Notes的工具；而Bowne Global Solutions公司采用其在线本地化解决方案Elcano，它通过“管道（pipeline）”技术实现在线向专业的翻译人员分配翻译任务。
具体实现过程是：IBM利用DGW创建项目词汇表（glossary），确定需要本地化的内容，结合项目词汇表，将本地化的内容转换成符合XLIFF标准的文件格式，然后使用SOAP技术发送至Elcano WSDL文档。发送者和其他信息与需要本地化的内容可以被自动识别出来。Bowne Global Solutions利用Web服务将在Elcano中完成的翻译提交到IBM的DGW中，当DGW收到Elcano发送过来的已经翻译的XLIFF文件后，根据翻译内容更新项目词汇表，最后利用DGW将XLIFF格式再转换还原成最初的文件格式，进行本地化的编译等后续处理。
总之，XLIFF为本地化行业提供了单一本地化文件的数据交换格式，制订了本地化行业标准规范，有助于提高本地化工程处理效率，降低了本地化成本。但是由于软件本地化行业仍然很不成熟，很多本地化技术和流程等问题需要优化，加之XLIFF新标准刚刚推出不长时间，还需要在本地化项目中更多的实践、检验和更新。
上一篇：
发表、查看更多关于该信息的评论
将本信息发给好友
打印本页