XLIFF Version 2.2. Part 1: Core

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 the translated 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 its translation in the given Segmentation.

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>, <file> or <xliff> elements.

Contains:

Attributes:

Example:

<unit id="18">
  <notes>
    <note id="1" ref="#18-0">Change text to lower case</note>
  </notes>
  <segment state="initial" id="18-0">
    <source>Create Memories from Existing Translations</source>
  </segment>
</unit>        
    

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 id="1">
  <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 id="1">
  <originalData>
    <data id="d1">%d</data>
    <data id="d2">&lt;br/></data>
  </originalData>
  <segment>
    <source>Number of entries: <ph id="1" dataRef="d1" /><ph id="2"
        dataRef="d2"/>(These entries are only the ones matching the
        current 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 id="1">
  <originalData>
    <data id="1">&lt;B&gt;</data>
    <data id="2">&lt;/B&gt;</data>
  </originalData>
  <segment>
    <source><pc id="1" dataRefStart="1" dataRefEnd="2">Important</pc>
      text</source>
  </segment>
</unit>

Start of a spanning original code.

Contains:

Parents:

Attributes:

Example:

<unit id="1">
  <segment>
    <source><sc id="1" 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 id="1">
  <originalData>
    <data id="d1">\b </data>
    <data id="d2">\i </data>
    <data id="d3">\b0 </data>
    <data id="d4">\i0 </data>
  </originalData>
  <segment>
    <source>Text in <sc id="1" dataRef="d1"/>bold <sc id="2"
        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 the Annotations 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 well-formedness reasons.

Contains:

Parents:

Attributes:

See the Annotations 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 well-formedness reasons.

Contains:

Parents:

Attributes:

See the Annotations 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 or target.

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 or no.

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

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

Example:

<unit id="1">
  <originalData>
    <data id="1">\i1 </data>
    <data id="2">\i0 </data>
    <data id="3">{\b </data>
    <data id="4">}</data>
  </originalData>
  <segment>
    <source><pc id="1" dataRefStart="3" dataRefEnd="4" canOverlap="no">
        Bold, <sc id="2" 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. See Editing 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>.

For the normative Usage Description see Constraints and Processing Requirements in the Editing Hints section.

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

Value description: yes or no.

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 the id of the base code of a copied code.

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

Default value: undefined

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

Example:

<unit id="1">
  <segment>
    <source>Äter <pc id="1">katter möss</pc>?</source>
    <target>Do <pc id="1">cats</pc> eat <pc id="2" 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 the id attribute of one of the <data> element listed in the same <unit> element.

Default value: undefined.

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

Example:

<unit id="1">
  <originalData>
    <data id="d1">{0}</data>
  </originalData>
  <segment>
    <source>Error in '<ph id="1" dataRef="d1"/>'.</source>
    <target>Erreur dans '<ph id="1" 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 the id attribute of one of the <data> element listed in the same <unit> element.

Default value: undefined.

Used in: <pc>.

Example:

<unit id="1">
  <originalData>
    <data id="d1">&lt;EM></data>
    <data id="d2">&lt;/EM></data>
  </originalData>
  <segment>
    <source><pc id="1" dataRefStart="d1" dataRefEnd="d2">
        Efficiency</pc> is the operative word here.</source>
    <target><pc id="1" 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 the id attribute of one of the <data> element listed in the same <unit> element.

Default value: undefined.

Used in: <pc>.

Example:

<unit id="1">
  <originalData>
    <data id="d1">&lt;EM></data>
    <data id="d2">&lt;/EM></data>
  </originalData>
  <segment>
    <source><pc id="1" dataRefStart="d1" dataRefEnd="d2">
        Efficiency</pc> is the operative word here.</source>
    <target><pc id="1" 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), or auto (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 id="1">
  <originalData>
    <data id="d1">{1}</data>
  </originalData>
  <segment>
    <source>Welcome back <ph id="1" 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 id="1">
  <originalData>
    <data id="d1">\cf1\ul\b\f1\fs24 </data>
    <data id="d2">\cf0\ulnone\b0\f0\fs22 </data>
  </originalData>
  <segment>
    <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2"
        dispStart="&lt;span>" dispEnd="&lt;/span>">
        formatted text</pc>.</source>
  </segment>
</unit>

In the example above, the dispStart and dispEnd 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 id="1">
  <originalData>
    <data id="d1">\cf1\ul\b\f1\fs24 </data>
    <data id="d2">\cf0\ulnone\b0\f0\fs22 </data>
  </originalData>
  <segment>
    <source>Example of <pc id="1" dataRefStart="d1" dataRefEnd="d2"
        dispStart="&lt;span>" dispEnd="&lt;/span>">
        formatted text</pc>.</source>
  </segment>
</unit>

In the example above, the dispStart and dispEnd 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 id="1">
  <originalData>
    <data id="d1">&amp;</data>
  </originalData>
  <segment>
    <source>Open <ph id="1" equiv="" dataRef="d1"/>File</source>
  </segment>
</unit>

In this example the equiv 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 id="1">
  <originalData>
    <data id="d1">&lt;span class="link" onclick="linkTo('dbId5345')">
        </data>
    <data id="d2">&lt;/span></data>
  </originalData>
  <segment>
    <source>The jam made of <pc id="1" 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 id="1">
  <originalData>
    <data id="d1">&lt;span class="link" onclick="linkTo('dbId5345')">
        </data>
    <data id="d2">&lt;/span></data>
  </originalData>
  <segment>
    <source>The jam made of <pc id="1" 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.

Hyperlink reference - 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 id="f2" xmlns:abc="urn:abc">
  <unit id="1">
    <mtc:matches>
      <mtc:match id="tc01" ref="seg2">
        <source><sc id="1" isolated="yes"/>Warning:</source>
        <target><sc id="1" isolated="yes"/>Attention :</target>
      </mtc:match>
    </mtc:matches>
    <segment id="seg2">
      <source><pc id="1">Warning: File not found.</pc></source>
    </segment>
  </unit>
</file>

In the example above the <sc> elements have their isolated attribute set to yes because they do not have their corresponding <ec> elements.

Resource name - the original identifier of the resource corresponding to the extracted <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 implicit order value is of that position within the <unit>.

Used in: <target>.

See the Segments 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 element.

Value description: A value of the [XML Schema Datatypes] type anyURI. The semantics of the value depends on where the attribute is used:

Default value: undefined

Used in: <note>, <mrk> and <sm>.

Example:

<unit id="1">
  <segment>
    <source>The <pc id="1">ref</pc> attribute of a term
        annotation holds a <mrk id="m1" 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), , or auto (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 be translated is expressed.

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

Default value: undefined

Used in: <xliff>.

Start code or marker reference - The id 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 id="1">
  <segment>
    <source><sc id="1"/>Bold, <sc id="2"/>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:

The 4 defined states constitute a simple linear state machine that advances in the above given order. No particular workflow or process is prescribed, except that the three states more advanced than the default initial assume the existence of a translation within the segment. One can further specify the state of the translation using the subState attribute.

Default value: initial

Used in: <segment>

Sub-flows list - holds a list of id 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 the id attribute of a <unit> element.

Default value: undefined

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

Example:

See the example in the Sub-Flows section.

Sub-flows list - holds a list of id 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 the id attribute of a <unit> element.

Default value: undefined

Used in: <pc>.

Example:

See the example in the Sub-Flows section.

Sub-flows list - holds a list of id 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 the id attribute of a <unit> element.

Default value: undefined

Used in: <pc>.

Example:

See the example in the Sub-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 prefix xlf 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 prefix xlf 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 the translated 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 given translate flag is intended for translation.

Value description: yes or no.

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), or auto (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 the XLIFF Document. This corresponds to the version number of the XLIFF specification that the XLIFF document adheres to. For this specification, the version is 2.2.

Value description: 2.0, 2.1 or 2.2

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 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. For more information see the 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>, <source>, <target>, 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].

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:

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

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 id="1" canOverlap="yes" dataRefStart="c1" dataRefEnd="c2">
bold</pc>.

Text in <sc id="1" 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 the original 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 id="1">
  <segment>
    <source>This <pc id="1">naked mole rat</pc> is 
        <pc id="2">pretty ugly</pc>.</source>
    <target>Cet <pc id="1">hétérocéphale</pc> est 
        <pc id="2">plutôt laid</pc>.</target>
  </segment>
</unit>

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

<unit id="1">
  <originalData>
    <data id="d1">&lt;B></data>
    <data id="d2">&lt;/B></data>
  </originalData>
  <segment>
    <source>This <pc id="1" dataRefStart="d1" dataRefEnd="d2"> naked
        mole rat</pc> is <pc id="2" dataRefStart="d1"
        dataRefEnd="d2"> pretty ugly</pc>.</source>
    <target>Cet <pc id="1" dataRefStart="d1" dataRefEnd="d2">
        hétérocéphale</pc> est <pc id="2" 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> button
to 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 id="1">
  <originalData>
    <data id="d1">&lt;b></data>
    <data id="d2">&lt;/b></data>
  </originalData>
  <segment>
    <source>Äter <pc id="1" dataRefStart="d1" dataRefEnd="d2">katter
        möss</pc>?</source>
    <target>Do <pc id="1" dataRefStart="d1" dataRefEnd="d2">
        cats</pc> eat <pc id="2" dataRefStart="d1"
        dataRefEnd="d2">mice</pc>?</target>
  </segment>
</unit>

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

<unit id="1">
  <originalData>
    <data id="d1">&lt;b></data>
    <data id="d2">&lt;/b></data>
    <data id="n1">&lt;i></data>
    <data id="n2">&lt;/i></data>
  </originalData>
  <segment>
    <source>Press the <pc id="1" dataRefStart="d1" dataRefEnd="d2">
        Emergency Stop</pc> button to interrupt the count-down
        sequence. </source>
    <target>Appuyez sur le bouton <pc id="1" dataRefStart="d1"
        dataRefEnd="d2">Emergency Stop</pc> (<pc id="2"
        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 id="1">
  <segment>
    <source>Click &lt;ui>Next&lt;/ui></source>
  </segment>
</unit>

<unit id="1">
  <originalData>
    <data id="d1">&lt;ui></data>
    <data id="d2">&lt;/ui></data>
  </originalData>
  <segment>
    <source>Click <pc id="1" 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 id="1">
  <originalData>
    <data id="d1">&lt;i></data>
    <data id="d2">&lt;/i></data>
  </originalData>
  <segment>
    <source>I read <pc id="1" dataRefStart="d1" dataRefEnd="d2">Little
        House on the Prairie</pc> to my children.</source>
    <target>子供に「大草原の小さな家」を読みました。</target>
  </segment>
</unit>

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

<unit id="1">
  <segment>
    <source>Cannot find '%s'.</source>
  </segment>
</unit>

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

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

See the Target Content Modification section for additional details on editing.

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

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

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

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

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

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

One of the earliest surviving works of literature is
<mrk id="m1" 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 id="1">
  <segment>
    <source>Sentence A. <mrk id="m1" 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 id="1">
  <segment>
    <source>Sentence A. </source>
  </segment>
  <segment>
    <source><sm id="m1" type="comment" value="Comment for B and C"/>
        Sentence B. </source>
  </segment>
  <segment>
    <source>Sentence C.<em startRef="m1"/></source>
  </segment>
</unit>

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:

For extensibility of XLIFF Modules please refer to the relevant Module Sections.