Re: csprd01 023: Translation Candidates Module

[Jörg Schütz <joerg@bioloom.de>]

Hi Yves,

Thanks a lot for your explanation and the modification of the 
description of the standard values (am, mt, icm, etc.) which is now 
better comprehensible for the reader/developer.

For the attributes' revision, I will have a closer look in the next 
public reviewing round but for now the "origin" revision might be 
sufficient.

Yes, I was looking for a "context-before" and "context-after" for source 
and target respectively (as generated by the XLIFF creation tool) for a 
given TM match (mostly close to 80% - 100%) to give the translator a 
chance of checking if the match contextually fits, and therefore 
wouldn't actually need any (substantial) revision. Because it is data, 
i.e. the original text, generated by the creator tool, it should 
certainly be possible to provide this contextual information in a 
standard way. Otherwise you would again loose interoperability between 
tools.

Thanks and cheers -- Jörg

On July 21, 2013 at 07:17 (CEST), Yves Savourel wrote:
> Hi Jörg, all,
>
> Trying to address issue 23:
>
> [[
> Comment:  The Translation Candidates module is a replacement of the <alt-trans> element in XLIFF 1.2, and provides a means to
> maintain alternative translations (in particular translation automation) for the translatable content. The module is not very
> restrictive in the attribute selection, and might therefore be hijacked for arbitrary customization purposes. An exception, however,
> is the attribute 'type' for which standard values are provided. Because of the stated processing requirements, these standard values
> should be further explained and justified. This module particularly lacks a contextual reference (before/after; previous/subsequent)
> which certainly would be very helpful for human and machine processing (even in fully automated cases). The Resource Data module
> might be a place for such contextual information but only the Metadata module is a permitted element in this module
> ]]
>
> One initial note: while being the initial "owner" of this module, the initial proposal from many months ago has been significantly
> changed and updated by the TC. S I may not be the right person to answer some of the questions regarding various features of this
> module.
>
>
> > The module is not very restrictive in the attribute
> > selection, and might therefore be hijacked for arbitrary
> > customization purposes.
>
> The origin attribute has been revised to provide a better definition (see issue 52).
> For the other attributes, I'm not sure how much further they could be restrictive. Could you give an example?
>
>
> > Because of the stated processing requirements, these
> > standard values should be further explained and justified.
>
> There was many emails and call discussions about the values of the type attribute. Changing the consensus the TC came up with would
> probably require some call discussions.
>
> I've tried to re-word the text a bit and be more specific (but without changing the meaning of the type) in the following list.
> Would that be more acceptable:
>
> am - Candidate generated by assembling parts of different translations. For example: constructing a candidate by using the known
> translations of various spans of content of the source)
>
> mt - Machine Translation: candidate generated by a machine translation system.
>
> icm - In Context Match: candidate for which the content context of the translation was the same as the one the current source, i.e.
> the source text for both contents is also preceded and/or followed by an identical source segments.
>
> idm - Identifier-based Match: candidate that has an identifier identical to the one of the source content. For example the previous
> translation of a given UI component with the same ID.
>
> tb - Term Base: candidate obtained from a terminological database, i.e. the whole source segment matches with a source term base
> entry.
>
> tm - Translation Memory: candidate coming from a simple match of the source content.
>
> other - Candidate of a top level type not covered by any of the above definitions.
>
>
> > This module particularly lacks a contextual reference
> > (before/after; previous/subsequent) which certainly
> > would be very helpful for human and machine processing
> > (even in fully automated cases).
>
> Could you specify a bit hat you mean by "contextual reference (before/after; previous/subsequent)"? An example of what you would
> expect to be a contextual reference for a given candidate would be helpful.
>
> Maybe you are referring to a way of representing the segments that were before and after the candidate in the original context where
> the previous translation was done?
> If that is the case, then I'm not sure such thing can be represented in a standard way. Some system use various representation of
> the original text, other hash codes, other ID references, etc.
>
> Cheers,
> -yves