← Prev in month ← Prev in thread

Requirements for <sc> and <ec>

From
Yoshito Umaoka <>
Date
2022-04-26T19:08:43+00:00
ID
Thread
Requirements for <sc> and <ec>
Dear XLIFF experts,

 

I was looking at some issues related to <sc>/<ec> handling and reading XLIFF 2.1 specification closely.

 

The attribute isolated MUST
 be set to yes if and only if the <ec> element
 corresponding to this start marker is not in the same <unit>,
 and set to no otherwise.

If there are <sc> and corresponding <ec> are in a same <unit>, then it's NOT isolated. It looks this statement is very straight forward, but it becomes ambiguous if this constraint
 also applies to <target>.

The example in this section is below ?

<unit id="1">

  <segment>

    <source><sc id="1" type="fmt" subType="xlf:b"/>

        First sentence. </source>

  </segment>

  <segment>

    <source>Second sentence.<ec startRef="1" type="fmt"

        subType="xlf:b"/></source>

  </segment>

</unit>

But the spec is not clear about the case when only one segment has translation available.

<unit id="1">

  <segment state="translated">

    <source><sc id="1" type="fmt" subType="xlf:b"/>

        First sentence. </source>

    <target><sc id="1" type="fmt" subtype="xlf:b"/>

        最初の文。</target>

  </segment>

  <segment>

    <source>Second sentence.<ec startRef="1" type="fmt"

        subType="xlf:b"/></source>

  </segment>

</unit>

Does above valid? When translation memory is managed at each parsed segment level, then this could happen. I think the constraints should only apply to <source> part, otherwise,
 a single unit cannot be partially translated.

BTW, I wanted to check if the XLIFF is validated with the
XLIFF Validation Service. I found the example in the XLIFF specification was invalidated with the message:
Reason: <sc> element without matching <ec> in <source>. Rodolfo, you might want to look at this.

 

-Yoshito
← Prev in month ← Prev in thread