Page 2 of 4   « previous page   next page »

Solution: XLIFF provides structures to track workflow phases.

Challenge: Lack of standard resource or content container - Developing tools to improve the localization process involves commitments in resources, testing, and deployment. Frequent retooling to keep up with modifications to proprietary resource formats will adversely impact schedules and quality levels of both the localization tool and the localized content. Developing a custom localization tool or acquiring an off-the-shelf tool that is compliant with a standard, localizable resources container such as XLIFF mitigates project risks and reduces potential vendor lock-in. The existing localization standards supported very specific types of localization related data. For example the Localization Industry Standards Association (LISA) OSCAR standards group defined TMX for Translation Memory Exchange, and TBX for Term Base Exchange, but these XML vocabularies aren't used to store resources to be translated. Another de facto standard, Opentag, an XML-based container for localizable content, provided inspiration to the founders of XLIFF, but it failed to provide the hierarchical structure required for describing groups of related resources such as dialog boxes and menus, and lacked project and workflow management metadata.

Solution: XLIFF provides a standard XML-based hierarchical container for localizable data and related metadata that is compatible with existing localization industry standards TMX and TBX.

The XLIFF Technical Committee (TC) succinctly summarizes the approach to addressing these localization challenges in its charter: "The purpose of the OASIS XLIFF TC is to define, through XML vocabularies, an extensible specification for the interchange of localization information. The specification will provide the ability to mark up and capture localizable data and interoperate with different processes or phases without loss of information. The vocabularies will be tool-neutral, support the localization-related aspects of internationalization, and the entire localization process. The vocabularies will support common software and content data formats. The specification will provide an extensibility mechanism to allow the development of tools compatible with an implementer's own proprietary data formats and workflow requirements."

XLIFF Architecture
XLIFF is an XML vocabulary for exchanging localization related data. This standard was designed to take full advantage of XML's technical features, yet fit comfortably into the typical localization process. The architecture of XLIFF is designed so that it can be used in a number of ways:

• Extract only the localizable content within the original files to XLIFF, leaving untranslatable content in a skeleton file
• Transform the entire resource file to an XLIFF file

See Figure 1

XSL Transformation
Today XML is more widely adopted, so XSL can be used to transform an XML file directly into an XLIFF container. This process is illustrated in Figure 2.

In this model, an entire XML document is transformed into XLIFF, translated, and transformed back to its original structure. An open source tool is available for transforming XML into XLIFF and back again, and may be downloaded from https://sourceforge.net/projects/xliffroundtrip/.

Structure of XLIFF
Listing 2 is an example of a simple XLIFF file. This document does not intend to describe in detail all of the components that make up an XLIFF file. For further information on this, refer to the XLIFF specification from OASIS. The current specification is available at www.oasis-open.org/committees/xliff/documents/ cs-xliff-core-1.1-20031031.htm.

XLIFF files are bilingual. There is only one source language and one target language. This makes the overall model much simpler when you consider all of the additional features the format provides, such as pretranslation, version tracking, etc. It also avoids the problem that a multilingual file would have where different versions are localized by different translators at the same time.

File Element
Each file element corresponds to a real or virtual file from the source material. By virtual file, I mean that it could correspond to part of a database. An XLIFF file must contain at least one but can contain any number of file elements. It would be possible for a single XLIFF document to contain all of the resource files for an entire software application, each corresponding to its individual file element. This approach should take into consideration the effect that having many file elements will have on the size of the XLIFF file and management of the project.

The file element has a number of attributes that contain data that describes the actual file to which they relate.

Each file element contains both header and body child elements. The header element contains metadata about the file being localized. The body element contains the data to be localized.

trans-unit
The trans-unit contains the data to be localized. Each trans-unit has a source element that contains the original data to be localized. After translation, the target element contains the data that has been localized. The status of the target can be tracked with the state attribute.

<trans-unit>
  <source xml:lang="en-US">We are testing XLIFF.</source>
  <target state="translated" xml:lang="fr">Nous testons XLIFF.</target>
</trans-unit>

The source and target elements can include specific in-line elements for specific purposes. The g element, for example is useful for tagging text mark-up such font face changes or bold or italic.

<source xml:lang='EN-US'>We are testing <g id='b1'
ctype='bold'>XLIFF</g></source>

The x element is useful for empty in-line elements, like images.

<source xml:lang='EN-US'>We detected spaceships on the planet <x id='i1'
ctype='image' img:src='enterprize.jpg' /></source>

Page 2 of 4   « previous page   next page »