- From: Dr. David Filip <David.Filip@ul.ie>
- Date: Wed, 20 Mar 2013 12:30:38 +0000
- To: Dave Lewis <dave.lewis@cs.tcd.ie>
- Cc: public-multilingualweb-lt@w3.org
- Message-ID: <CANw5LKkreUwRRnP1nTAdEkNhM=nNje45e_QM_4vhzNY=_Xwmkg@mail.gmail.com>
Hi Dave, answers inline On Mon, Mar 18, 2013 at 10:17 PM, Dave Lewis <dave.lewis@cs.tcd.ie> wrote: > On 18/03/2013 17:14, Yves Savourel wrote: > >> How do we represent mt-confidence in alt-trans and how that gets back >> into the original document (if at all). >> > > For returning to the original document, is it safe to assume this would > never be trasnposed directly from the alt trans, i.e. it would only get > into the target document if it was in the trans-unit/target unit? > This should be the recommended best practice. Alt-trans or translation candidate in 2.0 is an internal xliff affair, the only element intended for merging back is <target> child of <trans-unit> in 1.2 and child of segment in 2.0 > > For the current CMS-LION-SOLAS implementation, we use quality-match and > origin in alt trans (based on the principle of using native XLIFF > attributes where-ever possible), but then copy the score to > its:mtconfidence in the trans-unit/target if and only if the text is not > touched by postediting. > > There is the problem you inidciate below that this means we don't have > annotatorRef value for the use of mtConfidence (you are correct, using 'mt' > in the alt-trans.origin doesn't offer anything useful here). In our > particular use case, we can derive the annotator ref from the provenance > relationship. This may be useful best practice, but that's no help if your > implementation dosn't use provenance. > On the last call before Rome, we decided to use the annotatorRef, as not using it would violate the its semantics. It is also reflected on the wiki table http://www.w3.org/International/multilingualweb/lt/wiki/XLIFF_Mapping I edited it before Rome > > In general we probably do need to condier what is best practice in the > three use cases: > a) ITS for source to XLIFF mapping > b) ITS generated from one XLIFF component and consumed by another XLIFF > component > c) ITS in XLIFF to ITS in target document > > and perhaps live with the best practice not being the same in each case. > I do not see any sort of clash between the use cases. If the MT confidecne info is found in the content. It will get straight to source using the same mechanism as target (not alt-trans) The info will be irrelevant for the new alt-transes and targets > > The main question at this point though, after the burst of implementaiton > for Rome, do we think there are any ITS-XLIFF mapping issues that will > impact the ITS draft? > I do not think there are > > If not, perhaps we should focus on getting the draft complete now and > thenreturn to documenting the mapping after that. > +1 > > cheers, > Dave > > > for using quality-match in alt-trans: I suppose the value of >> quality-match is so loose that I suppose it can include the mt-confidence. >> But I'm really not sure that in such case the origin must be 'MT'. Origin >> is already in use today for indicating more specific information (e.g. not >> just MT but Google-Translate or Bing-Translator for example). >> Having origin set to 'mt' or not doesn't really bring anything to the >> mapping. >> > > > >
Received on Wednesday, 20 March 2013 12:31:44 UTC