- From: Dave Lewis <dave.lewis@cs.tcd.ie>
- Date: Tue, 23 Apr 2013 12:27:38 +0100
- To: public-multilingualweb-lt@w3.org
- CC: Christian Saam <saamc@scss.tcd.ie>, serikova@tcd.ie, John Moran <moranj3@cs.tcd.ie>
- Message-ID: <5176702A.7090102@cs.tcd.ie>
David, Yes, we would be using OKAPI for extracting content and ITS annotation from XLIFF - we are certainly not planning any new extractor/segmentor for OmegaT, so we are dependent on agreeing the mapping the OKAPI's implementation of it. Felix thanks for those examples we'll try then for follow that more neutral pattern for stating the requirements (Anuar, Christian Saam please note). One benefit I'm hoping to get from the ITS-XLIFF mapping of these requirements is that we can then offer an open set of test cases corresponding to these requirements (and their combination and nasty edge cases) as ITS+XLIFF files for other CAT tool developers to test their own UI functionality against. Hopefully we can offer this via the IG wiki alongside other best practice. cheers, Dave On 23/04/2013 11:36, Felix Sasaki wrote: > Hi David, > > I agree with your statement wrt to the role of XLIFF. My point is > only: we can give guidance to the "native support" scenario as well, > without disturbing the importance of XLIFF. > > We already have described ITS 2.0 support in XLIFF extraction scenarios > http://www.w3.org/TR/2013/WD-mlw-metadata-us-impl-20130307/#Translation_Package_Creation > and ITS 2.0 support in non XLIFF scenarios > http://www.w3.org/TR/2013/WD-mlw-metadata-us-impl-20130307/#ITS_2.0_for_localization_of_content_in_a_Web_Content_Management_System > > My (personal) point here would be: we can re-use a lot of descriptions > for both scenarios. Take e.g. the sentence > > "A source subsegment marked with the equivalent of its:translate="no" > (using xlf:mrk mtype="protected") should be visually highlighted for > the tool user." > > We can easily generalize this by saying > > "A source subsegment marked with the equivalent of its:translate="no" > (in XLIFF, using xlf:mrk mtype="protected") should be visually > highlighted for the tool user." > > It then would also cover e.g. the jquery plugin, as demonstrated at > http://attrib.org/jquery-its-example/ > (above demonstration does the "visually highlighted for the tool > user." thing) > > Best, > > Felix > > > > Am 23.04.13 12:22, schrieb Dr. David Filip: >> Christian, all, >> IMHO direct ITS support in CAT tools only makes sense if they are >> working with source formats. Which is often the case, but is exactly >> the undesirable formats and filters jungle that XLIFF had been set up >> to simplify and override. >> If a tool is an XLIFF extractor/merger it of course makes sense for >> them to be able to recognize ITS directly at least in HTML5 and a >> number of standard XML vocabularies. >> >> Supporting ITS on extract/merge is very different (and complementary) >> from supporting a translator consumption/manipulation of the >> categories during XLIFF editing. >> >> AFAIK OmegaT in neither incarnation is an XLIFF extractor/merger, it >> relies on OKAPI to get its XLIFFs. >> So as I see it, work on direct support of ITS in OmegaT does not make >> much sense and is orthogonal to the mapping support. >> >> 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: david.filip@ul.ie <mailto:david.filip@ul.ie> >> >> >> On Tue, Apr 23, 2013 at 8:58 AM, Lieske, Christian >> <christian.lieske@sap.com <mailto:christian.lieske@sap.com>> wrote: >> >> Hi Dave, >> >> I wonder if Anuar's work could, or even should look at the >> CAT-ITS relationship not just from an XLIFF point-of-view. >> >> To me, a scenario in which CAT tools in some contexts work >> natively with ITS - and not "mediated" via XLIFF - seems >> appealing. Possibly, you already know that some CAT tools already >> provide this kind of native ITS 1.0 support. >> >> To a certain degree, the native ITS support would be in line with >> "To foster interoperability, implementers are strongly encouraged >> not to rely on these mappings and to implement the ITS 2.0 >> quality types natively." (from: >> http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#lqissue-typevalues). >> >> The existing list of "Use Cases" is quite interesting. I would be >> tempted to differentiate between two categories: "visualization", >> and "interaction". >> >> Cheers, >> Christian >> >> -----Original Message----- >> From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie >> <mailto:dave.lewis@cs.tcd.ie>] >> Sent: Montag, 22. April 2013 03:00 >> To: public-multilingualweb-lt@w3.org >> <mailto: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 11:28:19 UTC