I see, so the point is that XLIFF should
be able to handle ms:aspdotnet_matches, ms:windowsphone_matches, ms:whatever?
From:
Ryan King <>
To:
Helena S Chapman/San
Jose/IBM@IBMUS
Cc:
"Dr. David Filip"
<>, Shirley Coady <>,
"" <>,
Yves Savourel <>
Date:
01/18/2013 03:46 PM
Subject:
RE: [xliff]
1.2 to 2.0 Gaps and Proposals
Sent by:
<>
We’re not suggesting including
a cost model, only extensible metadata on the match type that can be used
during statistical analysis of the XLIFF to categorize matches as they
might relate to a contractual agreement that lives outside of the XLIFF
document.
Your last statement assumes
that every company uses a centralized contractual agreement for billing
and there is no need to differentiate between internal teams/divisions,
which is not always the case.
From:
[
mailto:
]
On Behalf Of Helena S Chapman
Sent: Thursday, January 17, 2013 6:24 PM
To: Ryan King
Cc: Dr. David Filip; Shirley Coady; ; Yves
Savourel
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
Wait, so are we suggesting to include cost
(element) model along with matching attribute all in XLIFF? To the tools,
why would it matter whether or not a match is in-context-exact-match or
exact-match from a sister product's translation last 6 month, an exact-match
from public domain memories, or exact match from another product 20 years
ago etc. Most of us really only care about two types of exact matches:
1) a real exact match within context 2) everything else. How a vendor is
paid within the cost model of that company is established by an contractual
agreement that lives outside of the XLIFF document. Same principle should
apply to fuzzy matches.
Unless we are talking about mixing MS content along with Oracle content
in the same document and therefore there is a need to distinguish between
which one is which when you pay your vendor, within the same organization,
what's the value of having the ms namespace tagged along with the content?
From: Ryan
King <
>
To: Helena
S Chapman/San Jose/IBM@IBMUS
Cc: "Dr.
David Filip" <
>,
Shirley Coady <
>,
"
"
<
>,
Yves Savourel <
>
Date: 01/17/2013
01:08 PM
Subject: RE:
[xliff] 1.2 to 2.0 Gaps and Proposals
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:
[
mailto:
]
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;
;
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 <
>
To: Ryan King
<
>,
"Dr. David Filip" <
>
Cc: Shirley
Coady <
>,
Yves Savourel <
>,
"
"
<
>
Date: 12/15/2012
10:54 PM
Subject: RE:
[xliff] 1.2 to 2.0 Gaps and Proposals
Sent by: <
>
Further comments or discussion
J ?
From:
[
mailto:
]
On Behalf Of Ryan King
Sent: Tuesday, December 11, 2012 10:35 PM
To: Dr. David Filip
Cc: Shirley Coady; Yves Savourel;
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:
]
Sent: Tuesday, December 11, 2012 4:06 PM
To: Ryan King
Cc: Shirley Coady; Yves Savourel;
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:
On Tue, Dec 11, 2012 at 11:32 PM, Ryan King <
>
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
