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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> The issue you outline is more general in the sense 
> that you do not even need to use an ignorable to get into 
> the described issue.

Yes, that was just a concrete example.


> So I believe that the general solution is to say that recursively 
> inherited defaults on <segment> and <mrk> need to be checked 
> against possible <sm>/<em> overrides within the unit.

I think we need to be a little bit more specific because it is quite complicated.

[[
"When used in any other admissible structural element:
The value of the translate attribute is first set to the translate of its parent element"
]]

Should split into two parts and be something like this:

[[
When used in <group> or <unit>:
The value of the translate attribute of its parent element.

When used in <segment>:
- When applied to the source content:
	- If the segment is the first among all <segment> or <ignorable> element in this unit:
		The default value of translate is the same as the one of the parent unit.
	- otherwise:
		The default value is the same as the translate value at the end of the processing of the previous <segment> or
<ignorable> element.
- When applied to the target content:
	- If the segment is the first in the target order in this unit:
		The default value of translate is the same as the one of the parent unit.
	- Otherwise:
		The default value is the same as the translate value at the end of the processing of the previous <segment> or
<ignorable> element in the target order.
]]

The requirement of dealing with the target order has some important implication: Potentially you have to look even at the <segment>
or <ignorable> elements that comes (physically in the file) after the one you are processing before you can guess the correct
translate default.

I think we should have some examples for the user to visualize this.

I'm also looking forward to more than one SOU stating this is implemented.

Cheers,
-yves

PS

On a side note: Now, after all the tweaks done to <segment> it looks like segment markers are really better when treated as
annotations like there were in 1.2. The problem related to segment markers in 1.2 was really because backward compatibility was to
be maintained and one could not have a special element for it. But it wasn't dumb at all to use annotation-like mechanism.
Having a "source/target within a segment" structure like now is fine for simple cases, but as soon as you have to work with
re-segmentation or different ordering that structure shows its limitations, while the structure "segment within source/target" has
none of all these issues.