[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] best practice: should extraction process create target elements?
Tony, Thanks for your consideration. Discussing
it as new business at the next conference call is a good idea. Brian’s
comments dated 9 March explained the different scenarios quite well. For me, I’ve
decided to not create the <target> element when creating a new trans-unit
rather than copying the original language. From: Tony
Jewtushenko [mailto:tony.jewtushenko@productinnovator.com] Hi Doug: This is a good discussion
but I’d rather we discussed this in the next TC conference before setting
up a ballot. I would like the TC to focus as exclusively as possible on
getting the 1.2 work finished and approved. I have misgivings about
extending scope in any way at this point unless it’s absolutely critical. I’ll put this on
the next TC agenda and encourage further mailing list discussion on this topic. Regards, Tony -----Original Message----- All, As most of you have probably guessed
by now, Rodolfo and I have been ironing out some interoperability issues
between the XLIFF produced by the Ektron CMS and the Heartsome XLIFF editor. As
a result, I have a question of best practice. Tony, would it be appropriate to
have an online vote on this? Should the extraction process create
a target element with a copy of the source in it? 1. No, the
extraction process should only create the source tag.
<trans-unit id="16" datatype="plaintext">
<source>Hospital Wide</source>
</trans-unit> 2. Yes, but the
target should be empty and the state=”needs-translation”.
<trans-unit id="16" datatype="plaintext">
<source>Hospital Wide</source>
<target state="needs-translation"/>
</trans-unit> 3. Yes, the
target should be a copy of the source and the
state=”needs-translation”.
<trans-unit id="16" datatype="plaintext">
<source>Hospital Wide</source>
<target state="needs-translation">Hospital Wide</target>
</trans-unit> Once a decision is made, I recommend
that the XLIFF 1.2 specification be modified to state the recommended practice.
The segmentation section is clear in that is states: “It is important to note that
the manipulation / segmentation of trans-unit elements is owned by the
"translator" domain, not at the extraction filter domain. This means
that segmentation will be performed by the editing tool or possibly an
automated segmentation process.” I’m willing to draft the
changes once the best practice is determined. Here are my thoughts on it so far. PROPOSITION: No target element when
extracting PROS 1. Easier to visually see which
trans-units (TUs) have been translated and which need to be translated. 2. It would reduce the size of the
XLIFF file after the extraction process. 3. XLIFF editors would know
translation is needed (no target tag) without checking for
state=”needs-translation”. CONS 1. Translator wishing to ‘type
over’ the original so as to retain inline tags would need to copy source,
which may be easy in the XLIFF editor. However, if this is required most of the
time, it would be better to avoid this step. Of course, the XLIFF editor could
automatically copy. 2. Translator would need to copy
from source to target in order to keep source that is the same when translated,
such as with a proper name. 3. If trans-unit (TU) is skipped or
XLIFF is merged without translating (e.g., when testing), then the merge
process would need to replace with source or skeleton, which is probably a good
idea anyhow. While researching, I found that the
open-language-tools subsegmenter utility states: “The XLIFF SubSegmenter takes
an existing XLIFF, segmented at the paragraph level, and re-segments it to
sentence level. Of course, the incoming XLIFF file must only contain source
segments - it doesn't do any complex source/target sentence-alignment
functionality.” Given this, I’m definitely
leaning toward creating just the source element during extraction. I guess the
thing that threw me was the “needs-translation” state. Is the
“needs-translation” state redundant? Should it be deprecated? Regards, Doug Domeny Software Analyst Ektron, Inc. +1 603 594-0249 x212 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]