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

Yves, 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 Mon, Nov 4, 2013 at 3:36 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

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.

Of course we need a specific solution for the spec.

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

Yes, this one is simple..

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

This is a possible approach although I do not know what mean by "at the end of the processing", however this misses the fact that the same issue as with <segment> is with <mrk>

Also I'd prefer the approach of determining the default in two steps.

1. look what default value got inherited recursively.

2. Check if it is overridden locally by an <sm>/<em> pair

Please note that you are only looking for the closest enclosing occurrence and that you are done if you do not find any <sm> within the given <unit>

This is just to explain the approach, not fleshing out the exact wording yet..

Also please note that we should avoid prescribing the implementation, an implementer can still implement both styles of defining the default using the described by Yves, as they appear to be logically equivalent..

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 believe this would be also simplified if the default was determined as local override of the structurally inherited value

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

I agree

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.

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