- From: Dave Lewis <dave.lewis@cs.tcd.ie>
- Date: Tue, 23 Apr 2013 01:08:32 +0100
- To: Yves Savourel <ysavourel@enlaso.com>
- CC: public-multilingualweb-lt@w3.org
thanks Yves, that's really helpful. We'll address this and other comments that have come up internally, and send out a revised version hopefully next week before progressing onto some wireframes for discussion. cheers, Dave On 22/04/2013 13:41, Yves Savourel wrote: > Hi Dave, > > Here are a few comments for Anuar: > > === Translate: > > - another way to 'represent' original structural-type elements with translate='no' is to not extract them at all. > > - and inline content that is with translate='no' in the original file is also often represented as an inline code. > > > === Terminology: > > - "...the relevant its:annotatorsRef link that can be followed to display more information about the engine that generated the annotation" > Note that the IRI provided by its:annotatorsRef is not necessarily a link: > From the spec: "No single means is specified for how this IRI should be used to indicate processor information. Possible mechanisms are: to encode information directly in the IRI, e.g. as parameters; to reference an external resource that provides such information, e.g. an XML file or an RDF declaration; or to reference another part of the document that provides such information." > > > === Element Within Text: > > - IMO there should be no such data category used in XLIFF. On of the goal of converting to XLIFF is to separate inline from no-inline codes and therefore all inline codes should already be represented by an inline XLIFF element. Original content that is nested should be represented in separate text unit. > > > === Domain: > > - there is no such attribute as its:domain. > The document is probably referring to itsx:domain. > > > === Text Analysis: > > - its:taSource value is not a URL. > > > === MT confidence: > > - "...This will be represented in XLIFF using a match-quality attribute accompanied by a xlf:orgin attribute with value “MT” > As far as I can tell the mapping in the wiki is not reflecting the latest discussions. e.g. using xlf:origin='mt' is not useful (see discussion here: http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Mar/0135.html) > > > === Localization quality Issue: > > - "Each record can include a type strong" > What's a 'type strong'? > > > === Localization Quality Rating: > > - "The whole target document, the target of a translation unit, a target segment or a target subsegment can be annotated with a localisation quality measure." > while it's true that technically a sub-segment could be rated, I would use segment-level rating as the lowest level, anything under that may be very difficult to work with in practice. > > > That's all for now. > -yves > > > -----Original Message----- > From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie] > Sent: Sunday, April 21, 2013 7:00 PM > To: public-multilingualweb-lt@w3.org > Subject: [ISSUE-55] ITS in XLIFF - CAT tool requirements > > Hi all, > As you may know, we have an intern Anuar Serikov, who will be working on support for ITS annotation in the open source CAT tool OmegaT. > > As an first step we've produced a rough draft set of requirements for how users of a CAT tool could interact with ITS2.0 annotations at: > https://docs.google.com/document/d/1vt3a3wWFPFrEG8tS9X3RMClKVjV8xDXqWNHB4g8VGJw/edit?usp=sharing > > This may be of interest in those looking at the XLIFF-ITS mapping, since the requirements assume use of ITS within XLIFF. Any comments or feedback would be very welcome. > > Regards, > Dave > > > >
Received on Tuesday, 23 April 2013 00:09:03 UTC