OASIS XML Localisation Interchange File Format (XLIFF) TC

(sending Stephan's note to the list - I don't think he can post to the list (yet)) ________________________________________ From: Stephan Bohmig [sbohmig@wordbee.com] Sent: Monday, January 16, 2012 11:37 AM To: Dr. David Filip Cc: Schnabel, Bryan S; Rodolfo M. Raya; xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair Hi, Bryan gives a pertinent use case here. Since I was not able to follow the discussion from the beginning, this question may be redundant: * What is the rationale to not extend the standard to multilingual contents? I believe that nicely aligned multi lingual xliffs are beneficial for revision and proofreading tasks. It can also be helpful for consistency when e.g. an Italian translator gets in his xliff previously translated and approved Spanish texts. Thanks, Stephan Bohmig Wordbee On 16 janv. 2012, at 19:56, "Dr. David Filip" <David.Filip@ul.ie< mailto:David.Filip@ul.ie >> wrote: Bryan, thanks for providing this straw man.. Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 mobile: +353-86-049-34-68 facsimile: +353-6120-2734 mailto: david.filip@ul.ie< mailto:david.filip@ul.ie > On Fri, Jan 6, 2012 at 15:47, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com< mailto:bryan.s.schnabel@tektronix.com >> wrote: Hi all, I don’t have any real strong feelings on this issue. But I will offer a real world use case from the translation buyer perspective. In my company multilingual documents are pretty common. We use the multiple-bilingual-XLIFF-files approach that seems to be favored by most in this thread. I’m the one who writes and maintains the code on the client side to see that the XLIFF files reconnect in harmony at the conclusion of the translation cycle. For example for this file: <doc> <p lang=’en’ id=’e1’>Hello</p> <p lang=’de’ id=’d1’>xxxHello</p> <p lang=’fr’ id=’f1’>xxxHello</p> <p lang=’en’ id=’e2’>Goodbye</p> <p lang=’de’ id=’d2’>xxxGoodbye</p> <p lang=’fr’ id=’f2’>xxxGoodbye</p> </doc> We send out these files: de_hello-goodbye.xlf, fr_hello-goodbye.xlf And the CMS maintains hello-goodbye.config in order to weave the XLIFF files back together in the end. Of course this illustration is greatly simplified. It is not uncommon for this process to go sideways, usually due to some hiccup having to do with anomalies introduced into one of the files on the translation vendor side (again, in reality the files are large and complex). As a developer who supports the CMS translation workflow, multilingual XLIFF files would be very appealing. I think it would be much easier to detect a problem by parsing a single file, rather than needing to compare 20 15000-line files. Something like this would be nice: <xliff> <config target-lang=’de;fr’> <skel> <doc> <p lang=’en’ id=’e1’ /> <p lang=’de’ id=’d1’ /> <p lang=’fr’ id=’f1’ /> <p lang=’en’ id=’e2’ /> <p lang=’de’ id=’d2’ /> <p lang=’fr’ id=’f2’ /> </doc> </skel> </config> <file id=”d”> <unit idref='d1'> <s>Hello</s> <t>xxx</t> </unit> <unit idref='d2'> <s>Goodbye</s> <t>xxx</t> </unit> </file> <file id=”f”> <unit idref='f1'> <s>Hello</s> <t>xxx</t> </unit> <unit idref='f2'> <s>Goodbye</s> <t>xxx</t> </unit> </file> </xliff> So the question . . . would this approach be radically different and/or difficult to support by CAT tools and LSPs? I can support either way, so I have no strong feelings. For me the multilingual is merely a “nice-to-have” option. - Bryan ________________________________________ From: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > [xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org >] On Behalf Of Rodolfo M. Raya [rmraya@maxprograms.com< mailto:rmraya@maxprograms.com >] Sent: Friday, January 06, 2012 1:32 AM To: xliff@lists.oasis-open.org< mailto:xliff@lists.oasis-open.org > Subject: RE: [xliff] Uniqueness of language pair Hi, Translation packages and XLIFF documents are two different things. A package could be multilingual, have Dolby Surround sound, subtitles and 3D images. That's not an obstacle for XLIFF being just bilingual. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com< mailto:rmraya@maxprograms.com > Maxprograms http://www.maxprograms.com >

Hi Stephan, all, > Bryan gives a pertinent use case here. > Since I was not able to follow the discussion > from the beginning, this question may be redundant: > * What is the rationale to not extend the standard > to multilingual contents? > I believe that nicely aligned multi lingual xliffs > are beneficial for revision and proofreading tasks. Personally I think an XLIFF document should address only a bilingual case because that is the smallest unit we have to deal with. For example getting a multilingual XLIFF from a CMS system would force a lot of processing before we (i.e. an LSP) could dispatch it to the proper translators. And same thing in its way back. I think multilingual packages are perfectly fine, but they should be represented at the package level, in other words at a higher level than XLIFF. > It can also be helpful for consistency when e.g. > an Italian translator gets in his xliff previously > translated and approved Spanish texts. Having the user doing the Italian translation see the approved translation of the Spanish would need a major adjustment of the XLIFF tools to treat different translations as hints. Another way would be to have such translation hints provided using <alt-trans> and that is supported. Cheers, -yves

HI Yves, I am in total agreement with you. My view is that, like with the topic of inline elements, this is an attempt to impose on XLIFF a sub-optimal solution for a specific proprietary problem. This is exactly the kind of request that derailed XLIFF 1.2 and lead to the problems that we currently have. XLIFF should be kept as simple as possible. If you want to present various language translations then the answer is that you should aggregate multiple language XLIFF files in your application and not impose an unnecessary burden on XLIFF. Best Regards, Andrzej Zydron CTO XTM International   Tel:         +44 (0) 1753 480 469 Fax:        +44 (0) 1753 480 465 Mob:       +44 (0) 7966 477 181 email:     azydron@xtm-intl.com www:      http://www.xtm-intl.com Skype:    zydron This message contains confidential information and is intended only for the individual named. If you are not the named addressee you may not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Unless explicitly stated otherwise this message is provided for informational purposes only and should not be construed as a solicitation or offer. On 18/01/2012 07:48, Yves Savourel wrote: Hi Stephan, all, Bryan gives a pertinent use case here. Since I was not able to follow the discussion from the beginning, this question may be redundant: * What is the rationale to not extend the standard to multilingual contents? I believe that nicely aligned multi lingual xliffs are beneficial for revision and proofreading tasks. Personally I think an XLIFF document should address only a bilingual case because that is the smallest unit we have to deal with. For example getting a multilingual XLIFF from a CMS system would force a lot of processing before we (i.e. an LSP) could dispatch it to the proper translators. And same thing in its way back. I think multilingual packages are perfectly fine, but they should be represented at the package level, in other words at a higher level than XLIFF. It can also be helpful for consistency when e.g. an Italian translator gets in his xliff previously translated and approved Spanish texts. Having the user doing the Italian translation see the approved translation of the Spanish would need a major adjustment of the XLIFF tools to treat different translations as hints. Another way would be to have such translation hints provided using <alt-trans> and that is supported. Cheers, -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org