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 all,

I've implemented the changes for the canReorder attribute and identify a possible small change that would make things a lot easier
for both extraction and validation:

Currently we define a "sequence" as this:

[[
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.
]]

When extracting you may know that an inline code should not be reordered but based on our definition you should mark it so only if
there are two or more of them. This forces the extractor to do some look-ahead or back-writing. Allowing sequence made of a single
element would simplify things. Obviously such sequences would be moot, but they wouldn't hamper anything either.

So I would propose to amend the text above to:

[[
Inline codes re-ordering within a source or target content can be limited by defining no-reorderable sequences. Such sequence is
made of a first inline element with canReorder set to firstNo and zero or more consecutive elements with canReorder set to no.
]]

Cheers,
-ys





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