Re: [xliff] Glossaries in XLIFF 2.0

["Dr. David Filip" <David.Filip@ul.ie>]

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