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