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: RE: [xliff] best practice: should extraction process create target elements?

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.







-----Original Message-----
From: Doug Domeny [mailto:ddomeny@ektron.com]
Sent: 09 March 2006 15:16
To: xliff@lists.oasis-open.org
Subject: [xliff] best practice: should extraction process create target elements?




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>



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"/>



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>



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




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”.





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?




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]