更新时间：2022-03-21 18:19
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文档可以包括一个或多个部分，每个部分被包含在一个对应的元素内。每个元素由元素和元素组成，元素包括元素的元数据（meta-data），例如，项目数据（联系信息、项目阶段、引用对象的指针和框架文件的信息等）。元素包括从元素中抽取的可翻译的数据，它们是XLIFF文件的主要组成元素。这些可以本地化的数据包含在多个元素中，而每一个元素包括由和 成对组成的元素中。XLIFF 文件可以描述成翻译单元（trans-unit）的集合,每个翻译单元包含从原始文档中抽取的一个句子或者一个段落，原始文本放在 元素中，译员需要用适当的翻译文本填充 元素。多个元素可以成组地包含在元素中。
除此之外，XLIFF通过元素保存文件不同处理阶段的信息， 元素包含有关工具、日期、用户等等的信息，以便在项目进行过程中为不同用户提供强大的预翻译和版本管理接口，每个元素可以包含属性（attribute），并与特定阶段相关联。由机器翻译（MT）、计算机辅助翻译（CAT）和以前项目中的继承下来的翻译结果可以使用元素增加到元素中。如果 元素中的翻译是正确的，则译员必须接受建议的文本。二进制数据（例如图像、鼠标指针、图标等）包含在元素中，该元素包含 和 元素，对象类型在 元素的 mime-type 属性中指定。元素被包含在相关联的元素中。二进制数据对象可以直接嵌入在 XLIFF 文档中，也可以采用引用外部文件的方式，XLIFF 甚至可以进行适当的调用，以选择编辑对象所需的相关应用程序。
关于内嵌（Inline）代码，XLIFF支持两个主要的标记机制，以便在 和 元素中使用内嵌代码：封装机制和取代机制。封装机制是在 XLIFF 标记中包含本地代码。 和 元素用于封装成对代码； 元素用于任何成对代码的孤立部分；而 元素用于任何其他独立代码