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: Proposal to limit <alt-trans> to one <target> element

Hi all,


Following my action item from the meeting last Tuesday here is my proposal:


1) Problem Description:

The current XLIFF specification allows multiple <target> elements inside a single <alt-trans>. This has the following disadvantages:


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


I can think of two concrete examples where this applies:

i) The current restype attribute. In a <trans-unit> the <target> will always be the same restype as the <trans-unit>, but in an <alt-trans> with multiple <target> a different restype could be required for each of the <target> elements.

ii) The recently proposed “applied” attribute (see emails from Magnus and Matt), which is used to indicate which suggested translation was applied during translation, and any reasons it was changed. If multiple <target> elements are allowed in an <alt-trans> this attribute must be applied to the <target> element, rather than the <alt-trans>. But of course this attribute should not be used for <target> elements that appear in <trans-unit> elements.


b) Processing of the <alt-trans> content gets more complicated.

Tools processing the <alt-trans> would need additional processing to expect multiple <target> elements – it would not be possible to use the same algorithm as for <trans-unit>.


c) The same information can easily be represented by using separate <alt-trans> elements, one for each <target>, as in this example:



<target>(first suggested translation)</target>



<target>(second suggested translation)</target>



The only issue I can see with this is that this construct will occupy a little bit more space in the XLIFF file. But taking into consideration the unwanted side effects mentioned above I think that is a very small price to pay, in particular as it is likely to be a rather rare case.


2) Proposal:


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


This naturally leads to the following consequential proposals:


b) Deprecate the “restype” attribute for the <target> element.


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.


c) Assuming the suggested “applied” attribute is accepted, introduce it for the <alt-trans> element rather than for the <target> element.



Best regards,


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