OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]