RE: [xliff] Crossover aligned segments

["Rodolfo M. Raya" <rmraya@maxprograms.com>]

Hi Yves,

We could add an attribute to target, saying that it contains an integer number that starts in 1 and increments by one. We cannot validate that all numbers are present using an XML Schema, but we can validate quite easily using code to detect errors. I will update the schema draft with an "order" attribute if you agree.

Your comment about tools ignoring what they don't support is right, that is not harmless. Proper handling of XLIFF 2.0 would mean handling the order attribute and probably many more things. 

We still find tools in the market that include invalid XML characters in their XLIFF files. I know you too had to implement a tool for cleaning those characters. We can't do anything about that today and we can't predict what will happen when those tools claim support for XLIFF 2.0. 

Regards,
Rodolfo 
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Sunday, May 08, 2011 1:49 PM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Crossover aligned segments
> 
> Hi,
> 
> In the current segmentation representation proposal we have no provision
> for representing segments that are in different order in the source and the
> target.
> 
> This is something 1.2 allows. There are also more and more tools using
> human or on-the-fly alignments which need to preserve the "paragraph
> level" context (and therefore the order too).
> 
> So, while I do like the current proposed representation for 2.0, I think it is still
> important to allow crossover alignments.
> 
> 
> === A) The technical side:
> 
> I was wondering if anyone had some idea how to have both, probably using
> some optional attributes.
> 
> For example here is a 1.2 case where we have a crossover alignment:
> 
> <trans-unit id='1'>
>  <source>Segment 1. Segment 2.</source>
>  <seg-source><mrk mtype='seg' mid='1'>Segment 1. </mrk><seg
> mtype='seg' mid='2'>Segment 2.</mrk></seg-source>
>  <target><mrk mtype='seg' mid='2'>Translation 2. </mrk><seg mtype='seg'
> mid='1'>Translation 1.</mrk></target>
> </trans-unit>
> 
> Maybe the information could be provided with a simple attribute, giving the
> sequence in which the target segments (or <ignorable>) should be
> appended to provide the proper order when represented as the whole
> content of the unit:
> 
> <unit id='1' targetOrder="2,1">
>  <segment>
>   <source>Segment 1. </source>
>   <target>Translation 1.</target>
>  </segment>
>  <segment>
>   <source>Segment 2.</source>
>   <target>Translation 2. </target>
>  </segment>
> </unit>
> 
> 
> Another way would be to hold the information about the order in the target
> element:
> 
> <unit id='1'>
>  <segment>
>   <source>Segment 1. </source>
>   <target order='2'>Translation 1.</target>
>  </segment>
>  <segment>
>   <source>Segment 2.</source>
>   <target order='1'>Translation 2. </target>
>  </segment>
> </unit>
> 
> And if the order attribute is absent, the order is the same as for the source
> for that segment. This option would be a bit less "safe" as it may be a little bit
> more difficult to validate the values.
> 
> 
> === B) The core vs module side:
> 
> Assuming we found a representation, now comes the dilemma of the
> processing expectations:
> 
> Some tools don't support crossover alignments, so what should they do with
> targetOrder?
> 
> - just make sure they preserve it? But if they change the segmentation it
> invalidates the original targetOrder, so preserving is not really a good
> solution.
> 
> - detect it and generate and error because the document contains a
> feature/module the tool do not support?
> 
> This is really a general question about how tools not implementing some
> features need to handle files with those features. The "just ignore what you
> don't support" is not always harmless.
> 
> -ys
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php