[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-32) CTR Usability
[ https://issues.oasis-open.org/browse/XLIFF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65676#comment-65676 ]
David Filip commented on XLIFF-32:
----------------------------------
We had an intensive discussion in the meeting on 21st March 2017 on the future course for the CTR module. We seemed to be close to consensus towards the end of the meeting. This is to fulfill my AI to make a call for dissent that would solve/obsolete all of the open CTR issues:
=================================================
*This is a call for dissent that will be assumed to have produced a TC consensus if no material dissent expressed as a comment on this issue https://issues.oasis-open.org/browse/XLIFF-32 by Sat 25th March, 2017, 23:59 PDT*
==================================================
[CFD start]>
- XLIFF 2.1 will restate the CTR 2.0 as an extension, i.e. not as a module and non-normative [so people will be free to continue using their CTR 2.0 implementations until a new CTR module will become available with XLIFF 2.2][Work on CTR 2.2 won't be limited by the need to comply with CTR 2.0 as it won't have a module status]
- All development made on CTR 2.1 will be rolled back in 2.1 a copied to a 2.2 branch [TC members can continue work on it w/o affecting the XLIFF 2.1 timeline]
- XLIFF 2.1 will proceed towards csprd03 without the CTR update [The will be no way to reintroduce the CTR update as an XLIFF 2.1 feature once csprd03 published]
<[CFD end]
> CTR Usability
> -------------
>
> Key: XLIFF-32
> URL: https://issues.oasis-open.org/browse/XLIFF-32
> Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
> Issue Type: New Feature
> Components: Change Tracking Module
> Affects Versions: 2.1_csprd02
> Environment: http://markmail.org/thread/udmpeio52di5p44s
> Reporter: Yves Savourel
> Assignee: Chase Tingley
> Priority: Blocker
> Labels: AdoptionBlocker, request_tc_discussion, work_required
> Fix For: 2.1_csprd03
>
>
> https://lists.oasis-open.org/archives/xliff/201612/msg00015.html
> I'm still quite a bit uncertain about the CTR module.
> We have almost no example on how it would be used and no coded implementation at all.
> I've tried to manually go through the different steps of changes a unit may go through in the attached example.
> (Note that to put everything in a single file each unit is the next version of the previous one, not separate units). I've tried to
> make sure there were inline codes, segmentation (but no orphan inline-codes I'm afraid)
> The changes recorded are still very basic.
> (And BTW I have not validated it).
> I assumed the way the module is supposed to be used is as follow:
> When a change is made, the version before the change is save as a CTR entry and final result of the change set is the normal content
> of the unit.
> Is it the expected way to do it?
> This led me to several questions:
> - How do we represent entries that do not exist yet?
> For example if you add a note and there is no notes in the unit: what do we record?
> - I'm not sure what the version attribute can be used to do. Is it to link together all entries corresponding to a set of changes
> done during the same session? (Within and across units?)
> - What do we do when a change is linked to something we don't track? For example an <mrk> is added in the source when adding a
> translation candidate. We could track the new <mrk>, but not the match it corresponds to, so how could we restore a previous
> version?
> It seems to me that we have design the CTR module backward: Looking at the representation first, instead of trying to implement
> change tracking (i.e. really coding a tool doing it) and coming up with a representation based on the needs.
> https://lists.oasis-open.org/archives/xliff/201612/msg00028.html
> -- Out of context issues
> As we store content in unitItem and contentItem, there is the issue of context that crops up: Some information like xml:space or
> translate go across segment, or even across units, and may not have a physical representation in the XLIFF snippet we store.
> For example taking a segment content out of the context of its surrounding other segments may hide the fact that it is not
> translatable because there are some <mrk id='1' translate='no'> in the previous segment.
> That information cannot be stored in <contentItem>. It may be OK, but that may also have side effect when restoring the data in a
> different context.
> Another illustration of context issue: <mrk type='comment' ref="#n1"> is a comment referring to a note. If we store this in, for
> example, an <itemContent> because the translation has changed, there is no guaranty that the note n1 will stay there, or even point
> that n1 corresponds to the same note after some other changes. So we can end up with invalid references.
> Overall, it seems the content of a <revision> is bound to break the normal content constraint at some points because a) It is stored
> in a different context and b) It is not stored with all its 'dependencies'.
> -- Validation troubles:
> We say we do not want orphan <mrk>, but there are other validation issues with the stored content.
> For example the id value of a segment may exists twice: in the true content and in one (or more CTR entries). If they do have the
> same values, they break the constraint of http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#id where the
> specification says that when id is used with segment "...the value MUST be unique among all of the above (segment, etc.) within the
> enclosing <unit> element."
> I'm running into a lot of problems when trying to read back contentItem and unitItem.
> I think most of those questions are still un-answered and relate to the issue
> https://issues.oasis-open.org/browse/XLIFF-22: how the
> CTR module really works?
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]