XLIFF

本地化的困局

軟件開發技術的不斷髮展，軟件規模和軟件功能的不斷增強，不但增加了本地化處理過程的複雜程度，而且降低了本地化工程的處理效率，對軟件的本地化過程帶來嚴峻挑戰。

首先，多種資源文件格式增加了處理難度。本地化行業人士面對如此眾多的資源文件格式常常陷入迷茫的困局。對於一個大型軟件本地化項目，需要進行本地化的文件格式多達十幾種，其中大部分屬於通用格式文件，例如，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 標記中包含本地代碼。 和 元素用於封裝成對代碼； 元素用於任何成對代碼的孤立部分；而 元素用於任何其他獨立代碼