A tricky problem for handling in XLIFF

["Matthew Lovatt" <matthew.lovatt@oracle.com>]

In our last meeting, I mentioned that I had encountered a difficult problem for XLIFF.

This issue was actually raised once before
http://lists.oasis-open.org/archives/xliff-comment/200303/msg00000.html
But I think the issue does raise further discussion
So here are the details

Here is an XML document to be translated using XLIFF

<?xml version="1.0"?>
<ovpxml version="1.0" xml:lang="en-us">

  <prompt id="WELCOME">
    Welcome to the Oracle Messaging Centre.
  </prompt>

  <prompt id="DELETE_MESSAGE">
    <var name="key" type="phoneKey"/>
    To delete the message, press <varref name="key"/>.
  </prompt>

  <prompt id="MESSAGE_RECEIVED">
   <var name="timeReceived" type="dateTime"/>
    The message was received at <varref name="timeReceived" mask="hmA"/>.
  </prompt>

  <prompt id="YOU_HAVE_MESSAGE">
    <var name="numVM" type="integer"/>
    <choose>
      <when test="numVM==0">
        You have no new messages.
      </when>
      <when test="numVM==1"/>
        You have one new message.
      </when>
      <otherwise>
        You have <varref name="numVM"/> new messages.
      </otherwise>
    </choose>
  </prompt>

</ovpxml>

(FYI, after the strings are translated, Actors will record these phrases in audio files, and the files are played over the phone when connecting to a voice messaging system)

There are four prompts

1) id="WELCOME"
This is easy and causes no problems

2) id="DELETE_MESSAGE"

    This is also easy.
   
    But note the <var> and <varref> elements.
    At run time, the application can specify different phone keys

 

    E.G

    In US English

        To delete the message, press pound

    In Real(!) English

        To delete the message, press hash

3)id="MESSAGE_RECEIVED"

    This is slightly trickier, in that the translated prompt needs to modify the text and the mark-up.

    For Example
        <prompt id="MESSAGE_RECEIVED">
          <var name="timeReceived" type="dateTime"/>
          Le message a été reçu à <varref name="timeReceived" mask="Hm"/>.
        </prompt>

    Note that in the translation, the mask attribute has changed due to different linguistic requirements

4) id="YOU_HAVE_MESSAGE"

This is the killer problem!

First note that the designers of the file format have 'borrowed' the choose/when/otherwise structures from XSLT.

I quite like this idea.

We are bound to encounter similar scenarios in certain file types, and while we may encounter different usages, should we recommend incorporating XSLT structures into XLIFF when processing such scenarios?

For example, John mentioned that Java Resource bundles can have a similar mechanism. Should we use xslt elements to represent them?

But the real problem comes when we examine what is returned from translation.

<prompt id="YOU_HAVE_MESSAGE">
  <var name="numVM" type="integer"/>
  <choose>
    <when test="numVM=0">
      Nie masz nowych wiadomości
    </when>
    <when test="numVM=1"/>
      Masz jedną nową wiadomość
    </when>
    <when test="numVM<5"/>
      Masz <varref name="numVM" variant="feminine_accusative"/> nowe wiadomości
    </when>
    <when test="numVM<21"/>
      Masz <varref name="numVM" variant="feminine_accusative"/> nowych wiadomości
    </when>
    <when test="in(numVM % 10, [2,3,4])"/>
      Masz <varref name="numVM" variant="feminine_accusative"/> nowe wiadomości
    </when>
    <otherwise>
      Masz <varref name="numVM" variant="feminine_accusative"/> nowych wiadomości
    </otherwise>
  </choose>
</prompt>

There are three choices in the US English file, but six choices in the Polish Translation!

So how can we segment the prompt into trans-units

I see several options, none of which are simple

1) We can drop the entire prompt element into a single trans-unit, embed the OVPXML mark up in the source and target, and pass the OVPXML schema to translators to ensure they correctly modify the mark up.


2) we can segment on each option, incorporating the test condition into the id.
This means that the editing tool will need to add trans-units for the new conditions

3) We could permit multiple targets in each trans-unit, with different conditions for different targets

4) Since there is actually a many to many relationship between sources and targets, we could produce trans-units with only source, or only target, and implement a relationship map between related trans-unit

So From the above, you will deduce that the problem is rather complex, and that I am stuck.

 

We need to be able to translate these structures, validate the modified markup during transaltion , and be able to resue as much of the translation in subsequent versions of the files.

 

For example, if the second version of the file is different in one of the choose elements, how much of the original file can we reuse, and how much needs retranslation.

For our first pass at implementing this file (In XLIFF 1.0), I think I will go with option 1.

But if anyone has any better ideas, please let me know.

 

Mat