OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]