RE: [xliff] Inline codes in Change Tracking

[Patrik Mazanek <pmazanek@sdl.com>]

Hi,
From my point of view, using mrk elements to create a reference to actual change is preferred. It's then very easy to see where exactly the change applies to.
If we use the full segment in the change, it will be very difficult for tools to show changes - you need to create comparer which might get really tricky with the heavily structured content.
Regards
Patrik

www.sdl.com

SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.

SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Monday, December 7, 2015 1:27 PM
To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

Hi Fredrik, all,

Good point indeed on the danger of id and segments.

So, the idea is then to use appliesTo="source" or "target" (and property="content") and for those special cases store the changes ignoring the segments.

Or, second solution: to set an mrk in the content and again for that special case use "source" and "target" with ref set to the id of the mrk. Do we need to have a type value defined for the second option (like mtc:match is defined for the translation candidates)?

Both options behavior would be quite different from the behavior for a note for example. So, the specification needs to be very clear about how to do this (and well exemplified).
The other question then is how Change Tracking supports tracking the changes in segmentation if someone wants to do so?

A third possible option would be to always store the entire content (without the segment?) of source or target in <item> (still saying that "content" for "source" and "target" mean the whole thing.

That last option may allow the tracking of segments too.
The drawback is the size. But overall it may be safer than with mrk or segments.

-ys


-----Original Message-----
From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com]
Sent: Monday, December 7, 2015 3:06 AM
To: Yves Savourel <ysavourel@enlaso.com>; 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

Hi Yves, All,

I think that using references to segment "id"s are a bad practice unless you also disallow segmentation changes for the unit. If the unit is re-segmented or the content re-distributed between existing segments the references will be dangling. In some cases it may be possible to update the referencing data to match the new segmentation but that is not trivial or probably even wanted or possible in some cases.

A definition that "source" mean the whole source of the unit and "target" the whole target of the unit would be safe with respect to segmentation changes. Using <mrk> tags would make sub-unit change tracking of spans safe as well.

I think I raised the danger of having "id" on segments and how it would impact re-segmentation before. In my opinion not having ID's on segments would be better as it would force all implementations to use schemes that are compatible with segmentation changes.

Regards,
Fredrik Estreen

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 6 december 2015 21:17
To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

Hi all,

Another question related to change tracking:

In the example 5.6.6 (http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#d0e15038)

Some revisions are for the source, other for the target. But there is only one segment in that example. How do we indicate a given source or target element when there are several segments?

I assume we can't use the ref attribute since there is no id on <source> or <target>, and the definition for ref clearly requires an ID value.

On the other hand the definition of ref ("Holds a reference to a single instance of an element that has multiple instances within the enclosing element.") doesn't really say what the reference has to be for the element the revisions apply. It's implied in the example for the <note>, but it's just an example. Does that mean I can do <revisions appliesTo='target' ref='seg1'> and assume tools will know these revisions are for the <target> of the segment id=seg1?

Any clarification would be welcome.

Thanks,
-ys

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Sunday, December 6, 2015 1:01 PM
To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

To complement my initial questions: here is an XLIFF file.
Is it a valid one or not?

Thanks,
-yves


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Saturday, December 5, 2015 12:54 PM
To: XLIFF Main List <xliff@lists.oasis-open.org>
Subject: [xliff] Inline codes in Change Tracking

Hi,

I'm looking at how to represent inline codes in the <item> element of the Change Tracking module (for 2.1) and I'd like to make sure it doesn't break the 2.0 constraints. I'd like to double-check my interpretation.

The simplest way to store an old version of the translation of a segment is to copy it in the CTR's <item> element:

<unit id='1'>
<ctr:changeTrack>
 <ctr:revisions appliesTo="segment" ref="s1">
  <ctr:revision>
   <ctr:item property="content">This is a <pc id='1'>sample</pc></ctr:item>
  </ctr:revision>
 </ctr:revisions>
</ctr:changeTrack>
<segment id='s1'>
 <source>C'est un <pc id='1'>exemple</pc></source>
 <target> This is an <pc id='1'>example</pc></target>  </segment> </unit>

The potential issue there is the <pc>'s ID.

The specification says the following for the attribute id:

[[
When used in <segment>, <ignorable>, <mrk>, <sm>, <pc>, <sc>, <ec>, or <ph> elements:

- The inline elements enclosed by a <target> element MUST use the duplicate id values of their corresponding inline elements enclosed within the sibling <source> element if and only if those corresponding elements exist.

- Except for the above exception, the value MUST be unique among all of the above within the enclosing <unit> element.
]]

In the representation above we get three <pc id='1'> in the <unit>: The one in <source>, the one in <target> and one in <item>. It seems to me that, according the constraint, the ID of <pc id='1'> in <item> is not valid since it is duplicated within <unit> and it's not in a <target>.

1) Is my assumption (it's not valid) correct?

2) If so, how did manage to get away with it for <match> (The Ids in the <source> of <match> can be the same no?).

Thanks,
-yves


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

This message has been scanned for malware by Websense. www.websense.com