This document defines the XML Localization Interchange
File Format (XLIFF). The purpose of this vocabulary is to store
localizable data and carry it from one step of the localization process to
the other, while allowing interoperability between tools.

Status:

This document was last revised or approved by the
XLIFF TC on the above date. The level of approval is also listed above.
Check the current location noted above for possible later revisions of
this document. This document is updated periodically on no particular
schedule.

Technical Committee members should send comments on
this specification to the Technical Committee's email list. Others should
send comments to the Technical Committee by using the "Send A Comment"
button on the Technical Committee' s web page at
www.oasis-open.org/committees/xliff

For information on whether any patents have been
disclosed that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the Intellectual
Property Rights section of the Technical Committee web page (
http://www.oasis-open.org/committees/xliff/ipr.php).

All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property Rights Policy
(the "OASIS IPR Policy"). The full Policy may be found at the OASIS
website.

This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published, and distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and this section are
included on all such copies and derivative works. However, this document
itself may not be modified in any way, including by removing the copyright
notice or references to OASIS, except as needed for the purpose of
developing any document or deliverable produced by an OASIS Technical
Committee (in which case the rules applicable to copyrights, as set forth
in the OASIS IPR Policy, must be followed) or as required to translate it
into languages other than English.

The limited permissions granted above are perpetual and
will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party
that believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Committee Specification or OASIS Standard,
to notify OASIS TC Administrator and provide an indication of its
willingness to grant patent licenses to such patent claims in a manner
consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification.

OASIS invites any party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any patent claims
that would necessarily be infringed by implementations of this
specification by a patent holder that is not willing to provide a license
to such patent claims in a manner consistent with the IPR Mode of the
OASIS Technical Committee that produced this specification. OASIS may
include such claims on its website, but disclaims any obligation to do
so.

OASIS takes no position regarding the validity or scope
of any intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on OASIS' procedures with
respect to rights in any document or deliverable produced by an OASIS
Technical Committee can be found on the OASIS website. Copies of claims of
rights made available for publication and any assurances of licenses to be
made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementers or users of this OASIS Committee Specification or OASIS
Standard, can be obtained from the OASIS TC Administrator. OASIS makes no
representation that any information or list of intellectual property
rights will at any time be complete, or that any claims in such list are,
in fact, Essential Claims.

The names "OASIS" and "XLIFF" are trademarks of OASIS, the owner and developer of
this specification, and should be used only to refer to the organization
and its official outputs. OASIS welcomes reference to, and implementation
and use of, specifications, while reserving the right to enforce its marks
against misleading uses. Please see
http://www.oasis-open.org/who/trademark.php for above guidance.

1. Introduction

XLIFF is the XML Localization Interchange File Format
designed by a group of software providers, localization service providers,
and localization tools providers. It is intended to give any software
provider a single interchange file format that can be understood by any
localization provider. It is loosely based on the OpenTag version 1.2
specification and borrows from the TMX 1.2 specification. However, it is
different enough from either one to be its own format.

1.1
Transitional and Strict

XLIFF is specified in two "flavors". Indicate which of
these variants you are using by selecting the appropriate schema. The
schema may be specified in the XLIFF document itself or in an OASIS
catalog. The namespace is the same for both variants. Thus, if you want to
validate the document, the tool used knows which variant you are using.
Each variant has its own schema that defines which elements and attributes
are allowed in certain circumstances.

As newer versions of XLIFF are approved, sometimes
changes are made that render some elements, attributes or constructs in
older versions obsolete. Obsolete items are deprecated and should not be
used even though they are allowed. The XLIFF specification details which
items are deprecated and what new constructs to use.

Transitional -
Applications that produce older versions of XLIFF may still use
deprecated items. Deprecated elements and attributes are allowed.
Non-XLIFF items are validated only to ensure they are well-formed. Use
this variant to validate XLIFF documents that you read.

Strict - All
deprecated elements and attributes are not allowed. Obsolete items from
previous versions of XLIFF are deprecated and should not be used when
writing new XLIFF documents. In order for XLIFF documents with
extensions to validate, the parser MUST find the schema for namespaced
elements and attributes, and elements and attributes MUST be valid. Use
this variant to validate XLIFF documents that you create.

2. General Structure

XLIFF is an XML application, as such it begins with an
XML declaration. After the XML declaration comes the XLIFF document
itself, enclosed within the <xliff> element. An XLIFF document is
composed of one or more sections, each enclosed within a <file> element. The <file> element consists of a <header> element, which contains
metadata about the <file> , and a
<body> element, which contains the
extracted translatable data from the <file>. The translatable data within <trans-unit> elements is
organized into <source> and <target> paired elements. These <trans-unit> elements can be
grouped recursively in <group>
elements.

In addition, XLIFF provides the ability to maintain
information about the processing of the file via the <phase> element. Possible translations for a
specific <source> element can be
generated from any number of MT (Machine Translation) and CAT (Computer
Assisted Translation) systems and stored near the <source> in <alt-trans> elements. Context for a <source> that could be used by a
translator or a TM (Translation Memory) system is provided by the <context> element. Binary data can
be made available via the <bin-unit>, which may also be translated and
contain an associated
<trans-unit> .

The <phase-group> element contains information about
each processing phase used in localizing the file; references to these
phases are stored along with the translations. The <glossary> and <reference> elements may contain hypertext links to
a glossary and reference file, respectively, or the actual glossary and
reference data that can be used in the localization process.

The <count-group> element is a grouping element of
count information of the entire file. The <prop-group> element (deprecated) contains
tool-specific information used in combining the data with the skeleton
file or storing the data in a repository. The <note> element contains instructions for the
localization process. The <count-group>, <prop-group>, and <note> elements can also appear in the body of the
file.

The <trans-unit> and <bin-unit> elements contain the
translatable portions of the document. The <trans-unit> element contains the text to be
translated, the translations, and other related information. The <bin-unit> contains binary data
that may or may not need to be translated; it also can contain translated
versions of the binary object as well as other related information.

In the <trans-unit> element the text to be translated is
contained in a <source> element.
This element may contain inline elements that either remove the codes from
the source (<g>, <x/>, <bx/>,
<ex/>) or that mask off codes left
inline (<bpt>, <ept>, <sub>, <it>, <ph>). The translated text is contained in a <target> element that has the same
inline codes available to it as does the <source> element. Translation matches generated by
a TM or MT or entered by a translator may be provided in an <alt-trans> element, which also
contains the <source> and <target> elements.

At every structural level contextual information for the
localization process can be provided by the <context-group> named group element, count
information by the
<count-group> named group element, and tool-specific
information by the <prop-group> named group element (deprecated).

2.3. Named Groups

XLIFF allows grouping of certain elements into named
groups. A named group is simply a grouping element with a name attribute.
These named groups can be interspersed throughout the file with
information designed for specific purposes. Using XML processing
instructions different actions can be performed with specific named
groups. The named group elements are <context-group>, <count-group> and <prop-group> (deprecated).

The <count-group> element contains counts of words,
translations, dialogs, or anything else that may need to be counted in the
file. A different named group could be stored by the client, translator,
reviewer, and localization engineer. Processing instructions could inform
a system which of these <count-group> to update during
the localization process.

The <prop-group> element contains
tool specific data that can be used in creating the translated file,
storing the translations, and any other specific task. Processing
instructions can indicate to the tools which named <prop-group> to use when
updating the repository or combining the localized data with the skeleton
file to create a translated file. Note that the <prop-group> has been deprecated since version
1.1.

2.4.
Inline Elements

The content of the
<source> and the
<target> elements can include one or more inline elements
(also called "content markup"). Those elements are used to represent codes
that reside within the source or target text, for example the formatting
codes to mark a section of a sentence in bold.

There are three different types of inline elements:

Elements that have a content, and for which this content is the
actual native code of the original data (escaped for XML if necessary).
These elements are: <bpt>,
<ept>,
<it>, and <ph>.

Elements that are empty and act as placeholders for a native code
that is either in the Skeleton file or generated automatically. These
elements are: <g>, <bx/>, <ex/> , and <x/>.

The <sub> element, which can
be inside <bpt>, <ept>,
<it>, and <ph> to
delimit a translatable run of text within a native inline code, for
example the value of an ALT attribute in a
<IMG> element in HTML.

The first two types of inline elements can be classified
into three main categories depending on their function, and regardless the
method they use to hold the native codes:

A) Codes that either begin or end an instruction, and
whose beginning and ending functions both appear within a translation
unit. For example, an instruction to begin embolden for a range of words
which is then followed in the same translation unit by an instruction to
end bold formatting. The elements that can handle such cases are: <bpt>, <ept>, <g>,
<bx/>, and <ex/>
.

B) Codes that either begin or end an instruction, but
whose beginning and ending functions are not both contained within a
single translation unit. For example, an instruction to embolden text may
apply to the first of three sentences in a paragraph contained within a
single translation unit, but the instruction to turn off bolding may only
appear at the end of the third sentence. Its beginning instruction is
present in the first translation unit, while its closing tag is present in
the third translation unit. The elements that can handle such cases are:
<it> and <x/>.

C) Codes that represent self-contained functions that do
not require explicit ending instructions. Images or cross-reference tokens
are examples of these standalone codes. The elements that can handle such
cases are: <ph> and <x/>.

The guidelines for using the inline elements are as
follows:

Use <bpt> or <bx/> for opening each code that has a
corresponding closing code in the content. Use
<bpt> to mask the code and
<bx/> to replace the code. The
<bpt> and <bx/>
elements should be followed by a matching
<ept> or <ex/>
element, respectively, within the same translation unit. These paired
elements are matched by setting their
rid attributes to the same value. For example: <bpt
id='2' rid='1'>xx</bpt> ... <ept id='3'
rid='1'>xx</ept> and <bx id='4' rid='2'/>
... <ex id='5' rid='2'/>. If the rid attribute is not present (in a 1.0 document
for example), the attribute id is used to
match both tags. For example: <bpt id='5'>xx</bpt> ...
<ept id='5'>xx</ept>.

Use <ept> or <ex/> for closing each code that has a
corresponding opening code in the content. Use
<ept> to mask the code and
<ex/> to replace the code. The
<ept> and <ex/>
elements should be preceded by a matching
<bpt> and <bx/>
element, respectively. These paired elements are matched by setting
their rid attributes to the same value.
For example: <bpt id='2' rid='1'>xx</bpt> ... <ept
id='3' rid='1'>xx</ept> and <bx id='4'
rid='2'/> ... <ex id='5' rid='2'/>. If the rid attribute is not present (in a 1.0 document
for example), the attribute id is used to
match both tags. For example: <bpt id='5'>xx</bpt> ...
<ept id='5'>xx</ept>.

Use <g> to replace any inline
code of the original document that has a beginning and an end and can be
moved within its parent structural element.

Use <ph> or <x/> for standalone codes. Use <ph> to mask the code and <x/> to replace the code. Standalone codes
are codes that are not opening or closing of a pair, for example empty
elements in XML.

Use <it> for opening or
closing each code that has no corresponding closing or opening code in
the source element. In some cases, because of the segmentation, you may
have opening and closing codes that have no corresponding closing or
opening codes within the same translation unit. Use
<it> to encapsulate those codes. The <it> element has a mandatory pos attribute that should be set to
"begin" or "end" depending on whether the
isolated code is an opening or a closing code.

At the time of this document's authoring, TMX 14b does not support
<g> and <x/> inline tag
equivalents. Therefore, if interchange of translation memory data with
TMX is required, use <bpt> and <ept> tags instead of <g>
and <ph> tags instead of <x/>.

As XLIFF inline elements are closely related to TMX
inline elements, further examples of usage of these tags may be found in
their specification's Content
Markup section.

Inline elements are normally treated as being
transparent with regard to lexical processing such as segmentation or word
tokenisation. If the inline element also represents a lexical function,
such as implying spacial characteristics or a string of characters or
symbols, then the equiv-text
attribute must be used to denote any such lexical characteristics.

For example:

<p>This HTML break element<br/>is not followed by a white space character</p>

2.5. Extensibility

At times, it may be useful to extend the set of
information available in an XLIFF document by inserting constructs defined
in various other XML vocabularies. You can add non-XLIFF elements, as well
as attributes and attribute values. Adding elements and attributes use the
namespace mechanism [ XML Names]. Adding
attribute values generally involves preceding the value by an
"x-" (e.g. <context
context-type='x-for-engineers'>).

Although XLIFF offers this extensibility mechanism, in
order to avoid a nimiety of information and increase interoperability
between tools, it is strongly recommended to use XLIFF capabilities
whenever possible, rather than to create non-standard user-defined
elements or attributes.

It is not possible to add non-XLIFF elements in either
the <source> or <target> elements. However, the <mrk> element can be used to markup sections
of the text with user-defined values assigned to the mtype attribute. You can also add non-XLIFF attributes to
most of the inline elements used in
<source> and
<target>.

2.5.2. Adding Attributes

Attributes of a namespace different than XLIFF can be
included in several XLIFF elements.

For instance, the following XLIFF code illustrates how
to use attributes from the XHTML vocabulary (in bold) in the <group> and <trans-unit> XLIFF elements. The example shows how
to carry formatting information about an extracted table:

In each of the XLIFF elements allowing non-XLIFF
attributes: there is no specific location where to insert the non-XLIFF
attributes, and there is no limit to the number of non-XLIFF attributes
that can be used.

2.5.3. Adding Attribute Values

Many attributes in XLIFF offer a list of enumerated
values. Some applications may find it necessary to add user-defined values
to these lists. XLIFF allows for such extension.

User-defined values must start with an "x-"
prefix. There is no specified mechanism to validate individual
user-defined values. The XLIFF schema will allow any value starting with
"x-" in addition to the pre-defined values.

For example, the following excerpt shows how the
user-defined value x-for-engineer can be utilized in a
document:

2.5.4. Validating Documents with
Extensions

In order to validate an XLIFF document that contains
non-XLIFF parts, you can use the schema validation mechanism: In addition
to the namespace declarations, add the schemaLocation
attribute of the XML Schema-instance namespace to define what schemas to
use to validate the document (XLIFF and the non-XLIFF namespaces).

Note: XLIFF 1.2 XML Schemas set the attribute
processContents to value "skip", so the only
validation requirement for non-XLIFF content is to ensure it is
well-formed.

2.6. Embedding XLIFF

XML Namespace provides a convenient mechanism to use
XLIFF constructs within another XML vocabulary.

If necessary an XLIFF document, or parts of a document,
can be embedded within another XML document. The only requirement for this
is on the side of the XML format that includes the XLIFF data. For the
document to be valid, the schema of the given document type must include a
definition for external elements.

If the including XML format uses XML Schema, it should
include an <any> element in the definition of the
element where the XLIFF data can be inserted. For example, the following
XSD excerpt illustrates the case of an element type
dataBlockType that can contain zero, one or more XLIFF
constructs after a mandatory <type> element:

The ways of inserting different vocabulary in an XML
document using XSD are described in section "Any Element, Any Attribute"
in the document "XML Schema Part 0: Primer" available here:
http://www.w3.org/TR/xmlschema-0/#any.

2.7 Non equivalent translations

Linguistically complete text may have to be broken into
a number of <trans-unit>
elements due to message size constraints or other reasons. In these
instances the translator is not providing an equivalent translation for
each <source>, but rather fitting
in the target language text over a number of
<trans-unit><source> / <target> pair elements to meet the requirements of
the target application.

In this circumstance the
equiv-trans attribute for the
<target> element is used to denote that the translation
should not be regarded as a direct translation of the <source> element. The attribute is
optional, and default value is "yes". The other possible
value will be "no" to indicate that the translation in <target> for the given
<source> is not a direct equivalent linguistically of the
source language text. The following example demonstrates the use of the
equiv-trans attribute:

2.8 Grouping translations across
<trans-unit> elements

It is inevitable that individual XLIFF <trans-unit> elements may not
represent a piece of text that can be translated without reference to one
or more following <trans-unit> elements. The causes for
this may be incorrect segmentation or bad document design.

In these cases the
merged-trans attribute for the
<group> element can be used to denote that the individual
<trans-unit> elements cannot
be regarded as a direct translation, but rather need to be treated
linguistically as a merged group. This attribute has two possible values:
"yes" or "no". The default value is
"no". A value of "yes" indicates that the
<trans-unit> elements
contained within this <group>
element are to be treated together for linguistic purposes. All <trans-unit> elements that are
encompassed by a <group> element
that has its merged-trans
attribute set to "yes" normally have their related <target>
equiv-trans attribute set to the value of "no".
The text of all of the <source>
and <target> elements taken
together form one linguistic whole. No requirements are made regarding the
distribution of the translation in the
<target> elements. This will be governed by the
requirements of the individual applications. The translated text may be
placed within the first <target>
element leaving the following <target> elements blank, or distributed among the
<target> elements contained within the merged-trans attribute of the <group> element. The following example
demonstrates the use of the
merged-trans attribute for the
<group> element:

2.9 Segmentation

During some operations, such as translation and
leveraging, it may be important for the user agent to break down the
content of the <source> into
smaller runs of text (for example, sentences). These smaller parts of text
are called segments. The process of breaking down a text into
segments is known as segmentation. It is important to note that
the manipulation / segmentation of trans-unit elements is owned by the
"translator" domain, not at the extraction filter domain. This means that
segmentation will be performed by the editing tool or possibly an
automated segmentation process.

In order to avoid modifying the content of the original
<source> element, during
segmentation a new element
<seg-source> is introduced. The content of the <seg-source> element is the same as
the content of the <source>
element, but with segmentation markup. The segmentation markup is also
transferred to the <target>
element as applicable during translation.

Each segment inside the
<seg-source> and
<target> content is represented using the <mrk> element with attribute mtype set to the value "seg". For
example the following <source>
element contains three segments. After segmentation the content may look
as follows:

<source>Richard stepped out of the kitchen hut. He noticed a movement from the corner of his
eye. A monkey had climbed on top of one of the workshop sheds, trying to get in by the
ventilation shaft.</source>
<seg-source><mrk mtype="seg">Richard stepped out of the kitchen hut.</mrk>
<mrk mtype="seg">He noticed a movement from the corner of his eye.</mrk>
<mrk mtype="seg">A monkey had climbed on top of one of the workshop sheds, trying to get in
by the ventilation shaft.</mrk>
</seg-source>

Note that it may be advisable for XLIFF processing tools
to add any missing opening or closing tags when exporting standalone
segments outside the original XLIFF document.

Non-clonable <g> elements
introduce a problem for localisation in general and segmentation in
particular when the non-clonable <g> elements
content spans more than single words or isolated expressions. In this form
they represent localisation-unfriendly content and are very likely to
cause difficulties during translation. Being able to break a segment
inside such an element may be the smallest of the problems that tools
would be faced with. A non-clonable <g> element
clearly represents a piece of content that must be translated as one
piece, and cannot be segmented.

Example: This example shows how content with
clonable <g> may be localised:

<source>This is a <g>sentence. It has</g> markup.</source>

The translation into "Yoda-English" would be:

<target>A <g>sentence</g> this is. Markup <g>it has</g>.</target>

In this example the <g> element
is clonable, and can be localised correctly. However, in the case where
cloning is not possible, the resulting content cannot be correctly
localised, and is in fact irrespective of whether segments are introduced
here or not.

3.
Detailed Specifications

3.1.
XML Declaration

The XML declaration is strongly recommended. It
indicates the XML version and sets the defaults for the encoding of the
file. For example, the following declaration specifies the document is in
ISO 8859-1, the Latin-1 encoding.

<?xml version="1.0" encoding="iso-8859-1"?>

As in all XML files, the default encoding for an XLIFF
file is assumed to be either UTF-8, which is a superset of the 7-bit ASCII
character set, or UTF-16, which is UCS-2 with surrogate pairs for code
points above U+FFFF. Thus, for these character sets, the encoding
declaration is not necessary. Further, all XML parsers support these
encodings. If the encoding is in UTF-16 the first character of the file
must be the Unicode Byte-Order-Mark, U+FEFF, which indicates the
endianness of the file. Other encodings may be desirable and may be
generally supported by XML parsers. These must be declared using the
encoding declaration. The values to use for the encoding declaration are
defined in the [IANA Charsets] listing.

If necessary, you can also specify a namespace for
XLIFF. The namespace identifier for this standard is
"urn:oasis:names:tc:xliff:document:1.2".

If you need to validate the document, use the schema
validation mechanism: In addition to the namespace declarations, add the
schemaLocation attribute of the XML Schema-instance namespace
to define what schema files to use. The same example as above would then
look like this:

3.2.
Elements

XLIFF elements can be divided into five main categories:
the top-level and header elements, the named group elements, the
structural elements, the inline elements, and the delimiter elements. Attributes are shared among them.

3.2.1. Top-level and Header Elements

The top-level and header elements are the following:

<xliff>

XLIFF document - The <xliff>
element encloses all the other elements of the document. The required version attribute specifies the version
of XLIFF. The optional xml:lang
attribute is used to specify the language of the content of the
document.

One or more <file>
elements, followed by Zero, one or more non-XLIFF elements.

<file>

File - The <file> element
corresponds to a single extracted original document. The required original attribute specifies the name of
the file from which this file content is derived. The required datatype attribute specifies the format
of the original file; e.g. "html". The required source-language attribute
specifies the language of the <source> content. The optional target-language attribute is used
to specify the language of the <target> content. The optional tool-id attribute accepts the id of the <tool> used to generate this
XLIFF document. The optional date
attribute is used to specify the creation date of this XLIFF file. The
optional xml:space attribute is used
to specify how white-spaces are to be treated. The optional category attribute is used to specify a
general category of the content of the file; e.g. "medical". The optional
product-name attribute is used
to specify the name of the product which uses this file. The optional product-version and build-num attributes are used to
specify the revision of the product from which this file comes. The tool and ts
attributes have been deprecated in XLIFF 1.1.

While for backward compatibility reasons no order is
enforced for the elements before the non-XLIFF elements, the recommended
order is the one in which they are listed here.

<skl>

Skeleton file - The <skl>
element contains the skeleton file or the location of the skeleton file.
The skeleton file is a template that can be used in recreating the
original file, from the <source>
content, or the translated file, from the <target> content.

Internal file - The
<internal-file> element contains the actual file being
referenced. It is a child of the <skl> , <glossary>, and <reference> elements. The format
of the file is specified by the optional form attribute, which accepts mime-type values. The crc attribute accepts a value that can be
used to precisely identify and assure the authenticity of the file.

External file - The
<external-file> element specifies the location of the
actual file being referenced. The required href attribute provides a URI to the file. The crc attribute accepts a value that can be
used to precisely identify and assure the authenticity of the file. The uid attribute allows a unique ID to be
assigned to the file.

Note - The <note> element is
used to add localization-related comments to the XLIFF document. The
content of <note> may be instructions from developers
about how to handle the <source>, comments from the translator
about the translation, or any comment from anyone involved in processing
the XLIFF file. The optional xml:lang attribute specifies the language of the note
content. The optional from attribute
indicates who entered the note. The optional priority attribute allows a priority from 1 (high) to 10
(low) to be assigned to the note. The optional
annotates attribute indicates if the note is a general note or,
in the case of a <trans-unit>, pertains specifically to
the <source> or the <target> element.

Phase group - The
<phase-group> element contains information about the
task that has been performed on the file. This phase information is
specific to the tools and workflow used in processing the file.

Phase information - The
<phase> element contains metadata about the tasks
performed in a particular process. The required phase-name attribute uniquely
identifies the phase for reference within the
<file> element. The required process-name attribute identifies the kind of process the
phase corresponds to; e.g. "proofreading". The optional company-name attribute identifies
the company performing the task. The optional tool-id attribute references the <tool> used in performing the
task. The optional date attribute
provides a timestamp indicating when the task was performed. The optional
job-id attribute allows an ID to be
assigned to the job. The optional contact-name, contact-email, and
contact-phone attributes all refer to the person performing the
task.

Tool - The <tool> element
describes the tool that has been used to execute a given task in the
document. The required tool-id
attribute uniquely identifies the tool for reference within the <file> element. The required tool-nameattribute specifies the actual
tool name. The optional tool-versionattribute provides the version of the tool. The optional tool-company attribute provides the name
of the company that produced the tool.

3.2.2. Named Group Elements

The named group elements are the following:

<count-group>

Count group - The
<count-group> element holds count elements relating to
the level in the tree in which it occurs. Each group for <count> elements must be named, allowing
different uses for each group. The required name attribute uniquely identifies the
<count-group> within the
<file> element.

Count - The <count> element
contains information about counts. For each <count>
element the required count-type
attribute indicates what kind of count the element represents, and the
optional unit attribute indicates the
unit of the count (by default: word). A list of values for count-type and
unit is provided. The optional
phase-name attribute references the <phase> in which the count was produced.

Context group - The
<context-group> element holds context elements relating
to the level in the tree in which it occurs. Thus context can be set at a
<group> level, a <trans-unit> level, or a <alt-trans> level. Each
<context-group> element may be named, allowing
different uses for each group. When the <context-group> is named,
these uses can be controlled through the use of XML processing
instructions. Because the <context-group> element may
occur at a very high level, a default context can be established for all
<trans-unit> elements within
a file. This default can be overridden at many subsequent levels. The
optional name attribute may uniquely
identify the <context-group> within the <file> element. The optional crc attribute allows a verification of the data.
The optional purpose attribute
indicates to what use this context information is used; e.g. "match"
indicates the context information is for memory lookups.

Context - The <context>
element describes the context of a <source> within a <trans-unit> or a <alt-trans>. The purpose of this
context information is to allow certain pieces of text to have different
translations depending on where they came from. The translation of a piece
of text may differ if it is a web form or a dialog or an Oracle form or a
Lotus form for example. This information is thus required by a translator
when working on the file. Likewise, the information may be used by any
tool proposing to automatically leverage the text successfully.

The required
context-type attribute indicates what the context information
is; e.g. "recordtitle" indicates the name of a record in a database. The
optional match-mandatory
attribute indicates that translations of the
<source> elements within the scope of this context must
have the same context. The optional crc
attribute allows a verification of the data.

Property group - The
<prop-group> element contains <prop> elements. Each
<prop-group> element may be named, allowing different uses
for each group. These uses can be controlled through the use of XML
processing instructions.

Important: The <prop-group> element
was DEPRECATED in version 1.1. Instead, use attributes defined in a
namespace different from XLIFF. See the
Extensibility section for more information.

Property - The <prop> element
allows the tools to specify non-standard information in the XLIFF
document. This information can be used by the tools that have produced the
file or that translate the file or that do any other amount of processing
specific to the producer.

Important: The <prop> element was
DEPRECATED in version 1.1. Instead, use attributes defined in a namespace
different from XLIFF. See the
Extensibility section for more information.

Group - The <group> element
specifies a set of elements that should be processed together. For
example: all the items of a menu, etc. Note that a
<group> element can contain other
<group> elements. The <group> element can
be used to describe the hierarchy of the file.

The optional id attribute
is used to uniquely identify the <group> within the
same <file>. The optional datatype attribute specifies the data type of
the content of the <group>; e.g. "winres" for Windows
resources. The optional xml:space
attribute is used to specify how white-spaces are to be treated within the
<group>. The optional
restype, resname, extradata, help-id, menu, menu-option, menu-name,
coord, font, css-style,
style, exstyle, and
extype attributes describe the
resources contained within the <group>. The optional
translate attribute provides a default value for all
<trans-unit> elements contained within the
<group>. The optional
reformat attribute specifies whether and which attributes can
be modified for the <target>
elements of the <group>. The optional maxbytes and
minbytes attributes specify the required maximum and minimum
number of bytes for the translation units within the
<group>. The optional
size-unit attribute determines the unit for the optional
maxheight, minheight,
maxwidth, and minwidth
attributes, which limit the size of the resource described by the
<group>. The optional
charclass attribute restricts all translation units in the
scope of the <group> to a subset of characters. The
optional merged-trans attribute
indicates if the group element contains merged <trans-unit> elements.
The optional ts attribute was DEPRECATED in
XLIFF 1.1. Lists of values for the datatype, restype, and size-unit attributes are provided by this
specification.

The required id attribute
is used to uniquely identify the <trans-unit> within
all <trans-unit> and <bin-unit>
elements within the same <file>. The optional
approved attribute indicates whether
the translation has been approved by a reviewer. The optional translate attribute indicates whether the
<trans-unit> is to be translated. The optional reformat attribute specifies whether and
which attributes can be modified for the
<target> element of the <trans-unit> .
The optional xml:space attribute is
used to specify how white-spaces are to be treated within the
<trans-unit>. The optional
datatype attribute specifies the data type of the content of
the <trans-unit>; e.g. "winres" for Windows resources.
The optional ts attribute was DEPRECATED in
XLIFF 1.1. The optional phase-name
attribute references the phase that the <trans-unit> is
in. The optional restype, resname,
extradata, help-id,
menu,
menu-option, menu-name,
coord,
font, css-style, style,
exstyle, and extype
attributes describe the resource contained within the
<trans-unit>. The optional
maxbytes and minbytes
attributes specify the required maximum and minimum number of bytes for
the text inside the <source> and
<target> elements of the
<trans-unit>. The optional size-unit attribute determines the unit for
the optional maxheight, minheight, maxwidth, and minwidth attributes, which limit the size of
the resource described by the <trans-unit>. The
optional charclass attribute
restricts all <source> and
<target> text in the scope of the
<trans-unit> to a subset of characters. Lists of values
for the datatype, restype, and
size-unit attributes are provided by this specification. During
translation the content of the <source> element may be duplicated into a <seg-source> element, in which
additional segmentation related markup is introduced. See the Segmentation section for more
information.

All child elements of <trans-unit>
pertain to their sibling <source>
element. While for backward compatibility reasons no order is
enforced for the elements before the non-XLIFF elements, the recommended
order is the one in which they are listed here.

<source>

Source text - The <source>
element is used to delimit a unit of text that could be a paragraph, a
title, a menu item, a caption, etc. The content of the
<source> is generally the translatable text, depending
upon the translate attribute of the parent <trans-unit>. The optional xml:lang attribute is used to specify the
content language of the <source>; this should always
match source-language as a
child of <trans-unit> but can vary as a child of
<alt-trans>. The optional ts attribute was DEPRECATED in XLIFF 1.1.

Target - The <target> element
contains the translation of the content of the sibling <source> element. The optional state and state-qualifier attributes indicate in
which state the <target> is. The optional phase-name attribute references the <phase> in which the
<target> was last modified. The optional xml:lang attribute is used to specify the
content language of the <target>; this should always
match target-language as a
child of <trans-unit> but can
vary as a child of <alt-trans>. The optional coord, font,
css-style, style, and
exstyle attributes describe the
resource contained within the <target>; these are the
modifiable attributes for the
<trans-unit> depending upon the reformat attribute of the parent <trans-unit>. The optional equiv-trans
describes if the target language translation is a direct equivalent of the
source text. The optional ts attribute was
DEPRECATED in XLIFF 1.1. The restype
attribute is DEPRECATED in XLIFF 1.2, since <target>
will always be of the same restype as
its parent <trans-unit> or <alt-trans>. A list of preferred
values for the restype, state, and state-qualifier attributes are provided
by this specification.

Translation match - The
<alt-trans> element contains possible translations in
<target> elements along with
optional context, notes, etc. The optional mid attribute indicates that the <alt-trans>
applies only to a specific <mrkmtype="seg"> segment in the <seg-source> element of the <trans-unit>. (See the Segmentation section for further details.)
The optional match-quality
attribute provides a value indicating the exactness of the match between
the <source> of the <alt-trans> and that of the <source> element of the parent <trans-unit>; e.g. "90%". The optional
tool-id attribute accepts the id of
the <tool> used to generate this
<alt-trans>. The optional crc attribute allows a verification of the data.
The optional xml:lang attribute is
used to specify the content language of the
<alt-trans>. The optional xml:space attribute is used to specify how
white-spaces are to be treated within the <alt-trans>.
The optional datatype attribute
specifies the data type of the content of the
<alt-trans>; e.g. "winres" for Windows
resources. The optional restype,
resname, extradata,
help-id, menu, menu-option, menu-name,
coord, font, css-style,
style, exstyle, and
extype attributes describe the resource
contained within the <alt-trans>. The optional origin attribute specifies where the alternate
translation comes from; e.g. a previous version of the product. The
tool and ts attributes were DEPRECATED in XLIFF 1.1. Multiple <target> elements within a single
<alt-trans> are DEPRECATED in XLIFF 1.2. A list of
values for the datatype and restype attributes are provided by this
specification.

All child elements of <alt-trans>
pertain to their sibling <target> element. While for backward
compatibility reasons no order is enforced for the elements before the
non-XLIFF elements, the recommended order is the one in which they are
listed here. Although not enforced, it is recommended to adopt the
convention that more recent <alt-trans> elements appear
before older ones in order to define the order that changes are
introduced.

<bin-unit>

Binary unit - The <bin-unit>
element contains a binary object that may or may not be translatable. The
required id attribute is used to uniquely
identify the <bin-unit> within all <trans-unit> and <bin-unit> elements
within the same <file>. The required mime-type attribute specifies the data type
of the binary object based on RFC 1341. The
optional approved attribute indicates
whether the translation has been approved by a reviewer. The optional
translate attribute indicates
whether the <bin-unit> is to be
translated. The optional reformat
attribute specifies whether and which attributes can be modified for the
<bin-target> element of the
<bin-unit>. The optional ts attribute was DEPRECATED in XLIFF 1.1. The optional phase-name attribute references the phase
that the <bin-unit> is in. The optional restype and
resname attributes describe the resource contained within the
<bin-unit>. A list of values for the restype attribute is provided by this
specification.

All child elements of <bin-unit> pertain
to their sibling <bin-source> element. While for
backward compatibility reasons no order is enforced for the elements
before the non-XLIFF elements, the recommended order is the one in which
they are listed here.

<bin-source>

Binary source -The
<bin-source> element is the container for the binary
source data. The optional ts attribute was
DEPRECATED in XLIFF 1.1.

Binary target -The
<bin-target> element is the container for the
translated version of the binary data. The optional mime-type attribute specifies the data type
of the binary object based on RFC 1341. The
optional ts attribute was DEPRECATED in
XLIFF 1.1. The optional state and
state-qualifier attributes
indicate in which state the <bin-target> is. The
optional phase-name attribute
references the phase that the <bin-target> is in. The
optional restype and resname attributes describe the resource
contained within the <bin-target>. A list of values for
the restype,
state, and
state-qualifier attributes are provided by this
specification.

Source text - The <seg-source>
element is used to maintain a working copy of the
<source> element, where markup such as segmentation can
be introduced without affecting the actual
<source> element content. The content of the
<seg-source> is generally the translatable text,
typically divided into segments through the use of
<mrkmtype="seg"> elements. See the
Segmentation section for more
information. As with the <source> element, the optional xml:lang attribute is used to specify the content language of the
<seg-source>; this should always match source-language as a child of <trans-unit> but can vary as a child
of <alt-trans>. The optional
ts attribute was DEPRECATED in XLIFF
1.1.

3.2.4. Inline Elements

The inline elements are the elements that can appear
inside the <source> and <target> elements. They enclose or
replace any formatting or control code that is not text, but resides
within the text unit.

<g>

Generic group placeholder - The
<g> element is used to replace any inline code of the
original document that has a beginning and an end, does not overlap other
paired inline codes, and can be moved within its parent structural
element. The required id attribute is used
to reference the replaced code in the skeleton file. The optional ctype attribute allows you to specify what
kind of attribute the placeholder represents; e.g. "bold". The optional
ts attribute was DEPRECATED in XLIFF 1.1.
The optional clone attribute indicates
whether this <g> element may be duplicated. The
optional xid attribute references a
<trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the replaced code. A list of values for the
ctype attribute is available. The
optional equiv-text attribute specifies text to
substitute in place of the inline tag. A <g> element
can contain another <g> element.

Generic placeholder - The <x/>
element is used to replace any code of the original document. The required
id attribute is used to reference the
replaced code in the skeleton file. The optional ctype attribute allows you to specify what
kind of attribute the placeholder represents; e.g. "bold". The optional
ts attribute was DEPRECATED in XLIFF 1.1.
The optional clone attribute indicates
whether this <x/> element may be duplicated. The
optional xid attribute references a
<trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the replaced code. A list of values for the
ctype attribute is provided by this
specification. The optional equiv-text attribute
specifies text to substitute in place of the inline tag.

Begin paired placeholder - The
<bx/> element is used to replace a beginning paired
code of the original document. It should be used for paired codes that do
not follow XML well-formedness rules (i.e. no overlapping elements). If
the paired codes follow that rule, it is strongly recommended that the <g> element is used because it
simplifies processing. The <bx/> element should be
followed by a matching <ex/> element.
These paired elements are related via their rid attributes. If the rid attribute is not present (in a 1.0 document for
example), the attribute id is used to
match both tags. The required id attribute
is used to reference the replaced code in the skeleton file. The optional
ctype attribute allows you to specify
what kind of attribute the placeholder represents; e.g. "bold". The
optional ts attribute was DEPRECATED in
XLIFF 1.1. The optional clone attribute
indicates whether this <bx/> element may be duplicated.
The optional xid attribute references a
<trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the replaced code. A list of values for the
ctype attribute is provided by this
specification. The optional equiv-text attribute
specifies text to substitute in place of the inline tag.

End paired placeholder - The
<ex/> element is used to replace an ending paired code
of the original document. It should be used for paired codes that do not
follow XML well-formedness rules (i.e. no overlapping elements). If the
paired codes follow that rule, it is strongly recommended that the <g> element is used because it simplifies
processing. The <ex/> element should be preceded by a
matching <bx/> element. These paired
elements are related via their rid
attributes. If the rid attribute is not
present (in a 1.0 document for example), the attribute id is used to match both tags. The required
id attribute is used to reference the
replaced code in the skeleton file. The optional ts attribute was DEPRECATED in XLIFF 1.1. The
optional xid attribute references a
<trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the replaced code. The optional equiv-text attribute specifies text to substitute
in place of the inline tag.

Placeholder - The <ph> element
is used to delimit a sequence of native stand-alone codes in the
translation unit. The required id attribute
is used to identify the <ph> inline code. The optional
ctype attribute allows you to specify
what kind of attribute the placeholder represents; e.g. "bold". The
optional ts attribute was DEPRECATED in
XLIFF 1.1. The optional crc attribute
allows a verification of the data. The optional assoc attribute specifies whether this
placeholder code is associated with the text prior or after. The optional
xid attribute references a <trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the replaced code. A list of values for the
ctype attribute is provided by this
specification. The optional equiv-text attribute
specifies text to substitute in place of the inline tag.

Begin paired tag - The <bpt>
element is used to delimit the beginning of a paired sequence of native
codes. Each <bpt> has a corresponding <ept> element within the translation unit. These
paired elements are related via their rid
attributes. If the rid attribute is not
present (in a 1.0 document for example), the attribute id is used to match both tags. The required
id attribute is used to identify the
<bpt> inline code. The optional ctype attribute allows you to specify what
kind of attribute the code represents; e.g. "bold". The optional ts attribute was DEPRECATED in XLIFF 1.1. The
optional crc attribute allows a
verification of the data. The optional xid
attribute references a <trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the inline code. A list of values for the ctype attribute is provided by this
specification. The optional equiv-text attribute
specifies text to substitute in place of the inline tag.

End paired tag - The <ept>
element is used to delimit the end of a paired sequence of native codes.
Each <ept> has a corresponding <bpt> element within the translation unit. These
paired elements are related via their rid
attributes. If the rid attribute is not
present (in a 1.0 document for example), the attribute id is used to match both tags. The required
id attribute is used to identify the
<ept> inline code. The optional ts attribute was DEPRECATED in XLIFF 1.1. The
optional crc attribute allows a
verification of the data. The optional xid
attribute references a <trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the inline code. The optional equiv-text attribute specifies text to substitute
in place of the inline tag.

Isolated tag - The <it>
element is used to delimit a beginning/ending sequence of native codes
that does not have its corresponding ending/beginning within the
translation unit. The required id attribute
is used to identify the <it> inline code. The required
pos attribute specifies whether this is
the begin or end code. The optional ctype attribute allows you to specify what
kind of attribute the code represents; e.g. "bold". The optional ts attribute was DEPRECATED in XLIFF 1.1. The
optional crc attribute allows a
verification of the data. The optional xid
attribute references a
<trans-unit> or
<bin-unit>, through its id attribute value, which can contain any translatable text from the
inline code. A list of values for the ctype attribute is provided by this
specification. The optional equiv-text attribute
specifies text to substitute in place of the inline tag.

Sub-flow - The <sub> element
is used to delimit sub-flow text inside a sequence of native code, for
example: the definition of a footnote or the text of a title
attribute in a HTML <a> element. The optional datatype attribute specifies the data type of
the content of the <sub>; e.g. "html". The optional ctype attribute allows you to specify what
kind of attribute the code represents. The optional xid attribute references a <trans-unit> or <bin-unit>, through its id attribute value, which can contain any
translatable text from the inline code. Lists of values for the ctype and datatype attributes are provided by this
specification.

3.2.5. Delimiter Element

XLIFF defines an additional element to support various
types of text processing. This element is usually not generated by the
extraction module and is ignored most of the time during merging, but it
can be very powerful with tools such as Machine Translation, glossary
handling, quality assurance, etc.

<mrk>

Marker - The <mrk> element
delimits a section of text that has special meaning, such as a
terminological unit, a proper name, an item that should not be modified,
etc. It can be used for various processing tasks. For example: to indicate
to a Machine Translation tool proper names that should not be translated;
for terminology verification; to mark suspect expressions after a grammar
checking. The <mrk> element is usually not generated by
the extraction tool and it is not part of the tags used to merge the XLIFF
file back into its original format. The required mtype attribute specifies what is being
delimited; e.g. "abbrev" for an abbreviation. The optional ts attribute was DEPRECATED in XLIFF 1.1. The
optional comment attribute allow a
free-form comment to be entered. A list of values for the mtype attribute is provided by this
specification. The <mrk> element can be used to delimit
segments as described in the
Segmentation section.

3.3.
Attributes

This section lists the various attributes used in the
XLIFF elements. An attribute is never specified more than once for each
element. Along with some of the attributes is the list of their possible
values.

Association - Indicates the association of a <ph> with the text prior or after the
inline element.

Value description:

preceding (the element is associated with the
text preceding the element), following (the element is
associated with the text following the element), and both
(the element is associated with the text on both sides).

Clone - This indicates that a copy of the given
inline element can be made and placed multiple times in the <target>. This is useful for codes such
as bold which may require duplication after localization of a segment.

Context type - The context-type
attribute specifies the context and the type of resource or style of the
data of a given element. For example, to define if it is a label, or a
menu item in the case of resource-type data, or the style in the case of
document-related data.

Value description:

The pre-defined values are defined in the table below.

Value

Description

database

Indicates a database
content.

element

Indicates the content of an
element within an XML document.

elementtitle

Indicates the name of an
element within an XML document.

linenumber

Indicates the line number
from the sourcefile (see context-type="sourcefile") where the
<source> is found.

numparams

Indicates a the number of
parameters contained within the <source>.

paramnotes

Indicates notes pertaining to
the parameters in the <source>.

record

Indicates the content of a
record within a database.

recordtitle

Indicates the name of a
record within a database.

sourcefile

Indicates the original source
file in the case that multiple files are merged to form the original
file from which the XLIFF file is created. This differs from the
original <file> attribute in that this sourcefile is one of many
that make up that file.

In addition, user-defined values can be used with this
attribute. A user-defined value must start with an "x-"
prefix.

Coordinates - The coord attribute
specifies the x, y, cx and cy coordinates of the text for a given element.
The cx and cy values must represent the width and the height (as in
Windows resources). The extraction and merging tools must make the right
conversion if the original format uses a top-left/bottom-right coordinate
system.

Value description:

Four decimal (possibly negative) values, in the order: x,
y, cx and cy, separated by semi-colons. Null values may be entered as
"#"; (e.g. coord="#;#;183;272").

Data type - The datatype attribute
specifies the kind of text contained in the element. Depending on that
type, you may apply different processes to the data. For example:
datatype="winres" specifies that the content is Windows
resources which would allow using the Win32 API in rendering the
content.

Value description:

The pre-defined values are defined in the table below.

Value

Description

asp

Indicates Active Server Page
data.

c

Indicates C source file
data.

cdf

Indicates Channel Definition
Format (CDF) data.

cfm

Indicates ColdFusion
data.

cpp

Indicates C++ source file
data.

csharp

Indicates C-Sharp data.

cstring

Indicates strings from C,
ASM, and driver files data.

csv

Indicates comma-separated
values data.

database

Indicates database data.

documentfooter

Indicates portions of
document that follows data and contains metadata.

documentheader

Indicates portions of
document that precedes data and contains metadata.

Date - The date attribute indicates
when a given element was created or modified.

Value description:

Date in [ISO 8601] Format. The
recommended pattern to use is: CCYY-MM-DDThh:mm:ssZ
Where: CCYY is the year (4 digits), MM is the
month (2 digits), DD is the day (2 digits), hh
is the hours (2 digits), mm is the minutes (2 digits),
ss is the second (2 digits), and Z indicates the
time is UTC time. For example:

date="2002-01-25T21:06:00Z"
is January 25, 2002 at 9:06pm GMT
is January 25, 2002 at 2:06pm US Mountain Time
is January 26, 2002 at 6:06am Japan time

equiv-text - Indicates the equivalent text to
substitute in place of an inline tag. It is useful for inserting
whitespace or other content in place of markup to facilitate consistent
word counting. The equiv-text attribute is also useful for ensuring
consistent round trip conversion between native resource formats and XLIFF
content, for example the resource string "F&ile" converts
to the following XLIFF: "F<x id='1' ctype='x-akey'
equiv-text=''/>ile" to preserve the underlying translatable
content.

Font - The font attribute specifies
the font name, size, and weight of the text for a given element. The font
attribute would generally be used for resource-type data: change of font
in document-type data can be marked with the <g> element.

Value description:

Name of the font, its size, its weight, its style and its
encoding separated by semi-colons. Only the name of the font is
required.

Identifier - The id attribute is
used in many elements as a reference to the original corresponding code
data or format for the given element. The value of the id
element is determined by the tool creating the XLIFF document. It may or
may not be a resource identifier. The identifier of a resource should, at
least, be stored in the resname
attribute.

Maximum height - The maximum height for the
<target> of a <trans-unit>. This could be
interpreted as lines, pixels, or any other relevant unit. The unit is
determined by the size-unit
attribute, which defaults to pixel.

Maximum bytes - The maximum number of bytes for
the <target> of a <trans-unit>. The verification of
whether the relevant text respects this requirement must be done using the
encoding and line-break type of the final target environment.

Maximum width - The maximum width for the <target> of a <trans-unit>. This could be interpreted as lines,
pixels, or any other relevant unit. The unit is determined by the size-unit attribute, which defaults to
pixel.

Mime type -Indicates the type of a binary object.
These roughly correspond to the content-type of RFC
1341 , the MIME specification; e.g.
mime-type="image/jpeg" indicates the binary object is an
image file of JPEG format. This is important in determining how to edit
the binary object.

Value description:

Text. A list of preferred values is available from the [RFC 1341] document: the MIME specification.

Minimum height - The minimum height for the
<target> of a <trans-unit>. This could be
interpreted as lines, pixels, or any other relevant unit. The unit is
determined by the size-unit
attribute, which defaults to pixel.

Minimum bytes - The minimum number of bytes for
the <target> of a <trans-unit>. The verification of
whether the relevant text respects this requirement must be done using the
encoding and line-break type of the final target environment.

Minimum width - The minimum width for the <target> of a <trans-unit>. This could be interpreted as lines,
pixels, or any other relevant unit. The unit is determined by the size-unit attribute, which defaults to
pixel.

Marker type -The mtype attribute
specifies what a <mrk> element is
defining within the content of a <source> or <target> element.

Value description:

The pre-defined values are defined in the table below.

Value

Description

abbrev

Indicates the marked text is
an abbreviation.

abbreviated-form

ISO-12620 2.1.8: A term
resulting from the omission of any part of the full term while
designating the same concept.

abbreviation

ISO-12620 2.1.8.1: An
abbreviated form of a simple term resulting from the omission of some
of its letters (e.g. 'adj.' for 'adjective').

acronym

ISO-12620 2.1.8.4: An
abbreviated form of a term made up of letters from the full form of a
multiword term strung together into a sequence pronounced only
syllabically (e.g. 'radar' for 'radio detecting and ranging').

appellation

ISO-12620: A proper-name
term, such as the name of an agency or other proper entity.

collocation

ISO-12620 2.1.18.1: A
recurrent word combination characterized by cohesion in that the
components of the collocation must co-occur within an utterance or
series of utterances, even though they do not necessarily have to
maintain immediate proximity to one another.

common-name

ISO-12620 2.1.5: A synonym
for an international scientific term that is used in general discourse
in a given language.

datetime

Indicates the marked text is
a date and/or time.

equation

ISO-12620 2.1.15: An
expression used to represent a concept based on a statement that two
mathematical expressions are, for instance, equal as identified by the
equal sign (=), or assigned to one another by a similar sign.

expanded-form

ISO-12620 2.1.7: The complete
representation of a term for which there is an abbreviated form.

formula

ISO-12620 2.1.14: Figures,
symbols or the like used to express a concept briefly, such as a
mathematical or chemical formula.

head-term

ISO-12620 2.1.1: The concept
designation that has been chosen to head a terminological record.

initialism

ISO-12620 2.1.8.3: An
abbreviated form of a term consisting of some of the initial letters
of the words making up a multiword term or the term elements making up
a compound term when these letters are pronounced individually (e.g.
'BSE' for 'bovine spongiform encephalopathy').

international-scientific-term

ISO-12620 2.1.4: A term that
is part of an international scientific nomenclature as adopted by an
appropriate scientific body.

internationalism

ISO-12620 2.1.6: A term that
has the same or nearly identical orthographic or phonemic form in many
languages.

logical-expression

ISO-12620 2.1.16: An
expression used to represent a concept based on mathematical or
logical relations, such as statements of inequality, set
relationships, Boolean operations, and the like.

materials-management-unit

ISO-12620 2.1.17: A unit to
track object.

name

Indicates the marked text is
a name.

near-synonym

ISO-12620 2.1.3: A term that
represents the same or a very similar concept as another term in the
same language, but for which interchangeability is limited to some
contexts and inapplicable in others.

part-number

ISO-12620 2.1.17.2: A unique
alphanumeric designation assigned to an object in a manufacturing
system.

phrase

Indicates the marked text is
a phrase.

phraseological-unit

ISO-12620 2.1.18: Any group
of two or more words that form a unit, the meaning of which frequently
cannot be deduced based on the combined sense of the words making up
the phrase.

protected

Indicates the marked text
should not be translated.

romanized-form

ISO-12620 2.1.12: A form of a
term resulting from an operation whereby non-Latin writing systems are
converted to the Latin alphabet.

seg

Indicates that the marked
text represents a segment.

set-phrase

ISO-12620 2.1.18.2: A fixed,
lexicalized phrase.

short-form

ISO-12620 2.1.8.2: A variant
of a multiword term that includes fewer words than the full form of
the term (e.g. 'Group of Twenty-four' for 'Intergovernmental Group of
Twenty-four on International Monetary Affairs').

sku

ISO-12620 2.1.17.1: Stock
keeping unit, an inventory item identified by a unique alphanumeric
designation assigned to an object in an inventory control system.

standard-text

ISO-12620 2.1.19: A fixed
chunk of recurring text.

symbol

ISO-12620 2.1.13: A
designation of a concept by letters, numerals, pictograms or any
combination thereof.

synonym

ISO-12620 2.1.2: Any term
that represents the same or a very similar concept as the main entry
term in a term entry.

synonymous-phrase

ISO-12620 2.1.18.3:
Phraseological unit in a language that expresses the same semantic
content as another phrase in that same language.

term

Indicates the marked text is
a term.

transcribed-form

ISO-12620 2.1.11: A form of a
term resulting from an operation whereby the characters of one writing
system are represented by characters from another writing system,
taking into account the pronunciation of the characters
converted.

transliterated-form

ISO-12620 2.1.10: A form of a
term resulting from an operation whereby the characters of an
alphabetic writing system are represented by characters from another
alphabetic writing system.

truncated-term

ISO-12620 2.1.8.5: An
abbreviated form of a term resulting from the omission of one or more
term elements or syllables (e.g. 'flu' for 'influenza').

variant

ISO-12620 2.1.9: One of the
alternate forms of a term.

In addition, user-defined values can be used with this
attribute. A user-defined value must start with an "x-"
prefix.

Name - The name attribute specifies
the user-defined name of a named group element. This is used for
identification purposes only and is not referenced with the file, unless
by a processing instruction.

Translation Match Origin - The
origin attribute specifies where a translation match came
from; for example, from a previous version of the same product, a
different product, a shared translation memory, etc.

Property type - The prop-type
attribute specifies the type of a <prop> element.

Important: Because the
<prop> element was DEPRECATED in version 1.1 and this
attribute is only a member of that element, this attribute is also
deprecated. Instead, use attributes defined in a namespace different from
XLIFF. See the Extensibility section for
more information.

Purpose - The purpose attribute
specifies the purpose of a
<context-group> element. For example:
purpose="information" indicates the content is informational
only and not used for specific processing.

Value description:

The pre-defined values are defined in the table below.

Value

Description

information

Indicates that the context is
informational in nature, specifying for example, how a term should be
translated. Thus, should be displayed to anyone editing the XLIFF
document.

location

Indicates that the
context-group is used to specify where the term was found in the
translatable source. Thus, it is not displayed.

match

Indicates that the context
information should be used during translation memory lookups. Thus, it
is not displayed.

In addition, user-defined values can be used with this
attribute. A user-defined value must start with an "x-"
prefix.

Combinations of these values can be used. For example,
purpose="location match x-validate" provides both location
(location) and TM matching (match) contextual
information, as well as some user-defined data (x-validate
).

Resource name - Resource name or identifier of a
item. For example: the key in the key/value pair in a Java properties
file, the ID of a string in a Windows string table, the index value of an
entry in a database table, etc.

Reference identifier - The rid
attribute is used to link paired inline elements. The rid
attribute of a begin-paired-code element should have the same value as the
close-paired-code element. For example: <bx id="1" rid="1"/>
... <ex id="3" rid="1"/> indicates these elements are paired.
If the rid attribute is not present (in a 1.0 document for
example), the attribute id is used to match
both tags. For example: <bpt id='5'>xx</bpt> ... <ept
id='5'>xx</ept>.

Unit of size attributes - The
size-unit attribute specifies the units of measure used in
the maxheight, minheight,
maxwidth, and minwidth
attributes. The size-unit attribute is not related to the
coord attribute.

Value description:

The pre-defined values are defined in the table below.

Value

Description

byte

Indicates a size in 8-bit
bytes.

char

Indicates a size in Unicode
characters.

col

Indicates a size in columns.
Used for HTML text area.

cm

Indicates a size in
centimeters.

dlgunit

Indicates a size in dialog
units, as defined in Windows resources.

em

Indicates a size in
'font-size' units (as defined in CSS).

ex

Indicates a size in
'x-height' units (as defined in CSS).

glyph

Indicates a size in glyphs. A
glyph is considered to be one or more combined Unicode characters that
represent a single displayable text character. Sometimes referred to
as a 'grapheme cluster'

in

Indicates a size in
inches.

mm

Indicates a size in
millimeters.

percent

Indicates a size in
percentage.

pixel

Indicates a size in
pixels.

point

Indicates a size in
point.

row

Indicates a size in rows.
Used for HTML text area.

In addition, user-defined values can be used with this
attribute. A user-defined value must start with an "x-"
prefix.

State-qualifier - Describes the state of a
particular translation in a <target> or <bin-target> element.

Value description:

The pre-defined values are defined in the table below.

Value

Description

exact-match

Indicates an exact match. An
exact match occurs when a source text of a segment is exactly the same
as the source text of a segment that was translated previously.

fuzzy-match

Indicates a fuzzy match. A
fuzzy match occurs when a source text of a segment is very similar to
the source text of a segment that was translated previously (e.g. when
the difference is casing, a few changed words, white-space
discripancy, etc.).

id-match

Indicates a match based on
matching IDs (in addition to matching text).

leveraged-glossary

Indicates a translation
derived from a glossary.

leveraged-inherited

Indicates a translation
derived from existing translation.

leveraged-mt

Indicates a translation
derived from machine translation.

leveraged-repository

Indicates a translation
derived from a translation repository.

leveraged-tm

Indicates a translation
derived from a translation memory.

mt-suggestion

Indicates the translation is
suggested by machine translation.

rejected-grammar

Indicates that the item has
been rejected because of incorrect grammar.

rejected-inaccurate

Indicates that the item has
been rejected because it is incorrect.

rejected-length

Indicates that the item has
been rejected because it is too long or too short.

rejected-spelling

Indicates that the item has
been rejected because of incorrect spelling.

tm-suggestion

Indicates the translation is
suggested by translation memory.

In addition, user-defined values can be used with this
attribute. A user-defined value must start with an "x-"
prefix.

Extern Reference identifier - The
xid attribute is used to link an inline element to a
different <trans-unit> or
<bin-unit> element. For
example, to link the text within a code to a corresponding translation
unit.

3.3.2. XML Namespace Attributes

Language - The xml:lang attribute
specifies the language variant of the text of a given element. For
example: xml:lang="fr-FR" indicates the French language as
spoken in France.

Value description:

A language code as described in the [RFC 4646], the successor to [RFC 3066]. This
declared value is considered to apply to all elements within the content
of the element where it is specified, unless overridden with another
instance of the xml:lang attribute. Unlike the other XLIFF
attributes, the values for xml:lang are not case-sensitive.
For more information see the section on
xml:lang in the XML specification, and the erratum E11 (which
replaces RFC 1766 by RFC 3066).

default or preserve. The value
default signals that an application's default white-space
processing modes are acceptable for this element; the value
preserve indicates the intent that applications preserve all
the white space. This declared intent is considered to apply to all
elements within the content of the element where it is specified, unless
overridden with another instance of the xml:space
attribute.

D. Naming
Guidelines (Non-Normative)

The following naming guidelines were used in writing
this specification.

D.1. Elements and Attributes

The following guidelines were used for element and
attribute naming.

Standard English letters.

Lower case only.

Hyphen is the preferred mean for creating composite names.

Industry standard terminology should be followed where
possible.

D.2. Attribute Values

Attribute values are case sensitive. It is recommended
that lower-case values are used. The specification recommends a number of
values for some attributes, these are all lower-case.

Where multiple attribute values are to be used in an
XLIFF document, two approaches are used: For enumerated attributes (such
as the purpose attribute of <context-group>) the separator must
be a space. For other textual attributes based on string, the
specification recommends the use of the semi-colon as a separator for
values. For example, multiple contacts may be listed for a <file> with the attribute written thusly:
contact-name="Frank Sinatra;Sammy Davis Jnr;Dean Martin"
.

D.3.
Processing Instructions

XLIFF reserves processing instructions that begin with
"xliff-".

D.4.
XLIFF File Extension

XLIFF documents use the .xlf extension. No
other extension is recommended by the specification.

E. XLIFF
Technical Committee (Non-Normative)

The XLIFF Technical Committee at OASIS is composed of
the following members: