11 messages in org.oasis-open.lists.xliffRE: [xliff] Attributes for translatio...| From | Sent On | Attachments |
|---|---|---|
| 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 | |
| List: | org.oasis-open.lists.xliff | |
-----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
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 rmr...@maxprograms.com Maxprograms http://www.maxprograms.com