|Yves Savourel||Feb 26, 2012 6:58 pm|
|Rodolfo M. Raya||Feb 27, 2012 1:00 am|
|Yves Savourel||Feb 27, 2012 4:45 am|
|Rodolfo M. Raya||Feb 27, 2012 5:04 am|
|Yves Savourel||Feb 27, 2012 5:37 am|
|Lucia.Morado||Feb 27, 2012 7:12 am|
|Yves Savourel||Feb 27, 2012 7:35 am|
|Jung Nicholas Ryoo||Feb 27, 2012 8:36 am|
|Yves Savourel||Feb 27, 2012 10:38 am|
|Rodolfo M. Raya||Feb 28, 2012 10:07 am|
|Yves Savourel||Feb 28, 2012 10:10 am|
|Subject:||RE: [xliff] Attributes for translation candidates|
|From:||Rodolfo M. Raya (rmr...@maxprograms.com)|
|Date:||Feb 27, 2012 5:04:40 am|
-----Original Message----- From: xli...@lists.oasis-open.org [mailto:xli...@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Monday, February 27, 2012 10:46 AM To: 'XLIFF TC' Subject: RE: [xliff] Attributes for translation candidates
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.
A generic module for common metadata would be better then.
We might use this optional module for holding data from the old <prop-group> /
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.
You are right. I don't see a unique answer and that's why I asked for an
explanation. We better present the information to end users and let them decide
how to use it.
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?
I don't think matches need to be preserved. An agent may replace existing
matches with better ones or simply remove all matches from a fully translated
XLIFF to shrink the document and save space/processing time.
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.
You are right. Tools/users should decide.
BTW, shouldn't <matches> and <match> live in a module? They are not essential
for creating an XLIFF document.