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?
- No, the extraction process
should only create the source tag.
<trans-unit id="16" datatype="plaintext">
<source>Hospital Wide</source>
</trans-unit>
- 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>
- 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
http://www.ektron.com