[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Attributes for translation candidates
> -----Original Message----- > From: xliff@lists.oasis-open.org [mailto:xliff@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 Hi Yves, > > 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> / <prop> mechanism. > > 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. Regards, Rodolfo -- Rodolfo M. Raya rmraya@maxprograms.com Maxprograms http://www.maxprograms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]