OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only

  • 1.  csprd01- 18, 24, and 36: Glossary Module Design

    Posted 07-17-2013 19:44
    Hi Jörg and Chase,   I hope you don’t mind that I respond to both of you on the same mail. Regarding your comments on the glossary module in the recent public review of the XLIFF 2.0 spec:   Jörg: “It is unclear if for the "term" type the 'ref' attribute could be used to establish a relationship with entries in the Glossary module. The Glossary module does not have a mechanism, e.g. an attribute such as 'termId', or even an element, that allows for dereferencing” AND “The Glossary module is a very simple incarnation of a bi-lingual terminology resource (source and target language of the <xliff> element) that does not offer either a mechanism to relate the <term> entries with <source> and <target> content or any other means to accomplish such a relationship by, for example, a term or even a concept identifier. Variations or synonyms are also not foreseen, and always require a new entry. The only attribute that is required is 'source' for the <definition> element which is certainly very bizarre in this context. The module has it is defined in the specification is useless because it only provides an isolated data bag.”   Chase: “I am not a term expert, but I am concerned that this schema is overly simplistic. There is no way identify correlate term entries with segment content. The per-term metadata is very limited; in particular term variations are not supported.”   We will make the following changes to the specification to address these and other issues:   1.        Add an id attribute to <glossentry> so that it can be referenced by the <mrk> element as a term annotation. 2.        Change the source attribute on <definition> to be optional. 3.        Allow elements and attributes from any namespace in <glossentry> for extensibility 4.        Allow attributes from any namespace in children of <glossentry> for extensibility 5.        Allow <translation> to appear zero, one, or more times with an id to support synonym translations.   Here is an example:   <unit id="1">   <segment>     <source>Press the <mrk id="m1" type="term" ref="#g1">TAB key</mrk>.</source>   </segment>   <gls:glossary>     <gls:glossentry id="g1">       <gls:term abc:concept-id=”25”>TAB key</gls:term>       <gls:translation id="1">Tabstopptaste</gls:translation>       <gls:translation id="2">TAB-TASTE</gls:translation>       <gls:definition>A keyboard key that is traditionally used to insert tab characters into a document.</gls:definition>       <abc:usageNotes>To be used when referring to a physical device</abc:usageNotes>     </gls:glossentry>   </gls:glossary>  </unit>   Thanks for your interest in XLIFF 2.0!   Ryan  


  • 2.  Re: csprd01- 18, 24, and 36: Glossary Module Design

    Posted 07-19-2013 07:40
    Hi Ryan,

    Thanks for this improved version. You should also consider to add some
    administrative data (date, time, resource, creator, etc.) to account for
    traceability of the module's entries. Not only think about the human
    employment of this data but also about the machine processability. The
    <translation> element might also benefit from a language attribute to
    include possible regional variants as well as other languages.

    By the way, the German "Tabstopptaste" is quite ugly but see my previous
    comment on your German terminology... ;-)

    Thanks again, and cheers,

    Jörg

    On July 17, 2013 at 21:42 (CEST), Ryan King wrote:
    > Hi Jörg and Chase,
    >
    > I hope you don’t mind that I respond to both of you on the same mail.
    > Regarding your comments on the glossary module in the recent public
    > review of the XLIFF 2.0 spec:
    >
    > Jörg: “It is unclear if for the "term" type the 'ref' attribute could be
    > used to establish a relationship with entries in the Glossary module.
    > The Glossary module does not have a mechanism, e.g. an attribute such as
    > 'termId', or even an element, that allows for dereferencing” AND “The
    > Glossary module is a very simple incarnation of a bi-lingual terminology
    > resource (source and target language of the <xliff> element) that does
    > not offer either a mechanism to relate the <term> entries with
    > and <target> content or any other means to accomplish such a
    > relationship by, for example, a term or even a concept identifier.
    > Variations or synonyms are also not foreseen, and always require a new
    > entry. The only attribute that is required is 'source' for the
    > <definition> element which is certainly very bizarre in this context.
    > The module has it is defined in the specification is useless because it
    > only provides an isolated data bag.”
    >
    > Chase: “I am not a term expert, but I am concerned that this schema is
    > overly simplistic. There is no way identify correlate term entries with
    > segment content. The per-term metadata is very limited; in particular
    > term variations are not supported.”
    >
    > We will make the following changes to the specification to address these
    > and other issues:
    >
    > 1.Add an id attribute to <glossentry> so that it can be referenced by
    > the <mrk> element as a term annotation.
    >
    > 2.Change the source attribute on <definition> to be optional.
    >
    > 3.Allow elements and attributes from any namespace in <glossentry> for
    > extensibility
    >
    > 4.Allow attributes from any namespace in children of <glossentry> for
    > extensibility
    >
    > 5.Allow <translation> to appear zero, one, or more times with an id to
    > support synonym translations.
    >
    > Here is an example:
    >
    > <unit id="1">
    >
    > <segment>
    >
    > Press the <mrk id="m1" type="term" ref="#g1">TAB
    > key</mrk>.
    >
    > </segment>
    >
    > <gls:glossary>
    >
    > <gls:glossentry id="g1">
    >
    > <gls:term abc:concept-id=”25”>TAB key</gls:term>
    >
    > <gls:translation id="1">Tabstopptaste</gls:translation>
    >
    > <gls:translation id="2">TAB-TASTE</gls:translation>
    >
    > <gls:definition>A keyboard key that is traditionally used to
    > insert tab characters into a document.</gls:definition>
    >
    > <abc:usageNotes>To be used when referring to a physical
    > device</abc:usageNotes>
    >
    > </gls:glossentry>
    >
    > </gls:glossary>
    >
    > </unit>
    >
    > Thanks for your interest in XLIFF 2.0!
    >
    > Ryan
    >



  • 3.  RE: csprd01- 18, 24, and 36: Glossary Module Design

    Posted 07-19-2013 18:20
    Hi Jörg, it was the general consensus of the TC to keep this terminology module simple and avoid building in complex terminological features; however, we wanted to make it extensible and flexible for those implementers who wanted more complexity. The data you mention below could be added to <gls:glossary> by using attributes or elements from another namespace. If you have complex terminological needs, another option is to add an external reference using the <mrk> element to create a term annotation, which points to an external termbase. We also removed <gls:glossary> from <file> level, which would allow implementers to define their own terminology extension/module, perhaps based on a more complex schema such as TBX.

    Again, if you have better German translations I could use in my examples, you can send them my way.

    Thanks,
    Ryan


    Original Message


  • 4.  Re: csprd01- 18, 24, and 36: Glossary Module Design

    Posted 07-19-2013 18:57
    Hi Ryan,

    Well, in princple that's pretty much understandable. And sure, I can add
    a lot of things with a separate namespace. But IMHO this would be
    against the general spirit of XLIFF 2.0 which aims at having a common
    format that can be used to seamlessly exchange information between
    different tools along the localization and translation supply chain, and
    guarantee interoperability between these tools (and accoring to the
    package metaphor used in the specification). Think about, for example,
    SQL that has once given us such a guarantee to solve the integration
    problem between RDBs... ;-)

    Regarding German terminology I 'll send you some proposals in a separate
    email.

    Thanks and cheers -- Jörg

    On July 19, 2013 at 20:20 (CEST), Ryan King wrote:
    > Hi Jörg, it was the general consensus of the TC to keep this terminology module simple and avoid building in complex terminological features; however, we wanted to make it extensible and flexible for those implementers who wanted more complexity. The data you mention below could be added to <gls:glossary> by using attributes or elements from another namespace. If you have complex terminological needs, another option is to add an external reference using the <mrk> element to create a term annotation, which points to an external termbase. We also removed <gls:glossary> from <file> level, which would allow implementers to define their own terminology extension/module, perhaps based on a more complex schema such as TBX.
    >
    > Again, if you have better German translations I could use in my examples, you can send them my way.
    >
    > Thanks,
    > Ryan
    >
    >
    Original Message


  • 5.  RE: csprd01- 18, 24, and 36: Glossary Module Design

    Posted 07-19-2013 19:46
    Thanks Jörg, you make a good point, and as is the case with any standard or product released to consumers, if there turns out to be a lot of custom usage for this type of data within XLIFF, perhaps we can look at adding it to a future version of the spec.

    Ryan


    Original Message


Related Content