Title: Message
Hi
Doug,
You
did a really nice job showing the different ways of looking at this. I
really liked thinking about this.
But I
don't think this topic is one that lends itself to a best practice. I
think the answer to "should the extraction process create target elements" is
"it depends."
My
extraction process for my translation provider is a good
example.
Factors include whether it is a new translation, or an update to a
previous translation; whether the translation includes "boilerplate" material;
etc.
Here's
a mythical sample of an update to a previous translation:
<book>
<warranty state="boilerplate>Some warranty
here</warranty>
<chapter state="new">This is my first
chapter</chapter>
<chapter state="updated">In July we
said hello. Now in November we say
goodbye.</chapter>
</book>
We extract into
this XLIFF:
<t-u>
<source>Some warranty
here</source>
</t-u>
<!-- notice, no target. The translation provider
needs the source, let's say for context,
but is locked out of the
boilerplate -->
<t-u>
<source>This is my first
chapter</source>
<target>This is my first
chapter</target>
</t-u>
<!-- notice there is a target here.
The translation provider
finds it most efficient to type the translation directly into the target.
We find it best if they only
enter text, not
tags-->
<t-u>
<source>In July we said hello. Now in November we
say goodbye.</source>
<target>Es julio. Decimos
hola.</target>
</t-u>
<!-- our translation provider finds it useful to see the
previous translation,
even thought the text has
changed. They type over the previous
translation
with the new
translation. It seemed odd to me at first. But they insisted
this
helps
them -->
The practice of when to generate target elements was driven
more by our translation providers (each of whom are represented in the
TC), than by me as a
developer.
Don't think there is a best practice when contemplating
generating target elements as part of the extraction, any more than I think
there's a best practice when contemplating whether or not to use a skeleton
file. The answer to each, as I see it, seems to be, "it
depends."
Thanks for this thought provoking
topic,
Bryan
-----Original Message-----
From: Doug Domeny
[mailto:]
Sent: Thursday, March 09, 2006 7:16
AM
To:
Subject: [xliff] best
practice: should extraction process create target
elements?
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
