1 Introduction

Agent

any application or tool that generates (creates), reads, edits, writes, processes, stores, renders or otherwise handlesXLIFF Documents.

Agent is the most general application conformance target that subsumes all other specialized user agents disregarding whether they are defined in this specification or not.

Enrich,Enriching

the process of associating module and extension based metadata and resources with theExtracted XLIFF payload

Processing Requirements

• Enriching MAY happen at the time ofExtraction.

Note

Extractor knowledge of the native format is not assumed whileEnriching.

Enricher,Enricher Agent

anyAgent that performs theEnriching process

Extract,Extraction

the process of encoding localizable content from a native content or User Interface format as XLIFF payload, so that localizable parts of the content in the source language are available forTranslation into the target language along with the necessary context information

Extractor,Extractor Agent

anyAgent that performs theExtraction process

Merge,Merging

the process of importing XLIFF payload back to the originating native format, based on thefull knowledge of theExtraction mechanism, so that the localized content or User Interface strings replace the source language in the native format

Merger,Merger Agent

anAgent that performs theMerge process

Warning

Unless specified otherwise, anyMerger is deemed to have the same knowledge of the native format as theExtractor throughout the specification.

Mergers independent ofExtractors can succeed, but it is out of scope of this specification to specify interoperability forMerging back without the fullExtractor knowledge of the native format.

Modify,Modification

the process of changing core and module XLIFF structural and inline elements that were previously created by otherWriters

Processing Requirements

• XLIFF elements MAY beModified andEnriched at the same time.

Note

Extractor orEnricher knowledge of the native format is not assumed whileModifying.

Modifier,Modifier Agent

anAgent that performs theModification process

Translation,Translate

a rendering of the meaning of the source text, expressed in the target language

Writer,Writer Agent

anAgent that creates, generates, or otherwise writes anXLIFF Document for whatever purpose, including but not limited toExtractor,Modifier, andEnricherAgents.

Note

Since XLIFF is intended as an exchange format rather than a processing format, many applications will need to generateXLIFF Documents from their internal processing formats, even in cases when they are processingXLIFF Documents created by anotherExtractor.

XLIFF Core

The core of XLIFF 2.0 consists of the minimum set of XML elements and attributes required to (a) prepare a document that contains text extracted from one or more files for localization, (b) allow it to be completed with the translation of the extracted text, and (c) allow the generation ofTranslated versions of the original document.

The XML namespace that corresponds to the core subset of XLIFF 2.0 is"urn:oasis:names:tc:xliff:document:2.0".

XLIFF-defined (elements and attributes)

The following is the list of allowed schema URN prefixes forXLIFF-defined elements and attributes:

urn:oasis:names:tc:xliff:

However, the following namespaces are NOT consideredXLIFF-defined for the purposes of the XLIFF 2.0 specification:

urn:oasis:names:tc:xliff:document:1.0

urn:oasis:names:tc:xliff:document:1.1

urn:oasis:names:tc:xliff:document:1.2

Elements and attributes from other namespaces are notXLIFF-defined.

XLIFF Document

Any XML document that declares the namespace"urn:oasis:names:tc:xliff:document:2.0" as its main namespace, has<xliff> as the root element and complies with the XML Schemas and the declared Constraints that are part of this specification.

XLIFF Module

A module is an OPTIONAL set of XML elements and attributes that stores information about a process applied to anXLIFF Document and the data incorporated into the document as result of that process.

Each official module defined for XLIFF 2.0 has its grammar defined in an independent XML Schema with a separate namespace.

[BCP 47] M. Davis,Tags for Identifying Languages,http://tools.ietf.org/html/bcp47 IETF (Internet Engineering Task Force).

[HTML5] W3C,HTML5. A vocabulary and associated APIs for HTML and XHTML,http://www.w3.org/TR/html5/ W3C Candidate Recommendation 17 December 2012.

[NOTE-datetime] M. Wolf, C. Wicksteed,Date and Time Formats,http://www.w3.org/TR/NOTE-datetime W3C Note, 15th Setember 1997.

[RFC 2119] S. Bradner,Key words for use in RFCs to Indicate Requirement Levels,http://www.ietf.org/rfc/rfc2119.txt IETF (Internet Engineering Task Force) RFC 2119, March 1997.

[UAX #9] M. Davis,UNICODE BIDIRECTIONAL ALGORITHM,http://www.unicode.org/reports/tr9/ Unicode Bidirectional Algorithm.

[UAX #15] M. Davis, K. Whistler,UNICODE NORMALIZATION FORMS,http://www.unicode.org/reports/tr15/ Unicode Normalization Forms.

[Unicode] The Unicode Consortium,The Unicode Standard,http://www.unicode.org/versions/latest/ Mountain View, CA: The Unicode Consortium, 2012.

[XML] W3C,Extensible Markup Language (XML) 1.0,http://www.w3.org/TR/xml/ (Fifth Edition) W3C Recommendation 26 November 2008.

[XML namespace] W3C,Schema document for namespace http://www.w3.org/XML/1998/namespacehttp://www.w3.org/2001/xml.xsd [http://www.w3.org/2009/01/xml.xsd]. athttp://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/informativeCopiesOf3rdPartySchemas/w3c/xml.xsd in this distribution

[XML Schema Datatypes] W3C,XML Schema Part 2: Datatypes,http://www.w3.org/TR/xmlschema-2/ (Second Edition) W3C Recommendation 28 October 2004.

[ITS] MultilingualWeb-LT WGInternationalization Tag Set (ITS) Version 2.0, 29 October 2013,http://www.w3.org/TR/its20/ W3C Recommendation.

[LDML]Unicode Locale Data Markup Languagehttp://unicode.org/reports/tr35/

[SRX]Segmentation Rules eXchangehttp://www.gala-global.org/oscarStandards/srx/

[UAX #29] M. Davis,UNICODE TEXT SEGMENTATION,http://www.unicode.org/reports/tr29/ Unicode text Segmentation.

[XML I18N BP]Best Practices for XML Internationalization, 13 February 2008,http://www.w3.org/TR/xml-i18n-bp/ W3C Working Group.

2 Conformance

3 Fragment Identification

4 The Core Specification

Root element for XLIFF documents.

Contains:

Attributes:

Container for localization material extracted from an entire single document, or another high level self contained logical node in a content structure that cannot be described in the terms of documents.

Contains:

Attributes:

Container for non-translatable material pertaining to the parent<file> element.

Contains:

Either

or

Attributes:

Provides a way to organize units into a structured hierarchy.

Note that this is especially useful for mirroring a source format's hierarchical structure.

Contains:

Attributes:

Static container for a dynamic structure of elements holding the extracted translatable source text, aligned with theTranslated text.

Contains:

Attributes:

This element is a container to hold in its aligned pair of children elements the minimum portion of translatable source text and itsTranslation in the givenSegmentation.

Contains:

Attributes:

Part of the extracted content that is not included in a segment (and therefore not translatable). For example tools can use<ignorable> to store the white space and/or codes that are between two segments.

Contains:

Attributes:

Collection of comments.

Contains:

This is an XLIFF specific way how to present end user readable comments and annotations. A note can contain information about<source>,<target>,<unit>,<group>, or<file> elements.

Contains:

Attributes:

Unit-level collection of original data for the inline codes.

Contains:

Storage for the original data of an inline code.

Contains:

Non-translatable text and<cp> elements MAY appear in any order.

Attributes:

Portion of text to be translated.

Contains:

Text and inline elements may appear in any order.

Attributes:

The translation of the sibling<source> element.

Contains:

Text and inline elements may appear in any order.

Attributes:

Represents a Unicode character that is invalid in XML.

Contains:

Parents:

Attributes:

Example:

<unit> <segment>  <source>Ctrl+C=<cp hex="0003"/></source> </segment></unit>

The example above shows a character U+0003 (Control C) as it has to be represented in XLIFF.

Represents a standalone code of the original format.

Contains:

Parents:

Attributes:

Example:

<unit> <originalData>  <data>%d</data>  <data>&lt;br/></data> </originalData> <segment>  <source>Number of entries: <ph dataRef="d1" /><ph dataRef="d2"/>(These entries are only the ones matching thecurrent filter settings)</source> </segment></unit>

Represents a well-formed spanning original code.

Contains:

Text and inline elements may appear in any order.

Parents:

Attributes:

Example:

<unit> <originalData>  <data>&lt;B&gt;</data>  <data>&lt;/B&gt;</data> </originalData> <segment><pc dataRefStart="1" dataRefEnd="2">Important</pc>text</source> </segment></unit>

Start of a spanning original code.

Contains:

Parents:

Attributes:

Example:

<unit> <segment>  <source><sc type="fmt" subType="xlf:b"/>First sentence. </source> </segment> <segment>  <source>Second sentence.<ec startRef="1" type="fmt" subType="xlf:b"/>  </source> </segment></unit>

End of a spanning original code.

Contains:

Parents:

Attributes:

Example:

<unit> <originalData>  <data>\b </data>  <data>\i </data>  <data>\b0 </data>  <data>\i0 </data> </originalData> <segment>  <source>Text in <sc dataRef="d1"/>bold <sc dataRef="d2"/>and<ec startRef="1" dataRef="d3"/> italics<ec startRef="2" dataRef="d4"/>.</source> </segment></unit>

Represents an annotation pertaining to the marked span.

Contains:

Text and inline elements may appear in any order.

Parents:

Attributes:

See theAnnotations section for more details and examples on how to use the<mrk> element.

Start marker of an annotation where the spanning marker cannot be used for wellformedness reasons.

Contains:

Parents:

Attributes:

See theAnnotations section for more details and examples on how to use the<sm> element.

End marker of an annotation where the spanning marker cannot be used for wellformedness reasons.

Contains:

Parents:

Attributes:

See theAnnotations section for more details and examples on how to use the<em> element.

Comment target - indicates the element to what the content of the note applies.

Value description:source ortarget.

Default value: undefined.

Used in:<note>.

Replication editing hint - indicates whether or not the inline code can be copied.

Value description:yes if the code can be copied,no if the code is not intended to be copied.

Default value:yes.

Used in:<pc>,<sc>,<ec>,<ph>.

Deletion editing hint - indicates whether or not the inline code can be deleted.

Value description:yes if the code can be deleted,no if the code is not allowed to be deleted.

Default value:yes.

Used in:<pc>,<sc>,<ec>,<ph>.

Code can overlap - indicates whether or not the spanning code where this attribute is used can enclose partial spanning codes (i.e. a start code without its corresponding end code, or an end code without its corresponding start code).

Value description:yes orno.

Default value: default values for this attribute depend on the element in which it is used:

Used in:<pc>,<sc> and<ec>

Example:

<unit> <originalData>  <data>\i1 </data>  <data>\i0 </data>  <data>{\b </data>  <data>}</data> </originalData> <segment>  <source><pc dataRefStart="3" dataRefEnd="4" canOverlap="no"/>Bold,<sc dataRef="1" canOverlap="yes"/>both</pc>,italics<ec startRef="2" dataRef="2"/></source> </segment></unit>

Re-ordering editing hint - indicates whether or not the inline code can be re-ordered. SeeEditing Hints section for more details.

Value description:yes in case the code can be re-ordered,firstNo when the code is the first element of a sequence that cannot be re-ordered,no when it is another element of such a sequence.

Default value:yes.

Used in:<pc>,<sc>,<ec>,<ph>.

Can resegment - indicates whether or not the source text in the scope of the givencanResegment flag can be reorganized into a different structure of<segment> elements within the same parent<unit>.

Value description:yes orno.

Default value: default values for this attribute depend on the element in which it is used:

Used in:<file><group><unit>, and<segment>.

Category - provides a way to categorize notes.

Value description: Text.

Default value: undefined

Used in:<note>.

Reference to base code - holds theid of the base code of a copied code.

Value description: NMTOKEN. Theid value of the base code of which this code is a copy.

Default value: undefined

Used in:<ph>,<pc>,<sc>,<ec>.

Example:

<unit> <segment>  <source>Äter <pc>katter möss</pc>?</source>  <target>Do <pc>cats</pc> eat <pc copyOf="1">mice</pc>?  </target> </segment></unit>

Original data reference - holds the identifier of the<data> element that contains the original data for a given inline code.

Value description: An[XML Schema Datatypes] NMTOKEN that MUST be the value of theid attribute of one of the<data> element listed in the same<unit> element.

Default value: undefined.

Used in:<ph>,<sc>,<ec>.

Example:

<unit> <originalData>  <data>{0}</data> </originalData> <segment>  <source>Error in '<ph dataRef="d1"/>'.</source>  <target>Erreur dans '<ph dataRef="d1"/>'.</target> </segment></unit>

The example above shows a<ph> element that has its original data stored outside the content, in a<data> element.

Original data reference - holds the identifier of the<data> element that contains the original data for the end marker of a given inline code.

Value description: An[XML Schema Datatypes] NMTOKEN that MUST be the value of theid attribute of one of the<data> element listed in the same<unit> element.

Default value: undefined.

Used in:<pc>.

Example:

<unit> <originalData>  <data>&lt;EM></data>  <data>&lt;/EM></data> </originalData> <segment>  <source><pc dataRefStart="d1" dataRefEnd="d2">Efficiency<pc>is the operative word here.</source>  <target><pc dataRefStart="d1" dataRefEnd="d2">Efficacité<pc>est le mot clé ici.</target> </segment></unit>

The example above shows two<pc> elements with their original data stored outside the content, in two<data> elements.

Original data reference - holds the identifier of the<data> element that contains the original data for the start marker of a given inline code.

Value description: An[XML Schema Datatypes] NMTOKEN that MUST be the value of theid attribute of one of the<data> element listed in the same<unit> element.

Default value: undefined.

Used in:<pc>.

Example:

<unit> <originalData>  <data>&lt;EM></data>  <data>&lt;/EM></data> </originalData> <segment>  <source><pc dataRefStart="d1" dataRefEnd="d2">Efficiency</pc>is the operative word here.</source>  <target><pc dataRefStart="d1" dataRefEnd="d2">Efficacité</pc>est le mot clé ici.</target> </segment></unit>

The example above shows two<pc> elements with their original data stored outside the content, in two<data> elements.

Directionality - indicates the directionality of content.

Value description:ltr (Left-To-Right),rtl (Right-To-Left), orauto (determined heuristically, based on the first strong directional character in scope, see[UAX #9]).

Default value: default values for this attribute depend on the element in which it is used:

Used in:<data>,<pc>,<sc>, and<ec>.

Display text - holds an alternative user-friendly display representation of the original data of the inline code.

Value description: Text.

Default value: undefined

Used in:<ph>,<sc>,<ec>.

Example:

<unit> <originalData>  <data>{1}</data> </originalData> <segment> <source>Welcome back <ph disp="[UserName]" dataRef="d1"/>!</source> </segment></unit>

Display text - holds an alternative user-friendly display representation of the original data of the end marker of an inline code.

Value description: Text.

Default value: undefined

Used in:<pc>.

Example:

<unit> <originalData>  <data>\cf1\ul\b\f1\fs24 </data>  <data>\cf0\ulnone\b0\f0\fs22 </data> </originalData> <segment>  <source>Example of <pc dataRefStart="d1" dataRefEnd="d2"dispStart="&lt;span>" dispEnd="&lt;/span>">formattedtext</pc>.</source> </segment></unit>

In the example above, thedispStart anddispEnd attributes provide a more user-friendly representation of the original formatting codes.

Display text - holds an alternative user-friendly display representation of the original data of the start marker of an inline code.

Value description: Text.

Default value: undefined

Used in:<pc>.

Example:

<unit> <originalData>  <data>\cf1\ul\b\f1\fs24 </data>  <data>\cf0\ulnone\b0\f0\fs22 </data> </originalData> <segment>  <source>Example of <pc dataRefStart="d1" dataRefEnd="d2"dispStart="&lt;span>" dispEnd="&lt;/span>">formattedtext</pc>.</source> </segment></unit>

In the example above, thedispStart anddispEnd attributes provide a more user-friendly representation of the original formatting codes.

Equivalent text - holds a plain text representation of the original data of the inline code that can be used when generating a plain text representation of the content.

Value description: Text.

Default value: an empty string.

Used in:<ph>,<sc>,<ec>.

Example:

<unit> <originalData>  <data>&amp;</data> </originalData> <segment>  <source>Open <ph equiv="" dataRef="d1"/>File</source> </segment></unit>

In this example theequiv attribute of the<ph> element is used to indicate that the original data of the code can be ignored in the text representation of the string. This could, for instance, help a spell-checker tool to process the content as "Open File".

Equivalent text - holds a plain text representation of the original data of the end marker of an inline code that can be used when generating a plain text representation of the content.

Value description: Text.

Default value: an empty string

Used in:<pc>.

Example:

<unit> <originalData>  <data>&lt;span></data>  <data>&lt;/span></data> </originalData> <segment>  <source>The jam made of <pc dataRefStart="d1" equivStart=""dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source> </segment></unit>

Equivalent text - holds a plain text representation of the original data of the start marker of an inline code that can be used when generating a plain text representation of the content.

Value description: Text.

Default value: an empty string

Used in:<pc>.

Example:

<unit> <originalData>  <data>&lt;span></data>  <data>&lt;/span></data> </originalData> <segment>  <source>The jam made of <pc dataRefStart="d1" equivStart=""dataRefEnd="d2" equivEnd="">lingonberries</pc> is quite tasty.</source> </segment></unit>

Hexadecimal code point - holds the value of a Unicode code point that is invalid in XML.

Value description: A canonical representation of the hexBinary[XML Schema Datatypes] data type: Two hexadecimal digits to represent each octet of the Unicode code point. The allowed values are any of the values representing code points invalid in XML, between hexadecimal 0000 and 10FFFF (both included).

Default value: undefined

Used in:<cp>.

Example:

<cp hex="001A"/><cp hex="0003"/>

The example above shows a character U+001A and a character U+0003 as they have to be represented in XLIFF.

href - a pointer to the location of an external skeleton file pertaining to the enclosing<file> element..

Value description: IRI.

Default value: undefined

Used in:<skeleton>.

Identifier - a character string used to identify an element.

Value description: NMTOKEN. The scope of the values for this attribute depends on the element, in which it is used.

Default value: undefined

Used in:<file>,<group>,<unit>,<note>,<segment>,<ignorable>,<data>,<sc>,<ec>,<ph>,<pc>,<mrk> and<sm>.

Orphan code flag - indicates if the start or end marker of a spanning inline code is not in the same<unit> as its corresponding end or start code.

Value description:yes if this start or end code is not in the same<unit> as its corresponding end or start code,no if both codes are in the same<unit>.

Default value:no.

Used in:<sc>,<ec>.

Example:

   <file xmlns:abc="urn:abc">   <unit>     <mtc:matches>       <mtc:match ref="seg2">         <source><sc isolated="yes"/>Warning:</source>         <target><sc isolated="yes"/>Attention :</target>       </mtc:match>     </mtc:matches>     <segment>       <source><pc>Warning: File not found.</pc></source>     </segment>   </unit> </file>

In the example above the<sc> elements have theirisolated attribute set toyes because they do not have their corresponding<ec> elements.

Resource name - the original identifier of the resource corresponding to theExtracted<unit> or<group>.

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.

Value description: Text.

Default value: undefined.

Used in:<unit> and<group>.

target order - indicates the order, in which to compose the target content parts.

Value description: A positive integer.

Default value: implicit, see below

When order is not explicitly set, the<target>order corresponds to its sibling<source>, i.e. it is not being moved anywhere when composing target content of the enclosing<unit> and the implicitorder value is of that position within the<unit>.

Used in:<target>.

See theSegments Order section for the normative usage description.

Original file - a pointer to the location of the original document from which the content of the enclosing<file> element is extracted.

Value description: IRI.

Default value: undefined

Used in:<file>.

Priority - provides a way to prioritize notes.

Value description: Integer 1-10.

Default value:1

Used in:<note>.

Reference - holds a reference for the associated annotation.

Value description: A value of the[XML Schema Datatypes] type anyURI. The semantics of the value depends on the type of annotation:

Default value: undefined

Used in:<mrk> or<sm>.

Example:

<unit> <segment>  <source>The <pc>ref</pc> attribute of a termannotation holds a <mrk type="term"ref="http://dbpedia.org/page/Uniform_Resource_Identifier">URI</mrk>pointing to more information about the given term.</source> </segment></unit>

Source directionality - indicates the directionality of the source content.

Value description:ltr (Left-To-Right),rtl (Right-To-Left), , orauto (determined heuristically, based on the first strong directional character in scope, see[UAX #9]).

Default value: default values for this attribute depend on the element in which it is used:

Used in:<file>,<group>, and<unit>.

Source language - the code of the language, in which the text to beTranslated is expressed.

Value description: A language code as described in[BCP 47].

Default value: undefined

Used in:<xliff>.

Start code or marker reference - Theid of the<sc> element or the<sm> element a given<ec> element or<em> element corresponds.

Value description: NMTOKEN.

Default value: undefined

Used in:<ec>,<em>.

Example:

<unit> <segment>  <source><sc/>Bold, <sc/>both<ec startRef="1"/>,italics<ec startRef="2"/></source> </segment></unit>

State - indicates the state of the translation of a segment.

Value description: The value MUST be set to one of the following values:

One can further specify the state of theTranslation using thesubState attribute.

Default value:initial

Used in:<segment>

Sub-flows list - holds a list ofid attributes corresponding to the<unit> elements that contain the sub-flows for a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to theid attribute of a<unit> element.

Default value: undefined

Used in:<ph>,<sc>,<ec>.

Example:

See the example in theSub-Flows section.

Sub-flows list - holds a list ofid attributes corresponding to the<unit> elements that contain the sub-flows for the end marker of a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to theid attribute of a<unit> element.

Default value: undefined

Used in:<pc>.

Example:

See the example in theSub-Flows section.

Sub-flows list - holds a list ofid attributes corresponding to the<unit> elements that contain the sub-flows for the start marker of a given inline code.

Value description: A list of NMTOKEN values separated by spaces. Each value corresponds to theid attribute of a<unit> element.

Default value: undefined

Used in:<pc>.

Example:

See the example in theSub-Flows section.

subState - indicates a user-defined status for the<segment> element.

Value description:

The value is composed of a prefix and a sub-value separated by a character: (U+003A).

The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority.

The prefixxlf is reserved for this specification.

Other prefixes and sub-values MAY be defined by the users.

Default value: undefined

Used in:<segment>

subType - indicates the secondary level type of an inline code.

Value description:

The value is composed of a prefix and a sub-value separated by a character: (U+003A).

The prefix is a string uniquely identifying a collection of sub-values for a specific authority. The sub-value is any string value defined by the authority.

The prefixxlf is reserved for this specification, and the following sub-values are defined:

Other prefixes and sub-values MAY be defined by the users.

Default value: undefined

Used in:<pc>,<sc>,<ec> and<ph>

Target language - the code of the language, in which theTranslated text is expressed.

Value description: A language code as described in[BCP 47].

Default value: undefined

Used in:<xliff>.

Translate - indicates whether or not the source text in the scope of the giventranslate flag is intended forTranslation.

Value description:yes orno.

Default value: default values for this attribute depend on the element in which it is used:

Used in:<file><group><unit>,<mrk> and<sm>.

Target directionality - indicates the directionality of the target content.

Value description:ltr (Left-To-Right),rtl (Right-To-Left), orauto (determined heuristically, based on the first strong directional character in scope, see[UAX #9]).

Default value: default values for this attribute depend on the element in which it is used:

Used in:<file>,<group>, and<unit>.

Type - indicates the type of an element.

Value description: allowed values for this attribute depend on the element in which it is used.

Used in:<group>,<unit>,<pc>,<sc>,<ec>,<mrk>,<ph> and<sm>.

Value - holds a value for the associated annotation.

Value description: Text.

Default value: undefined

Used in:<mrk> and<sm>.

XLIFF Version - is used to specify the Version of theXLIFF Document. This corresponds to the Version number of the XLIFF specification that theXLIFF Document adheres to.

Value description: Text.

Default value: undefined

Used in:<xliff>.

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[BCP 47].

Default value: default values for this attribute depend on the element in which it is used:

Used in:<source>,<target> and where extension attributes are allowed.

White spaces - the xml:space attribute specifies how white spaces (ASCII spaces, tabs and line-breaks) are to be treated.

Value description:default orpreserve. The valuedefault signals that an application's default white-space processing modes are acceptable for this element; the valuepreserve 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. For more information seethe section on xml:space in the[XML] specification.

Default value: default values for this attribute depend on the element in which it is used:

Used in:<xliff>,<file>,<group>,<unit> and<data>.

Because the content represented in XLIFF can be extracted from anywhere, including software resources and other material that can contain control characters, XLIFF needs to be able to represent all Unicode code points[Unicode].

However, XML does not have the capability to represent all Unicode code points[Unicode], and does not provide any official mechanism to escape the forbidden code points.

To remedy this, the inline markup provides the<cp> element.

The syntax and semantic of<cp> in XLIFF are similar to the ones of<cp> in the Unicode Locale Data Markup Language[LDML].

Original code

Anoriginal code is a code that exists in the original document being extracted into XLIFF.

Added code

Anadded code is a code that does not exist in the original document, but has been added to the content at some point after extraction.

Standalone

Astandalone code is a code that corresponds to a single position in the content. An example of such code is the<br/> element in HTML.

Spanning

Aspanning code is a code that encloses a section of the content using a start and an end marker. There are two kinds of spanning codes:

• Codes that can overlap, that is: they can enclose a non-closing or a non-opening spanning code. Such codes do not have an XML-like behavior. For example the RTF code\b1...\b0 is a spanning code that is allowed to overlap.

• Codes that cannot overlap, that is: they cannot enclose a partial spanning code and have an XML-like behavior at the same time. An example of such code is the<emphasis>...</emphasis> element in DocBook.

When the opening or closing marker of a spanning code does not have its corresponding closing or opening marker in the same unit, it is anorphan code.

Spanning codes present a set of challenges in XLIFF:

First, because the code format of the original data extracted to XLIFF does not need to be XML, spanning codes can overlap.

For example, in the following RTF content, the format markers are in a sequence: start bold, start italics, end bold, end italics. This does not translate into a well-formed mapping.

Text in \b bold \i and\b0  italics\i0

Another challenge is the possible effect of segmentation: A spanning code can start in one segment and end in another.

For example, in the following HTML content, the segmentation splits the text independently of the codes so the starting and ending tags of the<B>...</B> element end up in different parts of the<unit> element:

[Sentence <B>one. ][Sentence two.][ ][Sentence</B> three.]

Finally, a third potential cause of complication is that the start or the end markers of a spanning code can become orphans if their segment is used outside of its original<unit>.

For example, an entry with bold text can be broken down into two segments:

Segment 1 = "<b>Warning found: "Segment 2 = "The file is read-only</b>"

And later, one of the segments can be re-used outside its original<unit>, for instance as a translation candidate:

New segment = "<b>Warning found - see log</b>"Fuzzy match = "<b>Warning found: "

Because of these use cases, the representation of a spanning code cannot always be mapped to a similar spanning element in XLIFF.

When taking into account these issues, the possible use cases and their corresponding XLIFF representations are as follow:

A spanning code MUST be represented using a<sc> element and a<ec> element if the code is not well-formed or orphan.

For example, the following RTF content has two spans of formatting:

Text in \b bold \i and\b0  italics\i0

They can only be represented using two pairs of<sc> and<ec> elements:

Text in <sc>\b </sc>bold <sc>\i </sc>and<ec startRef="1">\b0 </ec> italics <ec startRef="2">\i0</ec>

If the spanning code is well-formed it MAY be represented using either a single<pc> element or using a pair of<sc> and a<ec> elements.

For example, the following RTF content has a single span of formatting:

Text in \b bold\b0 .

It can be represented using either notations:

Text in <pc canOverlap="yes" dataRefStart="c1" dataRefEnd="c2">bold</pc>.

Text in <sc dataRef="c1"/>bold<ec startRef="1" dataRef="c2"/>.

Most of the time, inline codes correspond to an original construct in the format from which the content was extracted. This is theoriginal data.

XLIFF tries to abstract and normalize as much as possible the extracted content because this allows a better re-use of the material across projects. Some tools require access to the original data in order to create the translated document back into its original format. Others do not.

This <B>naked mole rat</B> is <B>pretty ugly</B>.

<unit> <segment>  <source>This <pc>naked mole rat</pc>is <pc>pretty ugly</pc>.</source>  <target>Cet <pc>hétérocéphale</pc>est <pc>plutôt laid</pc>.</target> </segment></unit>

This <B>naked mole rat</B> is <B>pretty ugly</B>.

<unit> <originalData>  <data>&lt;B></data>  <data>&lt;/B></data> </originalData> <segment>  <source>This <pc dataRefStart="d1" dataRefEnd="d2">    naked mole rat</pc> is <pc dataRefStart="d1" dataRefEnd="d2">    pretty ugly</pc>.</source>  <target>Cet <pc dataRefStart="d1" dataRefEnd="d2">    hétérocéphale</pc> est <pc dataRefStart="d1" dataRefEnd="d2">    plutôt laid</pc>.</target> </segment></unit>

When processing content, there are possible cases when new inline codes need to be added.

For example, in the following HTML help content, the text has the name of a button in bold:

Press the <b>Emergency Stop</b> buttonto interrupt the count-down sequence.

In the translated version, the original label needs to remain in English because the user interface, unlike the help, is not translated. However, for convenience, a translation is also provided and emphasized using another style. That new formatting needs to be added:

Appuyez sur le bouton <b>Emergency Stop</b> (<i>Arrêt d'urgence</i>)pour interrompre le compte à rebours.

Having to split a single formatted span of text into several separate parts during translation, can serve as another example. For instance, the following sentence in Swedish uses bold on the names of two animals:

Äter <b>katter möss</b>?

But the English translation separates the two names and therefore needs to duplicate the bold codes.

Do <b>cats</b> eat <b>mice</b>?

There are several ways to add codes:

<unit> <originalData>  <data>&lt;b></data>  <data>&lt;/b></data> </originalData> <segment>  <source>Äter <pc dataRefStart="d1" dataRefEnd="d2">kattermöss</pc>?</source>  <target>Do <pc dataRefStart="d1" dataRefEnd="d2">cats</pc>eat <pc dataRefStart="d1" dataRefEnd="d2">mice</pc>?</target> </segment></unit>

<unit> <segment>  <source>Esznek <pc>a magyarok svéd húsgombócot</pc>?</source>  <target>Do <pc>Hungarians</pc> eat <pc copyOf="1">Swedish meatballs</pc>?</target> </segment></unit>

<unit> <originalData>  <data>&lt;b></data>  <data>&lt;/b></data>  <data>&lt;i></data>  <data>&lt;/i></data> </originalData> <segment>  <source>Press the <pc dataRefStart="d1" dataRefEnd="d2">    Emergency Stop</pc> button to interrupt the count-down sequence.  </source>  <target>Appuyez sur le bouton    <pc dataRefStart="d1" dataRefEnd="d2">Emergency Stop</pc>    (<pc dataRefStart="n1" dataRefEnd="n2">Arrêt d'urgence</pc>)    pour interrompre le compte à rebours.  </target> </segment></unit>

# text property for the widget 'next'nextText: Click <ui>Next</ui>

<unit> <segment>  <source>Click &lt;ui>Next&lt;/ui></source> </segment></unit>

<unit> <originalData>  <data>&lt;ui></data>  <data>&lt;/ui></data> </originalData> <segment>  <source>Click <pc dataRefStart="d1" dataRefEnd="d2">Next</pc>  </source> </segment></unit>

When processing content, there are some possible cases when existing inline codes need to be removed.

For an example the translation of a sentence can result in grouping of several formatted parts into a single one. For instance, the following sentence in English uses bold on the names of two animals:

Do <b>cats</b> eat <b>mice</b>?

But the Swedish translation group the two names and therefore needs only a single bolded part.

Äter <b>katter möss</b>?

There are several ways to remove codes:

<unit> <originalData>  <data>&lt;i></data>  <data>&lt;/i></data> </originalData> <segment>  <source>I read <pc dataRefStart="d1" dataRefEnd="d2">LittleHouse on the Prairie</pc> to my children.</source>  <target>子供に「大草原の小さな家」を読みました。</target> </segment></unit>

<unit> <originalData>  <data>%s</data> </originalData> <segment>  <source>Cannot find '<ph dataRef="d1"/>'.</source> </segment></unit>

<unit> <segment>  <source>Cannot find '%s'.</source> </segment></unit>

XLIFF provides some information about what editing operations are applicable to inline codes:

<unit> <originalData>  <data>%s</data> </originalData> <segment>  <source>Can't open '<ph dataRef="d1" canCopy="no"      canDelete="no"/>'.</source> </segment></unit><unit> <originalData>  <data>%s</data>  <data>%d</data> </originalData> <segment>  <source>Number of <ph dataRef="d1" canCopy="no" canDelete="no"    canReorder="firstNo"/>:     <ph dataRef="d2" canCopy="no" canDelete="no" canReorder="no"/>.  </source> </segment></unit>

See theTarget Content Modification section for additional details on editing.

There are several pre-defined types of annotation and definition ofcustom types is also allowed.

He saw his <mrk translate="no">doppelgänger</mrk>.

He saw his <mrk translate="no" type="term">doppelgänger</mrk>.

   <file>   <unit>     <segment>       <source>He is my <mrk type="term"           ref="http://dbpedia.org/page/Doppelgänger">doppelgänger</mrk>.       </source>     </segment>   </unit> </file>

The <mrk type="comment" value="Possible values: Printer or Stacker"><ph dataRef="d1"/></mrk>has been enabled.

<unit> <notes>  <note appliesTo="target">Please check the translation for 'namespace'. On also can use 'espace de nom',but I think most technical manuals use the Englishterm.</note> </notes> <segment>  <source>You use your own namespace.</source>  <target>Vous pouvez utiliser votre propre <mrktype="comment" ref="#n1">namespace</mrk>.</target> </segment></unit>

One of the earliest surviving works of literature is<mrk type="myCorp:isbn" value="978-0-14-44919-8">The Epic of Gilgamesh</mrk>.

Annotations can overlap spanning inline codes or other annotations. They also can be split by segmentation. Because of this, a single annotation span can be represented using a pair of<sm> and<em> elements instead of a single<mrk> element.

For example, one can have the following content:

<unit> <segment>  <source>Sentence A. <mrk type="comment" value="Comment for B and C">Sentence B. Sentence C.</mrk></source> </segment></unit>

After a user agent performs segmentation, the annotation element<mrk> is changed to a pair of<sm> and<em> elements:

<unit> <segment>  <source>Sentence A. </source> </segment> <segment>  <source><sm type="comment" value="Comment for B and C"/>Sentence B. </source> </segment> <segment>  <source>Sentence C.<em startRef="m1"/></source> </segment></unit>

Constraints

• An inline code containing or delimiting one or more sub-flows MUST have an attributesubFlows that holds a list of the identifiers of the<unit> elements where the sub-flows are stored.

• Sub-flows MUST be in the same<file> element as the<unit> element from which they are referenced.

Processing Requirements

• Extractors SHOULD store each sub-flow in its own<unit> element.

• Extractors MAY order the<unit> elements of the sub-flows and the<unit> element, from where the sub-flows are referenced, as they see fit.

Note

Please note that the static structure encoded by<file>,<group>, and<unit> elements is principally immutable inXLIFF Documents and hence the unit order initially set by theExtractor will be preserved throughout the roundtrip even in the special case of sub-flows.

Processing Requirements

• For the inline content and all non empty inline elements: The white spaces MUST be preserved if the value forxml:space set or inherited at the enclosing<unit> level ispreserve, and they MAY be preserved if the value isdefault.

Warning

While processing isolated<ec> elements with explicitly set directionality, please beware that unlike directionality set on the<pc> and<sc> , this method decreases the stack level as per [UAX #9].

Note

Please note that this specification does not define explicit markup for inline directional Overrides or Embeddings; in case those are needed.Extractors andModifiers will need to use [UAX #9] defined Directional Formatting Characters.

When there is no existing target, the processing requirements for a given segment are the following:

When working with a segment with content already in the target,Writers MUST choose one of the three behaviors described below:

• Equality type A: Two contents are equal if their normalized forms are equal.

• Equality type B: Two contents are equal if, in their normalized forms and with all inline code markers replaced by the value of theirequiv attributes, the resulting strings are equal.

• The text nodes are in Unicode Normalized Form C defined in the Unicode Annex #15: Unicode Normalization Forms[UAX #15].

• All annotation markers are removed.

• All pairs of<sc> and<ec> elements that can be converted into a<pc> element, are converted.

• All adjacent text nodes are merged into a single text node.

• For all the text nodes with the white space property set todefault, all adjacent white spaces are collapsed into a single space.

Warning

WhenWriters set explicitorder on<target> elements, they have to check for conflicts with implicitorder, as<target> elements without explicitorder correspond to their sibling<source> elements. Beware that moving one<target> element is likely to cause a renumbering domino effect throughout the enclosing<unit> element.

Constraints

• Integrity of the inline codes MUST be preserved. See the section onInline Codes and onAnnotations for details.

• The entire source content of any one<unit> element MUST remain logically unchanged:<segment> elements or their data MUST NOT be moved or joined across units.

Warning

Note that when splitting or joining segments that have both source and target content it is advisable to keep the resulting segments linguistically aligned, which is likely to require human linguistic expertise and hence manual re-segmentation. If the linguistically correct alignment cannot be guaranteed, discarding the target content and retranslating the resulting source segments is worth considering.

Processing Requirements

• When theModifiers perform a split operation:

  • Only<segment> or<ignorable> elements that have theircanResegment value resolved toyes MAY be split.

  • All new<segment> or<ignorable> elements created and their<source> and<target> children MUST have the same attribute values as the original elements they were created from, as applicable, except for theid attributes and, possibly, for theorder,state andsubState attributes.

  • Any newid attributes MUST follow the<segment> or<ignorable>id constraints.

  • If there was a target content in the original segment and if thestate attribute of the original segment was notinitial, thestate attributes of the segments resulting from the split (and possibly their correspondingsubState attributes) MAY be changed to reflect the fact that the target content MAY need to be verified as the new segmentation MAY have desynchronized the alignment between the source and target contents.

• When theModifiers perform a join operation:

  • Only<segment> or<ignorable> elements that have theircanResegment value resolved toyes MAY be join with other elements.

• When theModifiers orMergers perform a join operation:

  • Two elements (<segment> or<ignorable>) MUST NOT be joined if their<target> have resolvedorder values that are not consecutive.

  • The attributes of the elements to be joined (<segment> or<ignorable>) and the attributes of their<source> and<target> MUST be carried over in the resulting joined elements.

  • If attributes of elements to be joined (<segment> or<ignorable>) differ, or if the attributes of their<source> or<target> differ, the resulting joined elements MUST comply with following rules:

    • If thestate attributes of the<segment> elements differ: thestate attribute of the joined<segment> MUST be set to the "earliest" of the values specified in the original<segment> elements. The sequence ofstate values are defined in the following order: 1:initial, 2:translated, 3:reviewed, and 4:final.

    • ThesubState attribute MUST be the one associated with thestate attribute selected to be used in the joined<segment>. If nosubState attribute is associated with thatstate, the joined<segment> MUST NOT have asubState.

    • If thexml:space attributes differ: The<source> and<target> of the joined element MUST be set toxml:space="preserve".

• When theModifiers orMergers perform a join or a split operation:

  • If any<segment> or<ignorable> element of the<unit> had a<target> child with anorder attribute prior to the segmentation modification, the<target> child of all<segment> and<ignorable> elements in the<unit> MUST be examined and if necessary theirorder attributes updated to preserve the ordering of the target content prior the segmentation modification.

For extensibility ofXLIFF Modules please refer to the relevant Module Sections.

• When using identifiers, an extension MUST use either an attribute namedid or the attributexml:id to specify them.

• Extensions identifiers MUST be unique within their immediate<file>,<group> or<unit> enclosing element.

• Identifier values used in extensions MUST be of typexs:NMTOKEN or compatible withxs:NMTOKEN (e.g.xs:NAME andxs:ID are compatible).

• A user extension, whether implemented using<mda:metadata> or using a custom namespace, MUST NOT provide the same functionality as an existing XLIFF core or module feature, however it MAY complement an extensible XLIFF core feature or module feature or provide a new functionality at the provided extension points.

• Mergers MUST NOT rely on custom namespace extensions, other than the ones possibly defined in<skeleton>, to create theTranslated version of the original document.

• Writers that do not support a given custom namespace based user extension SHOULD preserve that extension withoutModification.

5 The Modules Specifications

• Theid attribute is REQUIRED

• Thetype attribute is REQUIRED and set tomtc:match

• Theref attribute is not used.

• Thetranslate attribute is OPTIONAL

Legend:

<matches>|+---<match> +  |  +---<mda:metadata> ?  |  +---<xlf:originalData> ?  |  +---<xlf:source> 1  |  +---<xlf:target> 1  |  +---<other> *

Collection of matches retrieved from any leveraging system (MT, TM, etc.)

Contains:

A potential translation suggested for a part of the source content of the enclosing<unit> element.

Contains:

Attributes:

Identifier - a character string used to identify a<match> element.

Value description: NMTOKEN.

Default value: undefined

Used in:<match>.

Match quality - indicates the quality of the<target> child of a<match> element based on an external benchmark or metric.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in:<match>.

Match suitability - indicates the general suitability and relevance of its<match> element based on various external benchmarks or metrics pertaining to both the<source> and the<target> children of the<match>.

This attribute is intended to carry a value that can be combined from values provided insimilarity andmatchQuality attributes based on an externally provided algorithm.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in:<match>.

Match origin - indicates the tool, system or repository that generated a<match> element. This is a free text short informativedescription. For example, 'Microsoft Translator Hub' or 'tm-client123-v456', or 'MSTH(52217d25-d9e7-54a2-af44-3d4e4341d112_healthc).'

Value description: Text.

Default value: undefined

Used in:<match>.

Reference - points to a span of source text within the same unit, to which the translation candidate is relevant.

Value description: IRI

Default value: undefined

Used in:<match>.

Reference - indicates that the<target> child of the<match> element contains aTranslation into a reference language rather than into the target language. For example, a German translation can be used as reference by a Luxembourgish translator.

Value description:yes orno.

Default value:no.

Used in:<match>

Similarity - indicates the similarity level between the content of the<source> child of a<match> element and the translatable text being matched.

Value description: a decimal number between 0.0 and 100.0.

Default value: undefined

Used in:<match>.

Sub-type - indicates the sub-type, i.e. a secondary level type, of a<match> element.

Value description:

The value is composed of a prefix and a sub-value separated by a character : (U+003A). The prefix is a string uniquely identifying a collection of values for a specific authority. The sub-value is any string value defined by an authority.

The prefixxlf is reserved for this specification, but no sub-values are defined for it at this time. Other prefixes and sub-values MAY be defined by the users.

Used in:<match>

Type - indicates the type of a<match> element, it gives the value providing additional information on how the match was generated or qualifying further the relevance of the match. The list of pre-defined values is general and user-specific information can be added using thesubType attribute.

Value description:

Used in:<match>

Legend:

<glossary>|+---<glossEntry> +  |  +---<term> 1  |  +---<translation> *  |  +---<definition> ?  |  +---<other> *

Container for a list of glossary terms.

Contains:

Glossary entry.

Contains:

Attributes:

A term in the glossary, expressed in the source language of the enclosing<xliff> element.

Contains:

Attributes:

A translation of the sibling<term> element expressed in the target language of the enclosing<xliff> element. Multiple translations can be specified as synonyms.

Contains:

Attributes:

Optional definition in plain text for the term stored in the sibling<term> element.

Contains:

Attributes:

Identifier - a character string used to identify a<glossEntry> or<translation> element.

Value description: NMTOKEN

Default value: undefined

Used in:<glossEntry> and<translation>

Reference - points to a span of source or target text within the same unit, to which the glossary entry is relevant.

Value description: IRI

Default value: undefined

Used in:<glossEntry> and<translation>.

Source - indicates the origin of the content of the element where the attribute is defined.

Value description: Text.

Default value: undefined

Used in:<term>,<translation>, and<definition>.

Constraints

• The Format Style attributes MUST be configured in such a way that the HTML[HTML5] snippet resulting at the<file> level is valid.

Processing Requirements

• Extractors andEnrichers SHOULD use the following method to validate their HTML snippets:

  1. Parse the snippet with the[HTML5] fragment parsing algorithm, seehttp://www.w3.org/TR/html5/syntax.html#parsing-html-fragments.

  2. the result MUST be a valid DOM tree as per[HTML5], seehttp://www.w3.org/TR/html5/infrastructure.html#tree-order.

Note

The above constraint and validation method will make sure that the snippets are renderable bystandard HTML browsers.

Format style attribute, fs - allows most structural and inline XLIFF core elements to conveybasic formatting information using a predefined subset of HTML formatting elements (for example,HTML elements names like <script> are not included). It enables the generation of HTML pagesor snippets for preview and review purposes. If additional style information is needed, the OPTIONALsubFs attribute isprovided.

Value description: