OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi, The attached zip file contains the following documents: - xliff_core_2.0 : updated XML Schema for XLIFF 2.0 - xliff_example.html : simple web page used for generating an example of XLIFF 2.0 - unsegmented.xlf : a basic XLIFF 2.0 representation of the example HTML file - segmentation1.xlf : a modified version of the previous file, with basic segmentation applied. - segmentation2.xlf : a modified version of the previous file, with improved segmentation applied. Main changes in the XML schema: - Removed <ignorable> element - Reintroduced <matches> as container - Added support for the "xml:space" attribute in <source> and <target> - Renamed <note> to <simpleNote> Possible change: add a holder element for <simpleNote> The example "segmentation2.xlf" shows one way of with untranslatable stuff without using the removed <ignorable> element. Regards, Rodolfo -- Rodolfo M. Raya <rmraya@maxprograms.com> Maxprograms http://www.maxprograms.com XLIFF20.zip

Thanks for the updated files and examples Rodolfo. I like very much the simpler mechanism to have translatable segments and non-translatable parts at the same level (rather than the non-translatable parts as elements inside the <segment> like before). But I would still make a semantic distinction between "segment" and "segment translate='no'" as used here. "Ignorable" (whatever the element name ends-up being ) as a concept is different from a segment. To me, the non-translatable/ignorable parts here are not segments they are inter-segments. I think the need to have their own element rather than overloading the semantic of <segment translate='no'>. A segment marked as translate='no' is a content that for some reason is non to be translated. If it is joined with another segment it probably should remain non-translatable. While the parts outside segments are content that are made non-translatable/ignorable by some segmentation and simplification mechanisms, basically to clean up the segment content. When joined with a segment such part becomes part of the segment content and is likely to become 'translatable'. For example, when you un-segment Rodolfo's example segmentation2.xlf you expect unsegmented.xlf. So in summary: - <segment> to store the segment (and some of those may be non-translatable) - <some-element-name> (<ignorable> was just fine for me) to store the parts outside the segments. Both at the same level, under <unit>. -ys

Hi Yves, We certainly need to differentiate between segments that should remain untranslatable, like a segment containing a product name, and something that is untranslatable because it's just structural content. We have two options: 1) Add a new attribute to <segment> to indicate it is untranslatable because it is structural, so we don't abuse of the proposed "translate" attribute. 2) Add an element with the same structure as <segment> as a possible child of <unit>. As you said, <ignorable> would be a fine name. Either approach is fine for me. Other opinions? 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 20, 2011 4:17 PM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Updated schema for XLIFF 2.0 plus examples > > Thanks for the updated files and examples Rodolfo. > > I like very much the simpler mechanism to have translatable segments and > non-translatable parts at the same level (rather than the non-translatable > parts as elements inside the <segment> like before). > > But I would still make a semantic distinction between "segment" and > "segment translate='no'" as used here. "Ignorable" (whatever the element > name ends-up being ) as a concept is different from a segment. > > To me, the non-translatable/ignorable parts here are not segments they are > inter-segments. I think the need to have their own element rather than > overloading the semantic of <segment translate='no'>. > > A segment marked as translate='no' is a content that for some reason is non > to be translated. If it is joined with another segment it probably should > remain non-translatable. > > While the parts outside segments are content that are made non- > translatable/ignorable by some segmentation and simplification mechanisms, > basically to clean up the segment content. When joined with a segment such > part becomes part of the segment content and is likely to become > 'translatable'. For example, when you un-segment Rodolfo's example > segmentation2.xlf you expect unsegmented.xlf. > > So in summary: > > - <segment> to store the segment (and some of those may be non- > translatable) > - <some-element-name> (<ignorable> was just fine for me) to store the > parts outside the segments. > > Both at the same level, under <unit>. > > -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

I like 2) better. Echo the opinion of Yves that <ignorable> would be better than overloading the <segment> element with both untranslatable content (appropriate, in my opinion) and structural (inappropriate, in my opinion).

- Bryan


Original Message-----
From: Rodolfo M. Raya [ mailto:rmraya@maxprograms.com ]
Sent: Wednesday, April 20, 2011 12:36 PM
To: 'Yves Savourel'; xliff@lists.oasis-open.org
Subject: RE: [xliff] Updated schema for XLIFF 2.0 plus examples

Hi Yves,

We certainly need to differentiate between segments that should remain untranslatable, like a segment containing a product name, and something that is untranslatable because it's just structural content.

We have two options:

1) Add a new attribute to <segment> to indicate it is untranslatable because it is structural, so we don't abuse of the proposed "translate" attribute.

2) Add an element with the same structure as <segment> as a possible child of <unit>. As you said, <ignorable> would be a fine name.

Either approach is fine for me. Other opinions?

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 20, 2011 4:17 PM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Updated schema for XLIFF 2.0 plus examples
>
> Thanks for the updated files and examples Rodolfo.
>
> I like very much the simpler mechanism to have translatable segments and
> non-translatable parts at the same level (rather than the non-translatable
> parts as elements inside the <segment> like before).
>
> But I would still make a semantic distinction between "segment" and
> "segment translate='no'" as used here. "Ignorable" (whatever the element
> name ends-up being ) as a concept is different from a segment.
>
> To me, the non-translatable/ignorable parts here are not segments they are
> inter-segments. I think the need to have their own element rather than
> overloading the semantic of <segment translate='no'>.
>
> A segment marked as translate='no' is a content that for some reason is non
> to be translated. If it is joined with another segment it probably should
> remain non-translatable.
>
> While the parts outside segments are content that are made non-
> translatable/ignorable by some segmentation and simplification mechanisms,
> basically to clean up the segment content. When joined with a segment such
> part becomes part of the segment content and is likely to become
> 'translatable'. For example, when you un-segment Rodolfo's example
> segmentation2.xlf you expect unsegmented.xlf.
>
> So in summary:
>
> - <segment> to store the segment (and some of those may be non-
> translatable)
> - <some-element-name> (<ignorable> was just fine for me) to store the
> parts outside the segments.
>
> Both at the same level, under <unit>.
>
> -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



---------------------------------------------------------------------
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

Please find attached another Schema update with the following changes: - Introduced <ignorable> as a child of <unit> - Introduced <notes> as container for <simpleNote> 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 20, 2011 4:17 PM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Updated schema for XLIFF 2.0 plus examples > > Thanks for the updated files and examples Rodolfo. > > I like very much the simpler mechanism to have translatable segments and > non-translatable parts at the same level (rather than the non-translatable > parts as elements inside the <segment> like before). > > But I would still make a semantic distinction between "segment" and > "segment translate='no'" as used here. "Ignorable" (whatever the element > name ends-up being ) as a concept is different from a segment. > > To me, the non-translatable/ignorable parts here are not segments they are > inter-segments. I think the need to have their own element rather than > overloading the semantic of <segment translate='no'>. > > A segment marked as translate='no' is a content that for some reason is non > to be translated. If it is joined with another segment it probably should > remain non-translatable. > > While the parts outside segments are content that are made non- > translatable/ignorable by some segmentation and simplification mechanisms, > basically to clean up the segment content. When joined with a segment such > part becomes part of the segment content and is likely to become > 'translatable'. For example, when you un-segment Rodolfo's example > segmentation2.xlf you expect unsegmented.xlf. > > So in summary: > > - <segment> to store the segment (and some of those may be non- > translatable) > - <some-element-name> (<ignorable> was just fine for me) to store the > parts outside the segments. > > Both at the same level, under <unit>. > > -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 xliff_core_2.0.xsd

> Please find attached another Schema update with the following changes: > - Introduced <ignorable> as a child of <unit> > - Introduced <notes> as container for <simpleNote> I've updated the latest snapshot of Rainbow to generate XLIFF 2.0 files based on the latest schema Rodolfo posted. http://okapi.opentag.com/snapshots cheers, -ys