Re: [xliff] mrk translate outside the content but in scope

Thanks, Yves, most of it makes sense to me, and IMHO as a bottom line it actually does not require a normative change, except possibly adding a constraint enforcing the to come logically after their <sm/>. Now as I think of it, we always assume (we e.g. do not allow em to have its own id) that <sm/>/ must always go in a pair but I am not sure if we explicitly say that anywhere in the spec..

Detailed answers inline:

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

mailto: david.filip@ul.ie

On Tue, Nov 5, 2013 at 1:01 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

> Yves, I am reacting to the use cases inline using
> my proposed algorithm..
> I first thought that yours should produce the same
> results but probably not, as your question marks do not
> seem puzzling to me..

I put the question marks because it wasn't clear to me what was the result of your algorithm. Now I know.

Good, and is it the same as yours?

I've tried to implement this and here are my conclusions:

-- We actually do not want to change the current definition with the defaults: they are fine.

I agree

It's not the default value of the
translate attribute of <segment> that depends on the overrides, it's how the value (set or inherited) is applied to the content.

I agree

-- What we are missing is a description of how an agent determines the translate state of a text is at any point in the source and
the target content.

IMHO this description should be added as a non normative example, as otherwise it would be pushing an implementation

I'm not sure where that should be added. The translate attribute section is a possible place.

Sounds plausible, will shout if I find a better place.

We could place a warning in the attribute description under the deafault values description aying that these defaults may be overridden by values set in <sm> pairs throughout the enclosing unit and that implementers should be careful about that. Your stack algorithm description could come as a possible implementation example, I would try to flesh out my abstract algorithm description, if Bryan or Tom can add an XSLT based example that we be very good.

Here is the algorithm I've tried:

Resolved value = value directly set or obtained by inheritance
Part = a segment or an ignorable element

- Create a stack of translate values
- Push a single value in the stack (the actual value does not matter).

- Get the list of the parts in the unit:
- for the source content use the parts in the order they are in the document
- for the target content use the parts in the order set by the target order attributes

- Starting at the first part of the list, for each part:
- Set the bottom of the stack to the translate value of the part:
- For a segment: the resolved translate value of the segment
- For an ignorable: the resolved translate value of the parent unit.

I don't think so, ignorable is not translatabale no matter what, it can just hold pieces of annotations that can flip parts outside of itself..

- Iterate through the content
- If an opening marker for a Translate Annotation is found:
- Push the translate value of the annotation at the top of the stack.
- If a closing marker for a Translate Annotation is found:
- Remove the corresponding item in the stack

At any time, the top of the stack has the translate value to apply to the current content.

This method has one caveat: The closing markers of each translation annotations must be after its corresponding opening marker.
Technically I don't think this is enforced by a constraint or a PR. It should be OK for the source content. But the target ordering
may introduce some problems if it's not done properly.

I think we do not have this, I propose to add this to the <sm/> and descriptions.

I think we should say for <sm/> that it MUST have a closing within the enclosing unit (and vice versa)

AND

that must come logically after its corresponding <sm/>

I'd also add a warning that the order attribute has to be considered in target for determining the logical order..

There are probably other ways to do it. Hopefully Bryan will come up with a nice way to do it in XSLT.

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

xliff message