RE: [xliff] XLIFF 2.0 Core

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

Hi,

The attached XML Schema drafts what I have in mind for a translation unit. In plain text, my initial proposal would be:

------------------------------------------------------
<unit> : extracted translatable text.

Contains:

 - One or more <segment> elements
------------------------------------------------------

<segment> : minimum portion of translatable text

Contains:

- Zero, one or more <ignorable> elements followed by
- One <source> element followed by
- Zero or one <target> element followed by
- Zero, one or more <ignorable> elements followed by
- Zero, one or more <note> elements followed by
- Zero or one <matches> element
------------------------------------------------------

<ignorable> : white space of formatting information that needs to be preserved but does not need to be modified/translated

Contains:

- White space
- Elements used to store inline markup
------------------------------------------------------

<matches> :  collection of matches retrieved from any system (MT, TM, etc.)

Contains:

- One or more <match> elements
------------------------------------------------------

<match> a potential translation suggested for the enclosing <segment> element

Contains:

- One <source> element followed by
- One <target> element
------------------------------------------------------

<note> : a comment that contains information about <source>, <target> or <segment>

Contains:

- Text
------------------------------------------------------

<source> portion of text to be translated

Contains:

-Text
- Elements used to store inline markup
------------------------------------------------------

<target> the translation of the sibbling <source> element

Contains:

-Text
- Elements used to store inline markup
------------------------------------------------------



The attached picture (unit_schema.jpg) may help in understanding the proposal.

The <matches> element is not really necessary and can be discarded. It only serves to keep some order.

If we agree on this draft, we will have to add attributes.

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


> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Wednesday, April 06, 2011 10:19 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 Core
> 
> Hi Rodolfo,
> 
> Using a "unit > segment > language" structure looks ok to me. It is one of the
> two representations I was thinking about.
> 
> It does have the advantage to make the segment id un-necessary. Simpler is
> better.
> We may have to think a bit about tools that allow cross-aligned segments,
> but that can possibly be resolved with an optional id.
> 
> The scenario you are describing is a good use case and I agree with the
> example of process: Segmentation change is one of the modifications the
> merging tool should be able to handle.
> 
> I also concur that clear definitions of the different parts are important.
> 
> 
> > The example described above could be improved by adding optional
> > elements between segments that would hold stuff we don't want
> > translators to see, like the spaces at the start of a sentence
> > or perhaps some formatting that applies to the whole sentence.
> 
> +1
> 
> So, yes Rodolfo, we basically agree.
> 
> -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

unit_schema.jpg

unit.xsd