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

[Yves Savourel <ysavourel@enlaso.com>]

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.


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

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

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

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

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

Cheers,
-yves