RE: [xliff] Attributes for translation candidates

[Yves Savourel <ysavourel@enlaso.com>]

Hi Yung,

> 1) Data type of score(similarity) and quality:
> * Is there any reason why the score should be an integer?

I suppose a real would be fine. We may want to force some precision (probably 2 decimals).


> 2) Score and quality?
> * I understand the points of having two attributes. However,
> our scoring logic all consider many factors including 
> similarity, quality, content domains and types etc. 
> The score for our case is a combination score, so we can 
> list the suggestions clearly in the order of our preference.

We the same: a 'combined-score' that hold a value we can sort on.
It relates to Rodolfo's note about interpreting both similarity and quality together.
Maybe an attribute could be provided. The question then is : How does it work? Should it be required? What processing expectations should we attached to <match>?

If we have a required 'score' then how does it related to similarity and quality (and possibly other info like type)? 


> 3) content-type, content-domain, match-type 
> * Due to cross-file/type leverage, we need to deliver content-type
> (xml, html, properties, etc) and content domain. Do you think 
> "origin" can be used for that purpose?

Not 'origin', to me 'origin' is more what system created the match. This would be more like the 'datatype' of 1.2

Lucìa was mentioning a possible 'category' for content-domain. Whatever the name, it seems that is something tool would use.


> * "type" requires a clearly defined list of values. For MT suggestions,
> translators should post-edit instead of translate. CATs may have 
> specific features for MT suggestions. Therefore, XLIFF docs should 
> use the same value in type attribute for MT suggestions.

+1

I'll try to update the wiki with all this feedback.
Keep it coming.

-ys