Proposal for Revision Tracking Mechanism in XLIFF

["Magnus Martikainen" <magnus@trados.com>]

Hi all,

 

According to my action item from the last meeting, here is my proposal for how revision tracking can be implemented in XLIFF.

 

1) Problem Statement:

Lacking a standard mechanism for tracking revisions for translations in an XLIFF document. The following information is of interest:

-          The actual changes introduced

-          Who made the changes

-          When they were implemented.

-          Which process/task this was part of

 

It is also desirable to be able to track the history and be able see more than one previous version.

All information except for the history and the actual changes made can be fully captured by using the phase mechanism in XLIFF (<phase> element and corresponding phase-name attributes).

 

2) Proposal:

My proposal on how to address this consists of several parts that work together. I propose to:

 

a) Recommend the use of <alt-trans> elements to store previous versions of <target> content in <trans-unit> elements.

The details of how to use this mechanism should be apparent from the rest of this proposal.

 

b) Add a “type” attribute for the <alt-trans> element.

This allows us to distinguish <alt-trans> elements representing previous versions from other types of <alt-trans> elements (e.g. representing translation memory matches).

The type attribute could have the following set of values:

• proposal – (default) the <alt-trans> represents a translation proposal from a translation memory or other resource.
• previous-version – the <alt-trans> represents a previous version of the <target> element.

This list could be extended in the future if we want to use <alt-trans> for other types of content.

 

It is left up to the tools to provide more information on why the content was updated (due to incorrect/rejected translations or for other reasons), e.g. by using <note> elements.

 

c) Introduce the “phase-name” attribute for <alt-trans>.

The phase-name for an <alt-trans> with type=”previous-version” would indicated which <phase> the change was introduced in. This makes it possible to find out who made the change, when, and which process the change was introduced in.

 

d) Introduce a convention: more recent <alt-trans> elements should appear before older ones.

This allows us to determine the order of changes if multiple previous versions have been introduced. (Even if the phase-name attribute can be used for this to some extent, sometimes changes may be introduced without adding a new <phase>. It is also possible that no phase-name attribute may have been specified for some versions. Or multiple versions could be introduced for the same phase-name.)

 

The type and phase-name attributes for the <alt-trans> could be introduced either in the main XLIFF namespace or in a recommended extension namespace.

 

Here is an example that illustrates the mechanism:

<trans-unit id="1" phase-name="Task4">

        <source>Plain body text.</source>

        <target phase-name="Task4">Vanlig brödtext.</target>

        <alt-trans type="previous-version" phase-name="Task4">

               <target phase-name="Task3">Helt vanlig brödtext.</target>

        </alt-trans>

        <alt-trans type="previous-version" phase-name="Task3">

               <target phase-name="Task2">Helt vanlig typisk brödtext.</target>

        </alt-trans>

</trans-unit>

 

In this example we can see that:

-          The name of the current phase for the trans-unit is “Task4” (from the phase-name on the <trans-unit> (this is a standard XLIFF mechanism that exists already today).

-          The current <target> content was changed during phase with name “Task4” (from the phase-name on the <target> element, which is also a standard XLIFF mechanism)

-          There are two previous versions of the <target> content (the two <alt-trans type=”previous-version”> elements)

-          The first version was created as part of the phase with name “Task2” (seen from the phase-name attribute on the <target> in the last <alt-trans>)

-          The first version was replaced during the phase with name “Task3” (seen from the phase-name attribute on the last <alt-trans>)

-          The second version was created as part of phase “Task3” (seen from the phase-name attribute on the <target> element in the first <alt-trans>)

-          The second version was replaced during phase “Task4” (seen from the phase-name attribute on the first <alt-trans>)

 

The detailed information about each phase should appear in <phase> elements in a <phase-group> in the <header>, as in normal XLIFF.

 

Best regards,

Magnus