Proposal for extending alt-trans type attribute

["Matthew Lovatt" <matthew.lovatt@oracle.com>]

 Expanding on Magnus’s previous mail on using alt-trans to track revision changes, here is my proposal for how tracking alt-trans usage can be implemented in XLIFF.

 

I have used Magnus’s original mail as a template for this proposal.

The two proposals are related and may be combined together

 

1)       Problem Statement:

The alt-trans element is used for containing alternate translation of the source.

 

To enhance interoperability, we need a mechanism to indicate what type of alternate translation is stored within each alt-trans element, as an alt-trans may have different meaning/usage for different users

 

For example, an alt-trans may be:

a)      A Candidate translation

b)      A Rejected translation

c)      A Translation from a previous version of the software/documentation

d)      A Modified translation from a previous phase of the translation process

e)      A Translation from a related language

 

2)       Proposal:

My proposal to resolve this issue builds onto the original proposal from Magnus

 

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

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.

·         rejected – the <alt-trans> represents a rejected version of the <target> element.

·         reference- the <alt-trans> represents a translation to be used for reference purposes only, for example from a related product or a different language

·         accepted- the <alt-trans> represents a proposed translation that was used for the translation of the trans-unit, possibly modified. Only ‘proposal’ alt-trans elements may be promoted to ‘accepted’

 

 

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

 

3)       An optional note element may be associated with each alt-trans to capture more detail on each of these alt-trans types.

For example:

·         previous-version

Note may give details of previous version.

·         rejected

Note may give reasons for rejecting the translation.

·         reference

Note may indicate where this alt-trans came from, and why it is included for reference reasons

·         accepted

Note may give details of how/why the suggestion was changed before being used as the real translation

 

 

Mat