Resolution proposal/Call for Dissent Re: [xliff] mrk translate outside the content but in scope

Hi all, I 'd like to suggest a resolution for this one.

This is based on this thread the discussion that we had in the TC and the discussion among Fredrik, Yves, and myself that continued after the meeting lost quorum.

Although the above described algorithm is unambiguous we figured that it can be simplified by dropping the translate attribute from segment.

So the last structural default is set on unit and the <sm/>/<em/> overrides are more naturally understood if you do not need to worry about segment defaults.

Please note that both type of markers (well formed <mrk></mrk> spans or <sm/>/<em/> pairs) will still inherit their translate default from unit XOR its parent <mrk>. These defaults will be however overridden by the lowermost enclosing <sm/></em> pair that has the value set explicitly. Same as in the above described algorithm, we are still looking for several implementation examples for the algorithm, but these should be considerably simpler now.

Segmentation will have no impact on translatability because neither segments nor ignorables will carry translatability metadata.

There is another side effect: dropping of translate from segment will make the complex re-segmentation PRs less so, which is a good thing. This also disposes of Yves comment complaining about dropping translatability info on resegmentation due to current resegmentation PR wrt translate on segment.

https://lists.oasis-open.org/archives/xliff/201310/msg00079.html

*This is a relatively major change, still I will first try a call for dissent and will only propose a ballot in case dissent is expressed by next Monday.*

The proposal:

Drop translate from segment (-> drop re-segmentation PRs re translate)

Marker defaults will be inherited from unit instead of segment

Add constraints for <sm>/</em> and <sc/>/<ec/>

For both, end marker or end code must come logically after its start marker or start code.

Warning: logical order in target can be affected by order attributes within the enclosing unit

For <sm/> and <em/> only, the corresponding marker MUST be within the same unit.

For <ec/> only, id is REQUIRED if the corresponding <sc/> does not exist or is outside of the enclosing <unit>

Make the note in the translation annotation section a standard part of the normative text and change "segment" to "unit" like this:

Current text:

Note
This annotation overrides the translate attribute set at the <segment> level.

New text:

This annotation has precedence over the translate attribute values inherited from the <unit> level 

End of the proposal

If this bunch of changes is agreed on, I can implement it in the spec and ask for review of the detailed implementation.

Algorithm implementation examples can be added later, even after the third review, because they are not normative. The examples would be placed in the translation annotation section. I just do not want to tie these changes to fleshing out the algorithm implementation examples for timing reasons..

Best regards and please engage in this thread by the end of this week

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: 

On Tue, Nov 5, 2013 at 12:12 PM, Yves Savourel <> wrote:

Hi David, all,

> possibly adding a constraint enforcing the <em/>

> to come logically after their <sm/>.

Possibly. That may be the case for <sc> and <ec> too.

>> 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 didn't have a set expectation.

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

When computing the state of translate in a segment one must take account both the segment and the ignorable elements into account as

part of a whole, otherwise you simply cannot end up with the correct result.

Note also that ignorable element contains whatever the Extractors or Modifiers deem appropriate (whitespace and inline codes most of

the time). While its content is not expected to be translatable text, it may need to be adapted in some cases, for example to remove

whitespace between segments in some languages, or to adjust whitespace when re-ordering the target.

>> Technically I don't think this is enforced by a constraint or a PR.

>

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

> and <em/> descriptions.

> I think we should say for <sm/> that it MUST have  a closing <em/>

> within the enclosing unit (and vice versa)

> AND

> that <em/> must come logically after its corresponding <sm/>

I tend to agree.

But other really need to look at all this and have opinions.

> I'd also add a warning that the order attribute has to be considered

> in target for determining the logical order..

Possibly. But let's just make sure we don't add repeated warnings, notes, PRs all over the place. As a general guideline we should

be concise. In my experience, overwhelming the reader with repeated information often leads to confusion and make things look more

complex than they are. The Segmentation Modification section is an example of that. I'll get to that at some point.

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