OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1. 

    Posted 02-07-2012 18:43
    Hi Yves, when I was referring to the overload of <group> in 1.2 spec I had this attribute in mind http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#merged-trans This is also what IN! are using for merging <trans-unit>s if segmentation does not fit. So if one of the uses of group is for merging trans-units, they cannot be blamed IMHO if they choose to use it with this semantics only. Group is an optional element that is potentially recursive but no guidance and/or processing requirements are given in the 1.2 spec, so they should be fine I guess in using it for just merging management.. Rgds dF PLEASE NOTE MY NEW MOBILE CONTACT! David Filip, Ph.D. ===================== cellphone: +353-86-0222-158 mailto: davidf@davidf.org Please use david.filip@ul.ie for LRC business www.davidf.org , http://www.linkedin.com/in/davidfatdavidf


  • 2.  RE:

    Posted 02-07-2012 21:18
    Hi David, > when I was referring to the overload of <group> in 1.2 spec > I had this attribute in mind > http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#merged-trans To me, this attribute (and equiv-trans) let you "fix" some bad structure of the initial extraction (for example a title that is broken down in two "paragraphs"), but it's not a way to deal with segmentation in general. > This is also what IN! are using for merging <trans-unit>s if segmentation does not fit. I don't think so. There is no reference to merged-trans (or equiv-trans) in XLIFF:doc. The definition of <group> in XLIFF:doc also specify that it has no attributes (mandatory or optional). > So if one of the uses of group is for merging trans-units, > they cannot be blamed IMHO if they choose to use it with this semantics only. > Group is an optional element that is potentially recursive > but no guidance and/or processing requirements are given > in the 1.2 spec, so they should be fine I guess in using > it for just merging management.. In any case using <trans-unit> for segmentation is not interoperable: a) simply because the segmentation representation is clearly defined in 1.2 and uses <seg-source>, not <group> and <trans-unit>. b) if you need to split a content (i.e. add a segment) you cannot: adding <trans-unit> elements won't work when merging things back (regardless of the usage of <group>) XLIFF:doc could use <seg-source>: the two only pure XLIFF attributes used in XLIFF:doc for <trans-unit> are id and translate. They could be mapped to mid and one extended attribute on <mrk> (and all extended attributes of <trans-unit> moved to <mrk>) This would provide the same functionality AND be interoperable. The problem I have with XLIFF:doc is that interoperability with a normal XLIFF tool is lost without a valid reason. All the features provided could be done without losing interoperability with the standard XLIFF. The argument of IN then will be: "But we don't care about interoperability with normal XLIFF because XLIFF:doc is meant to be used only with XLIFF:doc-enable tools" (there are many complex processing expectations). If that is the case then XLIFF:doc should not be promoted as an XLIFF solution. There is a very easy solution to leave XLIFF:doc as it is today (and even simplify it): make it a non-XLIFF document. Change the namespace. As a tool developer I see XLIFF and XLIFF:doc as two different formats: the processing expectations are vastly more complex and strict for XLIFF:doc, so it's easier to just treat it as a separate format anyway. Note also that regardless of the good intent of IN to develop this for a close set of tools, I know that one of those day I'll get an XLIFF:doc file and will have to send it to a translator that does not use MemoQ, GlobalSight or XTM, and some customer is going to say... but it's an XLIFF file why can't you work with it! And I'll be trying to explain him why it's not interoperable, and he'll summarize this as "Oh, so XLIFF is not really working then...". I could go on and on on the dangers of developing concurrent similar formats, but I have no time for that. The real long term solution for everybody is to make sure those XLIFF:doc features (most are excellent) are taken into account in 2.0 either in the core or as modules. And at some point XLIFF:doc v2 could be just a few additions on top of XLIFF 2.0. We might have been already close to that stage if all the energy spent on XLIFF:doc had been put on 2.0... Cheers, -yves


  • 3.  Re: [xliff-promotion] RE:

    Posted 02-07-2012 22:46
    Thanks for explaining, Yves, I agree with you on most points. I was just trying to be charitable in interpretation of their use of group. I agree that their trans-unit extensions break interoperability for no good reason..  Still, what would be the merged-trans attribute relation to your 2.0 segmentation solution? Isn't it a good opportunity to get rid of this overload? And I insist that an overload it is.. Rgds dF PLEASE NOTE MY NEW MOBILE CONTACT! Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Feb 7, 2012 at 21:18, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, > when I was referring to the overload of <group> in 1.2 spec > I had this attribute in mind > http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#merged-trans To me, this attribute (and equiv-trans) let you "fix" some bad structure of the initial extraction (for example a title that is broken down in two "paragraphs"), but it's not a way to deal with segmentation in general. > This is also what IN! are using for merging <trans-unit>s if segmentation does not fit. I don't think so. There is no reference to merged-trans (or equiv-trans) in XLIFF:doc. The definition of <group> in XLIFF:doc also specify that it has no attributes (mandatory or optional). > So if one of the uses of group is for merging trans-units, > they cannot be blamed IMHO if they choose to use it with this semantics only. > Group is an optional element that is potentially recursive > but no guidance and/or processing requirements are given > in the 1.2 spec, so they should be fine I guess in using > it for just merging management.. In any case using <trans-unit> for segmentation is not interoperable: a) simply because the segmentation representation is clearly defined in 1.2 and uses <seg-source>, not <group> and <trans-unit>. b) if you need to split a content (i.e. add a segment) you cannot: adding <trans-unit> elements won't work when merging things back (regardless of the usage of <group>) XLIFF:doc could use <seg-source>: the two only pure XLIFF attributes used in XLIFF:doc for <trans-unit> are id and translate. They could be mapped to mid and one extended attribute on <mrk> (and all extended attributes of <trans-unit> moved to <mrk>) This would provide the same functionality AND be interoperable. The problem I have with XLIFF:doc is that interoperability with a normal XLIFF tool is lost without a valid reason. All the features provided could be done without losing interoperability with the standard XLIFF. The argument of IN then will be: "But we don't care about interoperability with normal XLIFF because XLIFF:doc is meant to be used only with XLIFF:doc-enable tools" (there are many complex processing expectations). If that is the case then XLIFF:doc should not be promoted as an XLIFF solution. There is a very easy solution to leave XLIFF:doc as it is today (and even simplify it): make it a non-XLIFF document. Change the namespace. As a tool developer I see XLIFF and XLIFF:doc as two different formats: the processing expectations are vastly more complex and strict for XLIFF:doc, so it's easier to just treat it as a separate format anyway. Note also that regardless of the good intent of IN to develop this for a close set of tools, I know that one of those day I'll get an XLIFF:doc file and will have to send it to a translator that does not use MemoQ, GlobalSight or XTM, and some customer is going to say... but it's an XLIFF file why can't you work with it! And I'll be trying to explain him why it's not interoperable, and he'll summarize this as "Oh, so XLIFF is not really working then...". I could go on and on on the dangers of developing concurrent similar formats, but I have no time for that. The real long term solution for everybody is to make sure those XLIFF:doc features (most are excellent) are taken into account in 2.0 either in the core or as modules. And at some point XLIFF:doc v2 could be just a few additions on top of XLIFF 2.0. We might have been already close to that stage if all the energy spent on XLIFF:doc had been put on 2.0... Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-promotion-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-promotion-help@lists.oasis-open.org


  • 4.  RE: [xliff-promotion] RE:

    Posted 02-07-2012 23:31
    Indeed I suppose we will have to deal with merged-trans/equiv-trans for 2.0 at some point. But I don’t think it’s overlapping the segmentation feature we have today. It’s more to fix the cases when the structure of the original file breaks natural flows.   For example when a document has some title where the format is hard-coded with paragraph breaks. The source/target may need to be re-arranged.      Learning About XLIFF and Localization   Apprendre XLIFF Et la Localisation     -ys


  • 5.  RE: [xliff-promotion] RE:

    Posted 02-07-2012 23:31
    Indeed I suppose we will have to deal with merged-trans/equiv-trans for 2.0 at some point. But I don’t think it’s overlapping the segmentation feature we have today. It’s more to fix the cases when the structure of the original file breaks natural flows.   For example when a document has some title where the format is hard-coded with paragraph breaks. The source/target may need to be re-arranged.      Learning About XLIFF and Localization   Apprendre XLIFF Et la Localisation     -ys


  • 6.  Re: [xliff-promotion] RE:

    Posted 02-07-2012 22:46
    Thanks for explaining, Yves, I agree with you on most points. I was just trying to be charitable in interpretation of their use of group. I agree that their trans-unit extensions break interoperability for no good reason..  Still, what would be the merged-trans attribute relation to your 2.0 segmentation solution? Isn't it a good opportunity to get rid of this overload? And I insist that an overload it is.. Rgds dF PLEASE NOTE MY NEW MOBILE CONTACT! Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Tue, Feb 7, 2012 at 21:18, Yves Savourel < ysavourel@enlaso.com > wrote: Hi David, > when I was referring to the overload of <group> in 1.2 spec > I had this attribute in mind > http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#merged-trans To me, this attribute (and equiv-trans) let you "fix" some bad structure of the initial extraction (for example a title that is broken down in two "paragraphs"), but it's not a way to deal with segmentation in general. > This is also what IN! are using for merging <trans-unit>s if segmentation does not fit. I don't think so. There is no reference to merged-trans (or equiv-trans) in XLIFF:doc. The definition of <group> in XLIFF:doc also specify that it has no attributes (mandatory or optional). > So if one of the uses of group is for merging trans-units, > they cannot be blamed IMHO if they choose to use it with this semantics only. > Group is an optional element that is potentially recursive > but no guidance and/or processing requirements are given > in the 1.2 spec, so they should be fine I guess in using > it for just merging management.. In any case using <trans-unit> for segmentation is not interoperable: a) simply because the segmentation representation is clearly defined in 1.2 and uses <seg-source>, not <group> and <trans-unit>. b) if you need to split a content (i.e. add a segment) you cannot: adding <trans-unit> elements won't work when merging things back (regardless of the usage of <group>) XLIFF:doc could use <seg-source>: the two only pure XLIFF attributes used in XLIFF:doc for <trans-unit> are id and translate. They could be mapped to mid and one extended attribute on <mrk> (and all extended attributes of <trans-unit> moved to <mrk>) This would provide the same functionality AND be interoperable. The problem I have with XLIFF:doc is that interoperability with a normal XLIFF tool is lost without a valid reason. All the features provided could be done without losing interoperability with the standard XLIFF. The argument of IN then will be: "But we don't care about interoperability with normal XLIFF because XLIFF:doc is meant to be used only with XLIFF:doc-enable tools" (there are many complex processing expectations). If that is the case then XLIFF:doc should not be promoted as an XLIFF solution. There is a very easy solution to leave XLIFF:doc as it is today (and even simplify it): make it a non-XLIFF document. Change the namespace. As a tool developer I see XLIFF and XLIFF:doc as two different formats: the processing expectations are vastly more complex and strict for XLIFF:doc, so it's easier to just treat it as a separate format anyway. Note also that regardless of the good intent of IN to develop this for a close set of tools, I know that one of those day I'll get an XLIFF:doc file and will have to send it to a translator that does not use MemoQ, GlobalSight or XTM, and some customer is going to say... but it's an XLIFF file why can't you work with it! And I'll be trying to explain him why it's not interoperable, and he'll summarize this as "Oh, so XLIFF is not really working then...". I could go on and on on the dangers of developing concurrent similar formats, but I have no time for that. The real long term solution for everybody is to make sure those XLIFF:doc features (most are excellent) are taken into account in 2.0 either in the core or as modules. And at some point XLIFF:doc v2 could be just a few additions on top of XLIFF 2.0. We might have been already close to that stage if all the energy spent on XLIFF:doc had been put on 2.0... Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-promotion-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-promotion-help@lists.oasis-open.org