xliff — archive

1.2 to 2.0 Gaps and Proposals

From: Ryan King <[email protected]>
To: [email protected]
Date: Thu, 17 Jan 2013 18:02:00 -0000

One of the main reasons why having an extensible match subtype makes sense is because the cost and billing models between content providers and localization supplier can differ from one to the next. If I have a 100% match from a TM database, that match might just be an exact match or it might be an in context exact match. Microsoft might have a contract to pay their localization supplier to review the exact match, but not the in context exact match. Another company might have a different cost model where they pay to have the in context exact match reviewed as well. Thanks, Ryan From: [email protected] [mailto:[email protected]] On Behalf Of Helena S Chapman Sent: Monday, December 17, 2012 8:42 AM To: Ryan King Cc: Dr. David Filip; Ryan King; Shirley Coady; [email protected]; Yves Savourel Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals 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