xliiff: consolidated chnage proposals fro alt-trans

Hi all, 

I have combined the three sets of proposals for 
alt-trans enhancements made by myself and Magnus.

I have given Magnus a preview, and he agrees that 
this covers everything we want to do.

 

Mat

 

--------------------------------------------------------------------------------------------------------------------

 

Consolidated change proposals for alt-trans

 

Combining suggested changes 
from Matthew Lovatt and Magnus Martikainen.

 

 

Proposal 1: 

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

 

Details: 

It has been assumed that the 
<alt-trans> element is intended to contain translations that may be used 
to translate the parent target element, either by using the translation as-is, 
or by using the suggested translation as the starting point for translation.

 

Typically <alt-trans> 
elements will be generated from translation memory searches, or other fuzzy 
match mechanisms.

 

However, the 
<alt-trans> elements may also be of use for tracking previous 
translations, recording rejected translations, or may provide reference 
translations from related languages or from related translation projects.

 

A translation tool 
/translator needs to be able to identify that certain types of <alt-trans> 
elements are for informational purposes only, and may not be used for 
translation.

 

Finally, we require 
a mechanism to identify which (if any) <alt-trans> elements were used by 
translators during the translation process. Typically, this information is used 
to track the efficiency of the <alt-trans> generation process from 
fuzzy/machine matching.

 

The type attribute 
is to be optional, and is to have the following values and meanings:

  
  

    
      
Value

    
      
Meaning

  

    
      
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. 

 

Normally, a translator 
should only use <alt-trans> of type ‘proposal’ or ‘accepted’ when 
translating, all other types are ‘read-only’

Only type ‘proposal’ 
<alt-trans> elements may be promoted to ‘accepted’

 

Proposal 2: 

Deprecate 
the use of multiple <target> elements in a single 
<alt-trans>.

 
Details: 

Attributes that convey 
information about a specific <alt-trans> may need to be introduced on the 
<target> element rather than on the <alt-trans>. This causes the 
<target> element to have attributes that are used only when it appears 
inside an <alt-trans> - not when it appears in a <trans-unit>. That 
makes the <target> element unnecessarily complicated and overloaded with 
functionality.

 

Proposal 3: 

Deprecate 
the restype attribute for the <target> element.

 

Details: 

It should no longer be 
needed, as the <target> will always be of the same restype as the 
<trans-unit> or <alt-trans> it appears in.

 

Proposal 4: 

Introduce 
the phase-name attribute for <alt-trans>.

 
Details: 

The phase-name for an 
<alt-trans> with type=previous-version would indicate 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.

 

Proposal 5: 

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

 

 
Details: 

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.)