xliff — archive

1.2 to 2.0 Gaps and Proposals

From: Helena Chapman <[email protected]>
To: [email protected]
Date: Mon, 17 Dec 2012 16:42:00 -0000

I have some concerns about the similarity attribute, until there is a openly acknowledged standard around matching proximity, having that attribute does not make sense to me. What does it mean when your tool say 75%? What happens if my tool does not acknowledge the calculation to be agreeable? Note that I am not suggesting it is not useful information but I think the cart is in front of the horse. Based on an agreed upon matching standard, I do not believe there will be a need for subType. Most of the information specified by similarity would be sufficient enough for determining what the subType would be. From: Ryan King <[email protected]> To: Ryan King <[email protected]>, "Dr. David Filip" <[email protected]> Cc: Shirley Coady <[email protected]>, Yves Savourel <[email protected]>, "[email protected]" <[email protected]> Date: 12/15/2012 10:54 PM Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals Sent by: <[email protected]> Further comments or discussion J ? From: [email protected] [ mailto:[email protected] ] On Behalf Of Ryan King Sent: Tuesday, December 11, 2012 10:35 PM To: Dr. David Filip Cc: Shirley Coady; Yves Savourel; [email protected] Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals To be honest, I originally proposed concatenated because I thought that was what we agreed on for subState at the f2f and I wanted to follow suit…but maybe I misremembered that. I actually think a separate attribute is better. It is cleaner as you say, and I don’t think it is really a heavy requirement to ask user agents to drop the subtype when the main type changes (or is deleted), which I agree is the correct behavior. Should we define any sub values in Xliff such as “fuzzy” or “exact”? I would actually put “ice” here as well and not in the main type attribute. I reference Wikipedia for my reasoning J http://en.wikipedia.org/wiki/Translation_memory : Retrieval Several different types of matches can be retrieved from a TM. Exact match Exact matches appear when the match between the current source segment and the stored one is a character by character match. When translating a sentence, an exact match means the same sentence has been translated before. Exact matches are also called "100 % matches". In-Context Exact (ICE) match or Guaranteed Match An ICE match is an exact match that occurs in exactly the same context, that is, the same location in a paragraph. Context is often defined by the surrounding sentences and attributes such as document file name, date, and permissions. Fuzzy match When the match is not exact, it is a "fuzzy" match. Some systems assign percentages to these kinds of matches, in which case a fuzzy match is greater than 0% and less than 100%. Those figures are not comparable across systems unless the method of scoring is specified. So now we would have something like this: <match id=”1” similarity=”75.0” type=”tm” subtype=”xlf:fuzzy”> <match id=”1” similarity=”99.0” type=”tm” subtype=”ms:near-exact”> <match id=”1” similarity=”100.0” type=”tm” subtype=”xlf:exact”> <match id=”1” similarity=”100.0” type=”tm” subtype=”xlf:ice”> Thanks, ryan From: Dr. David Filip [ mailto:[email protected] ] Sent: Tuesday, December 11, 2012 4:06 PM To: Ryan King Cc: Shirley Coady; Yves Savourel; [email protected] Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals I support adding private subtype Pending issues: - Freeze of the normative top level list - Mechnics of subtype, we should be probably using the same mechanics consistently, i.e. either concatenated or separate attributes. This is a spec wide issue Separate seems cleaner, but concatenation seems better for processing, subtype is automatically dropped when main type changed, which seems desirable ?? Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: [email protected] On Tue, Dec 11, 2012 at 11:32 PM, Ryan King < [email protected] > wrote: Thanks Yves and Shirley, while we are discussing the correct list of match values, I'd like to know from the list if we have consensus on adding a subtype for match. Thanks, ryan