Hi David,
I think your solution would work fine.
Even better because it then allows for disjoined groups of non-re-orderable codes.
I’ll try an implementation as soon as I can.
The new PR would go in section 2.7.2.6 I guess.
And we need something in the re-segmentation section too. But that one, as I mentioned before, needs a bunch of fixes. I still had no time to come up with a proper email on it.
-ys
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Thursday, November 14, 2013 8:31 AM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
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 me
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
On Mon, Nov 11, 2013 at 4:13 PM, Yves Savourel <ysavourel@enlaso.com> 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>."
In XLIFF:
<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
around.
Thoughts?
Cheers,
-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