XLIFF

XLIFF是由軟體開發商、本地化服務提供商、本地化工具提供商等團體共同倡議和設計，由OASIS標準組織發布的用於本地化數據交換的格式標準。它基於XML技術制定軟體資源檔案格式的轉換規格，其目的在於提高軟體的本地化作業效率。

基本介紹

• 中文名：XML本地化數據交換格式
• 外文名：XML Localization Interchange File Format
• 目標：制定可擴展的多語言本地化數據
• 基於：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 標記中包含本地代碼。 和 元素用於封裝成對代碼； 元素用於任何成對代碼的孤立部分；而 元素用於任何其他獨立代碼