RE: [xliff] Attributes for translation candidates

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, all,

> 1) Change the name of "score" to "similarity".
> That would be clearer.

Done.


> 2) Define an optional module for storing the 
> metadata associated with a match.

Yes, I think such metadata could be re-used for other features. For example QA annotations, etc. 


> Perhaps we would need to provide some directions 
> for handling the combination of "score/similarity" with "quality".
> It may be hard for a user to select the best match from 
> two matches that have these properties:
> a) similarity="60" quality="90"
> b) similarity="80" quality="60"

That would be something useful. But, based on some discussions I've seen in use cases like Microsoft Translator's MatchDegree (similarity) and Rating (quality) I'm not sure there would be a single answer. Often it ends up being a user preference that needs to be decided at usage time.

This also brings the question: should we have a processing expectation that user agents should preserve the order of the matches? Also should we have specific processing expectations about how new matches should be added?

My guess is that we probably want to keep this simple: XLIFF provides the structure to hold the information, but let tools do what they want with it. For example a processing expectation that the matches must be re-written in the same order wouldn't work with a tool whose tasks is precisely to apply some ranking to the matches.

Cheers,
-yves