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,


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







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









Dr. David Filip



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>."


<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:


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