OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff] Re-ordering of inline codes


Hi David, all,

> [Please note that Extractors that make whole segments uniformly 
> reorderable or not, do not need to bother about the third value.]
> ...
> . When specifying adjacent sequences of codes that MUST NOT be 
> reordered, Writers  MUST set the first code of each sequence to 
> canReoder="firstNo".

This would allow the first element of a sequence sometimes set to firstNo, sometimes set to no (e.g. when there is an element with
canReorder='yes' before). I think being consistent is better, especially since it actually simplify the work of the
writer/extractor.


> [Modifiers merging segments will need to introduce the third value 
> if a mixed sequence is the result, this would need to be added 
> or referenced from resegmentation PRs]

Like for translate, you need to take the whole content into account, not work segment by segments. There is no reasons to prevent a
non-reorderable sequence to span two or more segments.


Here is my proposal C:

--- In section 2.3.1.5 canReorder

Change:

[[
Value description: yes in case the code can be re-ordered, no in case the code cannot be re-ordered.
]]

To:

[[
Value description: yes in case the code can be re-ordered, firstNo when the code is the first element of a sequence that cannot be
re-ordered, no when it is another part of such a sequence.
]]


-- In section 2.7.2.6 Editing Hints

Add:

[[
Inline codes re-ordering within a source or target content can be limited by defining no-reordereable sequences. Such sequence is
made of two or more consecutive inline elements where the first element has canReorder set to firstNo and the next elements have
canReorder set to no.

PRs:

- The number and order of the inline elements making up a sequence MUST NOT be changed.
- A whole sequence MAY be moved before or after another sequence.
]]

-- In section 2.2.3.5 ec:

Change:

[[
The values of the attributes canCopy, canDelete, canReorder and canOverlap MUST be the same as the values the ones in the <sc>
element corresponding to this end code.
]]

To:

[[
The values of the attributes canCopy, canDelete and canOverlap MUST be the same as the values the ones in the <sc> element
corresponding to this end code.

The value of the attribute canReorder MUST be 'no' if the value of canReorder is firstNo in the <sc> element corresponding to this
end code.
]]


-- In section 2.9.3 Segmentation Modification

We'll need to have some text related to re-ordering. But, as I mentioned several times, I still had no time to come up with a
proposal for that whole section.


Cheers,
-yves



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]