OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  

Hi Rodolfo,   I absolutely agree that only having one pair of source and target languages per Xliff document is a good idea. Allowing one per <file> is just confusing for the end users, introduces partial failure modes or complicates the implementation of some type of tools.   Regards, Fredrik Estreen   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya Sent: den 5 januari 2012 12:31 To: xliff@lists.oasis-open.org Subject: [xliff] Uniqueness of language pair   Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  

Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..] Rgds dF 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 On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  

> I think that it makes perfect sense to set > language pair uniqueness constraint at > the file level. David: Just to clarify, when you say "file" do you mean at the <file> element or at the "document" (<xliff> element)? I assume: <xliff> level. And I agree with Rodolfo/Fredrik too. -yves

Hi Yves, sorry for confusion. Although I as most of you do support XLIFF staying bilingual. I was looking into a way how to implement the business need for multilingual project bulk exchange, so I proposed to enforce the bilinguality at the <file> level rather than <xliff> level, so that <xliff> can become a collection of <file> level elements of arbitrary source and target combinations. I think this would be a sound implementation of multilingualism in xliff, although we would need to handle overload and processing carefully. Wordbee who would push for this need are a cloud based TMS provider, and I gues they might be seconded by a large publisher such as Adobe or MS. I am not sure about IBM or Oracle, please do chime in guys! I think (from my own experience) that LSP for most do not like to work with multilingual files. It can be done but is tricky, and the issue is that as matter of fact it usually is not well thought through by the client who owns the format and ends up in a lot of messy manual sorting and version controlling.. But this again might be a point for developing a blueprint ho wthis can be done properly.. Thanks and regards dF 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 On Thu, Jan 5, 2012 at 21:11, Yves Savourel < ysavourel@enlaso.com > wrote: > I think that it makes perfect sense to set > language pair uniqueness constraint at > the file level. David: Just to clarify, when you say "file" do you mean at the <file> element or at the "document" (<xliff> element)? I assume: <xliff> level. And I agree with Rodolfo/Fredrik too. -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

For IBM, bilingual at the <xliff> level is sufficient.  Each language would get a separate set of XLIFF files to translate, so there is no reason to include multilingual capability within an XLIFF file.  A multilingual file would actually complicate the process flow. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Dr. David Filip" ---01/05/2012 08:04:21 PM---Hi Yves, sorry for confusion. Although I as most of you do support XLIFF staying bilingual. From: "Dr. David Filip" <David.Filip@ul.ie> To: Yves Savourel <ysavourel@enlaso.com> Cc: xliff@lists.oasis-open.org Date: 01/05/2012 08:04 PM Subject: Re: [xliff] Uniqueness of language pair Sent by: <xliff@lists.oasis-open.org> Hi Yves, sorry for confusion. Although I as most of you do support XLIFF staying bilingual. I was looking into a way how to implement the business need for multilingual project bulk exchange, so I proposed to enforce the bilinguality at the <file> level rather than <xliff> level, so that <xliff> can become a collection of <file> level elements of arbitrary source and target combinations. I think this would be a sound implementation of multilingualism in xliff, although we would need to handle overload and processing carefully. Wordbee who would push for this need are a cloud based TMS provider, and I gues they might be seconded by a large publisher such as Adobe or MS. I am not sure about IBM or Oracle, please do chime in guys! I think (from my own experience) that LSP for most do not like to work with multilingual files. It can be done but is tricky, and the issue is that as matter of fact it usually is not well thought through by the client who owns the format and ends up in a lot of messy manual sorting and version controlling.. But this again might be a point for developing a blueprint ho wthis can be done properly.. Thanks and regards dF 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 On Thu, Jan 5, 2012 at 21:11, Yves Savourel < ysavourel@enlaso.com > wrote: > I think that it makes perfect sense to set > language pair uniqueness constraint at > the file level. David: Just to clarify, when you say "file" do you mean at the <file> element or at the "document" (<xliff> element)? I assume: <xliff> level. And I agree with Rodolfo/Fredrik too. -yves --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

  Hi David,   If we opt for having multilingual XLIFF files, there is no reason for not allowing their use in translation editors.   Editing a multilingual XLIFF file should be as easy as editing a bilingual file for the end user. Designing an editor that can handle multilingual files is not a trivial task but can be done.   As developer of XLIFF editors, I certainly prefer XLIFF files to be bilingual. Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   The wiki has a feature request for “Ability to store Multilingual Content” (item 2.12 in the feature tracking page). It is not clear how this can be achieved and there is no proposal for implementation.   Perhaps we should vote whether we want bilingual or multilingual files in next meeting and send this pending item to section 1) or 3). If it goes to section 1), we need to start working right now on how multilingualism will be implemented in XLIFF 2.0 because that affects the elements we define. It would not be the same to have multiple <file> elements, each one with its own language pair, than to have a single <file> and multiple <target> elements per segment.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip Sent: Thursday, January 05, 2012 6:38 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..]   Rgds dF   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 On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com    

Hi Rodolfo,   > Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   No, I do not think so. The added synchronization complexity would not fit well into workflows. We would actually (see Fredrik’s comment earlier today) prefer a bilingual standard.   Regards, Joachim

>> Nevertheless, I admit that language service >> providers may prefer multilingual XLIFF >> documents. > > No, I do not think so. The added synchronization > complexity would not fit well into workflows. > We would actually (see Fredrik’s comment earlier > today) prefer a bilingual standard. +1 for bilingual. I think LSPs do not want to get multilingual files and have few or no reason to send such files: they cause more troubles than they resolve. -ys

Thanks Rodolfo, I would first try and find a champion for this feature. If such a champion is found I would give him/her some time for thinking of possible implementations. If a champion is not found soon, the feature should be moved  to 3, but next meting might be to quick, IMHO. I would expect the champion to be a large publisher or a cloud based TMS provider, if anyone at all. We might be able to bring Stephan from Wordbee to the table after all.. Rgds dF 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 On Thu, Jan 5, 2012 at 21:23, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:   Hi David,   If we opt for having multilingual XLIFF files, there is no reason for not allowing their use in translation editors.   Editing a multilingual XLIFF file should be as easy as editing a bilingual file for the end user. Designing an editor that can handle multilingual files is not a trivial task but can be done.   As developer of XLIFF editors, I certainly prefer XLIFF files to be bilingual. Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   The wiki has a feature request for “Ability to store Multilingual Content” (item 2.12 in the feature tracking page). It is not clear how this can be achieved and there is no proposal for implementation.   Perhaps we should vote whether we want bilingual or multilingual files in next meeting and send this pending item to section 1) or 3). If it goes to section 1), we need to start working right now on how multilingualism will be implemented in XLIFF 2.0 because that affects the elements we define. It would not be the same to have multiple <file> elements, each one with its own language pair, than to have a single <file> and multiple <target> elements per segment.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Thursday, January 05, 2012 6:38 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..]   Rgds dF   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 On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com    

David,   Next meeting is in two weeks; that is enough time for TC members to consider the pros and cons of multilingual/bilingual XLIFF.   Don’t look for a champion outside the TC, Bryan owns this feature in the wiki. The feature has been on the wiki long enough and the wiki is public. There were multiple opportunities to send feedback to the TC regarding this issue.   If you really want multilingual XLIFF, please provide the basic design for multilingual support and we will discuss it. This feature may affect the work on XLIFF 2.0 that we are doing at this moment. We can’t keep waiting for someone to join OASIS sometime in the future and became a champion for multilingual support, sending us back to square one to adjust the design.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip Sent: Friday, January 06, 2012 12:09 AM To: Rodolfo M. Raya; Stephan Böhmig Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, I would first try and find a champion for this feature. If such a champion is found I would give him/her some time for thinking of possible implementations. If a champion is not found soon, the feature should be moved  to 3, but next meting might be to quick, IMHO.   I would expect the champion to be a large publisher or a cloud based TMS provider, if anyone at all. We might be able to bring Stephan from Wordbee to the table after all..   Rgds dF 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 On Thu, Jan 5, 2012 at 21:23, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:   Hi David,   If we opt for having multilingual XLIFF files, there is no reason for not allowing their use in translation editors.   Editing a multilingual XLIFF file should be as easy as editing a bilingual file for the end user. Designing an editor that can handle multilingual files is not a trivial task but can be done.   As developer of XLIFF editors, I certainly prefer XLIFF files to be bilingual. Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   The wiki has a feature request for “Ability to store Multilingual Content” (item 2.12 in the feature tracking page). It is not clear how this can be achieved and there is no proposal for implementation.   Perhaps we should vote whether we want bilingual or multilingual files in next meeting and send this pending item to section 1) or 3). If it goes to section 1), we need to start working right now on how multilingualism will be implemented in XLIFF 2.0 because that affects the elements we define. It would not be the same to have multiple <file> elements, each one with its own language pair, than to have a single <file> and multiple <target> elements per segment.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Thursday, January 05, 2012 6:38 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..]   Rgds dF   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   On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com      

Rodolfo, [a speparate issue] I think there are sound reasons to keep multilingualism away from translation editing. Even Wordbee suggested the construct only for the purpose of bulk project exchange and would not consider it seriously for translating. Of course it can be done, but I see no sound reason for doing it.. Rgds dF 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 On Thu, Jan 5, 2012 at 21:23, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:   Hi David,   If we opt for having multilingual XLIFF files, there is no reason for not allowing their use in translation editors.   Editing a multilingual XLIFF file should be as easy as editing a bilingual file for the end user. Designing an editor that can handle multilingual files is not a trivial task but can be done.   As developer of XLIFF editors, I certainly prefer XLIFF files to be bilingual. Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   The wiki has a feature request for “Ability to store Multilingual Content” (item 2.12 in the feature tracking page). It is not clear how this can be achieved and there is no proposal for implementation.   Perhaps we should vote whether we want bilingual or multilingual files in next meeting and send this pending item to section 1) or 3). If it goes to section 1), we need to start working right now on how multilingualism will be implemented in XLIFF 2.0 because that affects the elements we define. It would not be the same to have multiple <file> elements, each one with its own language pair, than to have a single <file> and multiple <target> elements per segment.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Thursday, January 05, 2012 6:38 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..]   Rgds dF   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 On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com    

If you want multilingual XLIFF files, then allow for editors to use them. If multilingual is really OK, then it has to be OK for any tool or process.   I don’t like the idea of multilingual XLIFF but if it happens, I will have to implement support for it in my tools. If any program creates a valid multilingual file, my software must support that file.   You usually talk about improving interoperability why do you want to restrict interoperability now? If a process creates multilingual XLIFF then that XLIFF has to be supported by all other tools in the market.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip Sent: Friday, January 06, 2012 12:12 AM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Rodolfo, [a speparate issue]   I think there are sound reasons to keep multilingualism away from translation editing. Even Wordbee suggested the construct only for the purpose of bulk project exchange and would not consider it seriously for translating.   Of course it can be done, but I see no sound reason for doing it..   Rgds dF 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 On Thu, Jan 5, 2012 at 21:23, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:   Hi David,   If we opt for having multilingual XLIFF files, there is no reason for not allowing their use in translation editors.   Editing a multilingual XLIFF file should be as easy as editing a bilingual file for the end user. Designing an editor that can handle multilingual files is not a trivial task but can be done.   As developer of XLIFF editors, I certainly prefer XLIFF files to be bilingual. Nevertheless, I admit that language service providers may prefer multilingual XLIFF documents.   The wiki has a feature request for “Ability to store Multilingual Content” (item 2.12 in the feature tracking page). It is not clear how this can be achieved and there is no proposal for implementation.   Perhaps we should vote whether we want bilingual or multilingual files in next meeting and send this pending item to section 1) or 3). If it goes to section 1), we need to start working right now on how multilingualism will be implemented in XLIFF 2.0 because that affects the elements we define. It would not be the same to have multiple <file> elements, each one with its own language pair, than to have a single <file> and multiple <target> elements per segment.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Thursday, January 05, 2012 6:38 PM To: Rodolfo M. Raya Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] Uniqueness of language pair   Thanks Rodolfo, for opening this. I think that it makes perfect sense to set language pair uniqueness constraint at the file level. I was talking to Wordbee in summer trying to recruit them for the TC. Anyway, Wordbee (as our customer) would represent a business need for bulk exchange of multilingual collections. I assume that a collection of different files with various source and target languages would do the trick. Nevertheless, I suspect that Stephan (Wordbee CTO and cowner) would be even more radical than that, and that he would simply want to allow systematically multilingual use of multiple targets. I quote Wordbee position to impartially illustrate an existing business need. I personally would use multilingual formats only with utmost caution, as they pose obvious business process issues, e.g. problematic merging to central data store. If we allowed some controlled sort of multilingualism (multi- in the sense of more than bi-) [if I remember correctly, Andrzej had a good study of why multilingual formats are to be discouraged in translation automation], we would need to explicitly say in processing requirements, that this format MUST NOT be used in and for translation editors. We would need to specify canonical transforms to facilitate canonical behavior of translation editors, that should be bilingual. The multilingual bulk exchange construct should be restricted to CMS<->TMS and TMS<->TMS bulk exchange. [I am aware that alt-trans target is sometimes being used multilngually, I am however not sure what are the support levels for this in tools.. IMHO this is a seprate discussion..]   Rgds dF   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   On Thu, Jan 5, 2012 at 11:31, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi,   In an XLIFF 1.2 document you may have multiple <file> elements and they could have different source/target languages. In theory, that would allow someone to create an XLIFF document with many copies of the same <file> element, each having a different target language. In practice, that would be a bad idea as tools that work with XLIFF usually expect bilingual documents.   It might be interesting for XLIFF 2.0 to set source and target language in the <xliff> element and let all <file> children inherit the declared language pair.   Opinions?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com      

> Even Wordbee suggested the construct only for > the purpose of bulk project exchange and > would not consider it seriously for translating. I think multilingual translation packages can be handled at the package level. There are efforts with Linport and Interoperability Now to get some standardized package format done. Those could be easily made of several sets of bilingual XLIFF. The drawback: source is duplicated in different places: that make sense to me as the package will get eventually split into smaller parts for bilingual work anyway. In other words: XLIFF should provide a relatively small granularity: bilingual files are what translators are using. Then, if needed, XLIFF documents can be combined for larger purposes. Cheers, -ys

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 Maxprograms http://www.maxprograms.com >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Friday, January 06, 2012 1:50 AM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Uniqueness of language pair > > > Even Wordbee suggested the construct only for the purpose of bulk > > project exchange and would not consider it seriously for translating. > > I think multilingual translation packages can be handled at the package level. > There are efforts with Linport and Interoperability Now to get some > standardized package format done. Those could be easily made of several > sets of bilingual XLIFF. > > The drawback: source is duplicated in different places: that make sense to > me as the package will get eventually split into smaller parts for bilingual work > anyway. > > In other words: XLIFF should provide a relatively small granularity: bilingual > files are what translators are using. Then, if needed, XLIFF documents can be > combined for larger purposes. > > Cheers, > -ys > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org

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 [xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya [rmraya@maxprograms.com] Sent: Friday, January 06, 2012 1:32 AM To: 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 Maxprograms http://www.maxprograms.com >
Original Message----- > From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Friday, January 06, 2012 1:50 AM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Uniqueness of language pair > > > Even Wordbee suggested the construct only for the purpose of bulk > > project exchange and would not consider it seriously for translating. > > I think multilingual translation packages can be handled at the package level. > There are efforts with Linport and Interoperability Now to get some > standardized package format done. Those could be easily made of several > sets of bilingual XLIFF. > > The drawback: source is duplicated in different places: that make sense to > me as the package will get eventually split into smaller parts for bilingual work > anyway. > > In other words: XLIFF should provide a relatively small granularity: bilingual > files are what translators are using. Then, if needed, XLIFF documents can be > combined for larger purposes. > > Cheers, > -ys > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org

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 On Fri, Jan 6, 2012 at 15:47, Schnabel, Bryan S < 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 [ xliff@lists.oasis-open.org ] On Behalf Of Rodolfo M. Raya [ rmraya@maxprograms.com ] Sent: Friday, January 06, 2012 1:32 AM To: 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 Maxprograms       http://www.maxprograms.com >
Original Message----- > From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf > Of Yves Savourel > Sent: Friday, January 06, 2012 1:50 AM > To: xliff@lists.oasis-open.org > Subject: RE: [xliff] Uniqueness of language pair > > > Even Wordbee suggested the construct only for the purpose of bulk > > project exchange and would not consider it seriously for translating. > > I think multilingual translation packages can be handled at the package level. > There are efforts with Linport and Interoperability Now to get some > standardized package format done. Those could be easily made of several > sets of bilingual XLIFF. > > The drawback: source is duplicated in different places: that make sense to > me as the package will get eventually split into smaller parts for bilingual work > anyway. > > In other words: XLIFF should provide a relatively small granularity: bilingual > files are what translators are using. Then, if needed, XLIFF documents can be > combined for larger purposes. > > Cheers, > -ys > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xliff-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org