Implementation Option: <group> of <trans-unit>

[Magnus Martikainen <magnus@trados.com>]

Hi all,

 

This email kicks off the thread to discusses the pros and cons of representing segmentation in XLIFF through <group> of <trans-unit>, as originally suggested by Tony.

 

The idea is to use a special type of <group> to indicate where boundaries between <trans-unit> elements can be considered “soft” boundaries (i.e. they can be changed without affecting the ability to convert the file back to its original format) – in fact representing boundaries that are guaranteed to have no skeleton content between the <trans-unit>s.

 

Example:

 

<trans-unit id=”1”>

  <source xml:lang=”en”>First sentence.  Second sentence.</source>

</trans-unit>

 

Could be re-formatted as:

 

<group reformat=”trans-unit” id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First sentence.</source>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second sentence.</source>

  </trans-unit>

</group>

 

Which after translation could look like:

 

<group reformat=”trans-unit” id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First sentence.</source>

    <target xml:lang=”sv”>Första meningen.</target>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second sentence.</source>

    <target xml:lang=”sv”>Andra meningen.</target>

  </trans-unit>

</group>

 

Here is what I see as pro’s and con’s with this implementation:

Pros:

• All facilities of the <trans-unit> are available for segments.
• Reasonably close to functional compatibility with existing XLIFF specification. No new elements have been introduced. The functionality of existing elements has changed in a manner that mainly affects backward conversion (see Cons below).

 

Cons:

• Breaks functional compatibility with existing XLIFF, as one <trans-unit> can effectively be replaced by a <group>. This changes the meaning of <group> and <trans-unit> from the way they work in the current XLIFF implementation. This will be confusing, in particular as the <group> and <trans-unit> element names are the same.
• Functionality attached to the original <trans-unit> before it is split into a <group> cannot be represented without extending the <group> to also support things like <alt-trans> etc. Rather than extending the generic <group> in this way it would then seem natural to introduce a new element (e.g. <trans-unit-group>):

 

<trans-unit-group id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First sentence.</source>

    <target xml:lang=”sv”>Första meningen.</target>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second sentence.</source>

    <target xml:lang=”sv”>Andra meningen.</target>

  </trans-unit>

</trans-unit-group>

 

But as it turns out that the <trans-unit-group> will need all the functionality of the original <trans-unit>, would it not rather make sense to keep the <trans-unit> as it is today, and instead introduce a new element below it to represent the new functionality we want to introduce? The structure of the example below is exactly the same as the structure above, but we let the original <trans-unit> work as it does today (it will not need to be replaced by some type of group):

 

<trans-unit id=”1”>

  <segment>

    <source xml:lang=”en”>First sentence.</source>

    <target xml:lang=”sv”>Första meningen.</target>

  </segment>

  <segment>

    <source xml:lang=”en”>Second sentence.</source>

    <target xml:lang=”sv”>Andra meningen.</target>

  </segment>

</trans-unit>

 

• Difficulties arise when looking at how to handle <bpt>, <ept>, and <g> that span segment boundaries in the original <trans-unit>. This is an important issue that we will come across in almost all our representations.

 

 

Cheers,

Magnus