OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

xliiff: consolidated chnage proposals fro alt-trans

  • 1.  xliiff: consolidated chnage proposals fro alt-trans

    Posted 02-18-2005 09:09
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xliff message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

     

     



    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]