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


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


Thoughts?
dF





Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452
mailto: david.filip@ul.ie


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




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