[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:
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]