Re: [ISSUE-55] ITS in XLIFF - CAT tool requirements

Perhaps we could just use some generic terminology in the requirements 
for the items we currently refer to as xliff elements as follows:
Source Unit: translatable text and inline markup extracted from source 
= source element of xlf:trans-unit

Source Segment: translatable text and inline markup resulting from 
extraction and segmention of source content
=source segment of xlf:trans-unit

Source Subsegment: a portion of text within a Source Segment or a Source 

Candiate Translation: a proposed translation of a Source Segment or 
Source Unit
=target of xlf:alt-trans

Working Translation: The translation of a Source Segment or Source Unit 
currently intented for submission as the output translation
=target of xlf:trans-unit

Target Subsegment: a portion of text within a Candidate Translation or 
Working Translation

XLIFF experts, does that sound right or at least a workable mapping from 
generic to XLIFF as Felix suggests?


On 23/04/2013 10:08, Felix Sasaki wrote:
> Hi Dave, all,
> it seems that various requirements which already have been fleshed out 
> in the document are relevant to both the XLIFF scenario and to tool 
> support in general, e.g.
> [
> Source segments or subsegments annotated by its:withText set to nested 
> or no, should have these two options differentially indicated to the 
> tool user. No indication is needed if the value is yes, since this 
> would be the assumed state from segment to segment.
> ]
> So maybe it is possible to have both perspectives at the same time in 
> mind? E.g. via a table based approach - column 1 "XLIFF specific", 
> column 2 "general"?
> Best,
> Felix
> Am 23.04.13 10:14, schrieb Dave Lewis:
>> Hi Christian,
>> Yes you make a good point about these requrirements being desiarable 
>> even without XLIFF, but I made that decision deliberately to get the 
>> most benefit from this task for both CAT tool ITS support _and_ the 
>> ITS-XLIFF mapping work.
>> I'd suggest we press on with the XLIFF based approach, and see what 
>> we learn from using OmegaT as a reference implementation, and then we 
>> could attempt to generalise the wording requirements. What do you think?
>> Regards,
>> Dave
>> On 23/04/2013 08:58, Lieske, Christian 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: 
>>> 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 []
>>> Sent: Montag, 22. April 2013 03:00
>>> To:
>>> 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:
>>> 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 10:17:06 UTC