OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Another validation question


Ryan, I agree with Yves..
There was a discussion and there is indeed no reason to forbid target references from matches.
The description was unfortunately not updated, it comes from the time we had only source similarity in the module. But later we added also quality and suitability so there is no longer a reason to restrict the references to source text.
I also agree that source text is not text in source and would consider removing the word "source" from the definition in 2.1 an editorial clarification.
Cheers dF

dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient..

On Sep 4, 2015 18:39, "Ryan King" <ryanki@microsoft.com> wrote:

Thanks, Yves. +David and the rest of the discussion list.

 

Ryan

 

From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Friday, September 4, 2015 3:53 AM
To: Ryan King <ryanki@microsoft.com>
Subject: RE: Another validation question

 

You are right: the definition seems to not allow this.

 

The fact that there is a comment saying explicitly it is allowed make me think some discussion took place and it was decided it was fine. Which kind of make sense: why would we want to not allow pointing to a target reference?

 

David may have more thought on this. If this is allowed we should remove “source” in the definition, if it’s not allowed we should be clearer in the definition, because “source text” is not quite the same as “text in <source>”.

 

-ys

 

From: Ryan King [mailto:ryanki@microsoft.com]
Sent: Friday, September 4, 2015 12:53 AM
To: Yves Savourel <ysavourel@enlaso.com>
Subject: Another validation question

 

Hi Yves, another question for you. The part in question is highlighted below.

 

<?xml version="1.0"?>

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr"

xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0">

<file id="f1">

  <unit id="1">

   <mtc:matches xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0">

    <mtc:match id="1" ref="#m1">

     <metadata xmlns="urn:oasis:names:tc:xliff:metadata:2.0" >

      <metaGroup>

       <meta type="mytype">data</meta>

      </metaGroup>

     </metadata>

     <xlf:originalData>

      <xlf:data id="d1">[code]</xlf:data>

     </xlf:originalData>

     <xlf:source><xlf:ph id='1' dataRef='d1'/>Text</xlf:source>

     <xlf:target><xlf:ph id='1' dataRef='d1'/>Texte</xlf:target>

     <my:element xmlns:my="myNs">data</my:element>

    </mtc:match>

    <mtc:match id="2" ref="#t=m2"> <!-- Refers to a target (unlikely but allowed) -->

     <xlf:source>Text2</xlf:source>

     <xlf:target>Texte2</xlf:target>

    </mtc:match>

   </mtc:matches>

   <segment>

    <source><mrk id="m1" type="mtc:match">Text</mrk></source>

    <target><mrk id="m2" type="some:annotation">Texte2</mrk></target>

   </segment>

  </unit>

</file>

</xliff>

According to the spec this seems to be invalid, assuming source means Source (not Target) which is how I read it.

Reference - points to a span of source text within the same unit, to which the translation candidate is relevant.

Value description: IRI

Default value: undefined

Used in: <match>.

 

They seem to conflict. Just wondering, am I missing a nuance here?

 

Thanks,

Ryan

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]