OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Glossaries in XLIFF 2.0

    Posted 12-07-2011 10:27
    Hi All,   Current version of XLIFF (1.2) and older ones all have a placeholder for storing a glossary in the header. So far, the existing <glossary> element has not been useful because there is no indication on how to store glossary terms in it. There isn’t a well-defined way to store terms ensuring interoperability.   We have a request in the wiki for storing term proposals in an XLIFF file. The request is located here: http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-TermProposals.TermProposals . Current owner of the request is Yves.   We also have a concrete XML schema for holding glossary data in SVN. The schema defines 6 elements and 3 attributes that were originally included in the initial draft for XLIFF 2.0. Description of those elements and attributes is available in the PDF that documents the initial draft, which is also included in SVN.   Having the XML schema and initial documentation makes it easy to implement support for simple glossaries in XLIFF 2.0 as an optional module.   Should we move the existing request from section 2 in the wiki to section 1, making it an optional  module or should we discard the request completely moving it to section 3?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  


  • 2.  RE: [xliff] Glossaries in XLIFF 2.0

    Posted 12-07-2011 15:52
    Hi everyone,   Just to make sure the item #21 “Term proposals” in the wiki is clear:   The tentative item is about a way to markup the source content for terms and store their corresponding translations. A bit like the <match> does for segment matches.   Marking up the terms would be likely something done with the inline annotation element (currently <mrk>) and I had not really thought about how to store the translation yet. Potentially the mechanism could allow in-place storage or point to somewhere in the XLIFF document, or even possibly point outside.   In other words: item #21 is certainly related to having a glossary stored inside XLIFF, but it could potentially work without it as well.   Since the item has not been really worked on yet, there is little about what it would look like. Sorry if it misled anyone.   All this doesn’t change the merit or demerit to have a glossary in XLIFF and the actual format of that glossary. I think it is a related, but separate topic.   Cheers, -yves     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya Sent: Wednesday, December 07, 2011 3:27 AM To: xliff@lists.oasis-open.org Subject: [xliff] Glossaries in XLIFF 2.0   Hi All,   Current version of XLIFF (1.2) and older ones all have a placeholder for storing a glossary in the header. So far, the existing <glossary> element has not been useful because there is no indication on how to store glossary terms in it. There isn’t a well-defined way to store terms ensuring interoperability.   We have a request in the wiki for storing term proposals in an XLIFF file. The request is located here: http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-TermProposals.TermProposals . Current owner of the request is Yves.   We also have a concrete XML schema for holding glossary data in SVN. The schema defines 6 elements and 3 attributes that were originally included in the initial draft for XLIFF 2.0. Description of those elements and attributes is available in the PDF that documents the initial draft, which is also included in SVN.   Having the XML schema and initial documentation makes it easy to implement support for simple glossaries in XLIFF 2.0 as an optional module.   Should we move the existing request from section 2 in the wiki to section 1, making it an optional  module or should we discard the request completely moving it to section 3?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  


  • 3.  Re: [xliff] Glossaries in XLIFF 2.0

    Posted 12-07-2011 17:41
    Hi all, overall I do not think there is harm in XLIFF having its own small glossary mechanism. The role of this glossary mechanism would not be a full blown Terminology management solution. It should be more like a means for terminology managed elsewhere to survive transformations of the XLIFF translation package. The obvious benefits should be in the scenarios of suggesting and creating new terminology entries, creating target terminology candidates based on a source terminology, and displaying existing terminology to users in context without need to manually navigate to specialized terminology management servers. It think that apart from its own internal mechanism the solution should contain a mapping to/and from TBX light/basic (we know of TBX shortcomings in the technical area, but a mapping of a minimal set of data categories should be still possible). We should also consider OWL (Lite/DL) mappping/hook. Last but not least. Interoperability Now XLIFF:Doc contains an interesting proposal of an UTX wrapper. IMHO we should liaise with AAMT and find a solution for maintaing the XML wrapper for UTX, as UTX unfortunately is based on a tab delimited format.. I might miss other important links, still the bottom line should be that XLIFF must have a terminology survival mechanism to be able to provide a complete L10n roundtrip solution. Best 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 Wed, Dec 7, 2011 at 15:52, Yves Savourel < ysavourel@enlaso.com > wrote: Hi everyone,   Just to make sure the item #21 “Term proposals” in the wiki is clear:   The tentative item is about a way to markup the source content for terms and store their corresponding translations. A bit like the <match> does for segment matches.   Marking up the terms would be likely something done with the inline annotation element (currently <mrk>) and I had not really thought about how to store the translation yet. Potentially the mechanism could allow in-place storage or point to somewhere in the XLIFF document, or even possibly point outside.   In other words: item #21 is certainly related to having a glossary stored inside XLIFF, but it could potentially work without it as well.   Since the item has not been really worked on yet, there is little about what it would look like. Sorry if it misled anyone.   All this doesn’t change the merit or demerit to have a glossary in XLIFF and the actual format of that glossary. I think it is a related, but separate topic.   Cheers, -yves     From: xliff@lists.oasis-open.org [mailto: xliff@lists.oasis-open.org ] On Behalf Of Rodolfo M. Raya Sent: Wednesday, December 07, 2011 3:27 AM To: xliff@lists.oasis-open.org Subject: [xliff] Glossaries in XLIFF 2.0   Hi All,   Current version of XLIFF (1.2) and older ones all have a placeholder for storing a glossary in the header. So far, the existing <glossary> element has not been useful because there is no indication on how to store glossary terms in it. There isn’t a well-defined way to store terms ensuring interoperability.   We have a request in the wiki for storing term proposals in an XLIFF file. The request is located here: http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-TermProposals.TermProposals . Current owner of the request is Yves.   We also have a concrete XML schema for holding glossary data in SVN. The schema defines 6 elements and 3 attributes that were originally included in the initial draft for XLIFF 2.0. Description of those elements and attributes is available in the PDF that documents the initial draft, which is also included in SVN.   Having the XML schema and initial documentation makes it easy to implement support for simple glossaries in XLIFF 2.0 as an optional module.   Should we move the existing request from section 2 in the wiki to section 1, making it an optional  module or should we discard the request completely moving it to section 3?   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com  


  • 4.  RE: [xliff] Glossaries in XLIFF 2.0

    Posted 12-07-2011 18:34
    Hi David, The glossary format that is currently in SVN is based on GlossML, a simple design that was proposed earlier to LISA for holding glossary data in those cases where TBX is overkill. It is quite easy to export a glossary embedded in an XLIFF file as TBX using an XSL stylesheet. Actually, stylesheets for converting GlossML to TBX already exist and with a minor modification they could fit the design proposed for XLIFF. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com > From: "Dr. David Filip" <David.Filip@ul.ie> > To: Yves Savourel <ysavourel@enlaso.com> > Date: Wed, 7 Dec 2011 17:40:27 +0000 > >Hi all, overall I do not think there is harm in XLIFF having its own small glossary mechanism. The role of this glossary mechanism would not be a full blown Terminology management solution. It should be more like a means for terminology managed elsewhere to survive transformations of the XLIFF translation package. > The obvious benefits should be in the scenarios of suggesting and creating new terminology entries, creating target terminology candidates based on a source terminology, and displaying existing terminology to users in context without need to manually navigate to specialized terminology management servers. > It think that apart from its own internal mechanism the solution should contain a mapping to/and from TBX light/basic (we know of TBX shortcomings in the technical area, but a mapping of a minimal set of data categories should be still possible). > We should also consider OWL (Lite/DL) mappping/hook. > Last but not least. Interoperability Now XLIFF:Doc contains an interesting proposal of an UTX wrapper. IMHO we should liaise with AAMT and find a solution for maintaing the XML wrapper for UTX, as UTX unfortunately is based on a tab delimited format.. > I might miss other important links, still the bottom line should be that XLIFF must have a terminology survival mechanism to be able to provide a complete L10n roundtrip solution.


  • 5.  Re: [xliff] Glossaries in XLIFF 2.0

    Posted 12-07-2011 19:30
    This sounds good to me re TBX, thanks Rodolfo.. 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 Wed, Dec 7, 2011 at 18:33, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi David, The glossary format that is currently in SVN is based on GlossML, a simple design that was proposed earlier to LISA for holding glossary data in those cases where TBX is overkill. It is quite easy to export a glossary embedded in an XLIFF file as TBX using an XSL stylesheet. Actually, stylesheets for converting GlossML to TBX already exist and with a minor modification they could fit the design proposed for XLIFF. Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com > From: "Dr. David Filip" < David.Filip@ul.ie > > To: Yves Savourel < ysavourel@enlaso.com > > Date: Wed, 7 Dec 2011 17:40:27 +0000 > >Hi all, overall I do not think there is harm in XLIFF having its own small glossary mechanism. The role of this glossary mechanism would not be a full blown Terminology management solution. It should be more like a means for terminology managed elsewhere to survive transformations of the XLIFF translation package. > The obvious benefits should be in the scenarios of suggesting and creating new terminology entries, creating target terminology candidates based on a source terminology, and displaying existing terminology to users in context without need to manually navigate to specialized terminology management servers. > It think that apart from its own internal mechanism the solution should contain a mapping to/and from TBX light/basic (we know of TBX shortcomings in the technical area, but a mapping of a minimal set of data categories should be still possible). > We should also consider OWL (Lite/DL) mappping/hook. > Last but not least. Interoperability Now XLIFF:Doc contains an interesting proposal of an UTX wrapper. IMHO we should liaise with AAMT and find a solution for maintaing the XML wrapper for UTX, as UTX unfortunately is based on a tab delimited format.. > I might miss other important links, still the bottom line should be that XLIFF must have a terminology survival mechanism to be able to provide a complete L10n roundtrip solution. --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org