Proposal for extending alt-trans type attribute

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