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: 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?

 

  1. No, the extraction process should only create the source tag.

 

              <trans-unit id="16" datatype="plaintext">

                <source>Hospital Wide</source>

              </trans-unit>

 

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

 

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

 

 



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