[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Re-ordering of inline codes
There definitely is need for clarification. I would however advise against introducing a brand new code ordering mechanism.My proposal how to make this unambiguous would be as follows:If canReorder="yes" and canReorder="no" codes are mixed within a segment, any sequence of codes set to canReoder="no" MUST be broken with codes set to canReorder="yes"As result, having no on a single isolated code would have practical impact. But this seems OK to meThoughts?dFOn Mon, Nov 11, 2013 at 4:13 PM, Yves Savourel <firstname.lastname@example.org> wrote:Hi all,
While trying to implement validation for canReorder='no' I've run into a need for clarification:
Currently we define the re-ordering as:
A code can be re-ordered: That is, a given code can be moved before or after another inline code.
Imagine that we have three codes: two can be re-ordered, but not the last one.
"<1-canRO/> text <2-canRO/> text <3-cannotRO/>"
We cannot do this:
"<1-canRO/> text <3-cannotRO/> text <2-canRO/>"
And it seems we cannot do this either:
"<2-canRO/> text <3-cannotRO/> text <1-canRO/>"
In fact, it looks like if there is a single code that has the canReorder flag set to no in the unit, things you can move become very
limited. And I can think of examples where such limitations hamper what a translator should be able to do:
For example: "Can't find %s. Check %s. This is <b>important</b>."
<source>Can't find <ph id='1' canReorder='no' canDelete='no' canCopy='no'/>. Check <ph id='2' canReorder='no' canDelete='no'
canCopy='no'/>. This is <pc id='3'>important</pc>.</source>
It should be OK to do this:
<target> This is <pc id='3'>important</pc>. Can't find <ph id='1' canReorder='no' canDelete='no' canCopy='no'/>. Check <ph id='2'
canReorder='no' canDelete='no' canCopy='no'/>.</target>
But based on the current definition we cannot do that.
I see also issue with being able to addition or deletion of codes that should be allowed, and would not in the current rules.
Maybe we have a mechanism that is too simplistic: It seems the part that is missing is the information about in relation with which
other code one given code cannot be re-ordered. It looks like it's all or nothing.
A possibly more flexible way to allow/disallow code re-ordering would be to have a sequence defined for the codes that are related
and should be kept in the same order. For example:
<source>Can't find <ph id='1' order='1' canDelete='no' canCopy='no'/>. Check <ph id='2' order='2' canDelete='no' canCopy='no'/>.
This is <pc id='3'>important</pc>.</source>
That way we could state that the codes with a specified order must be kept in the given sequence, while any other code can be moved
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: