[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] internal matches
Hi all, I am a bit unsure if we get all this done in a hurry. Particularly the discussions about the version integration that Yves mentions below. Anyway, here a preliminary, for discussion, proposal to add the capability to point to internal matches to XLIFF 2.1 Translation Candidate Reference Annotation This annotation can be used to mark up content with a reference to other content which can be used as a translation proposal, but where
the translation is not yet known at the time of annotation. This annotation can reference any source spans of content that are referencable via the XLIFF
Fragment Identification
mechanism Usage: • The
id
attribute is REQUIRED • The
type
attribute is REQUIRED and set to
mtc:imatch • The
ref
attribute is REQUIRED and points to source content which can be used as translation candidate • The
value
attribute is OPTIONAL and if used represents the similarity value for the translation proposal in the range from 0.0 to 100.0 • The
translate
attribute is OPTIONAL For example: <unit id="u1"> <segment id="s1"> <source>He is my friend.</source> </segment> </unit> <unit id="u2"> <segment id="s1"> <source><mrk id="m1" type="mtc:imatch" ref="#u=u1/s1" value="100.0">He is my friend.</mrk></source> </segment> </unit> As you see, there are at least two problems: 1)
Other than in the original concept of the matches module the internal matches have to cross unit boundaries 2)
To make the referenced content of an internal match re-segmentable, it would be best to mark it with <mrk> tags, too. In case there is
a translation added to that reference, it needs <mrk> tags, too. The question is if one should make it a requirement that the ref attribute always points to a <mrk> (to enable resegmentation of the referenced
content without breaking the match). Best regards, Joachim From: Yves Savourel [mailto:ysavourel@enlaso.com]
There are 5 more day until closure of the 2.1 features. So if this has to have any chance to make it someone needs to fill a proposal very soon. Also, will we have anyone willing to implement it? (before January). It would also bring an interesting first case for implementing/(or not) backward compatibility with modules: -
Can a 2.1 document have 2.0 Translation candidates? (or both 2.1 and 2.1)? -
Does the 2.1 core schema would have to include both Translation Candidates schemes? -
Etc. A lot of question for dealing with updated modules will need to be resolved (which is a good thing). Cheers, -yves From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip I think that this custom annotation would be a natural extension to the mtc module, should not be too difficult to add.
Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer LRC | CNGL | CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie On Thu, Nov 13, 2014 at 12:12 PM, Schurig, Joachim <Joachim.Schurig@lionbridge.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]