Reference Language

While there are doubtless other methods to distribute reference language data, I don’t believe this example below would be as efficient as the proposal to include
  it within the XLIFF document itself. How would a processing / editing tool know to look for a reference language if it wasn’t available within the file? The burden to incorporate this would shift to each tool to manage separately, potentially limiting data
  interoperability.



As an interchange format, I see strong benefit in the XLIFF document providing the necessary information to conduct localization adequately, which would include
  essential reference language data.



Kevin.
From:
 [mailto:]
  On Behalf Of  Helena S Chapman
  Sent:  Thursday, January 17, 2013 6:24 PM
To:  Ryan King
Cc:  Dr. David Filip; Shirley Coady; ; Yves Savourel
Subject:  RE: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>



So this cannot be accomplished by sending along two different XLIFF documents each contain different source-target languages, e.g. en+es or en+de, in the same "package"? It
  has to all be squeezed into the same file because the process meta-data has no ability to establish that cross referencing?
From:          Ryan King < 
>
To:          Helena S Chapman/San Jose/IBM@IBMUS, Shirley Coady < 
>
Cc:          "Dr. David Filip" <  >, "  "
  <  >, Yves Savourel < 
>
Date:          01/17/2013 12:54 PM
Subject:          RE: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>

  Sent by:          < 
>

  Let me give you a use case for a Reference Language. We localize our products and services into Luxembourgish. We usually do this simultaneous with German, however, Luxembourgish
  translators will benefit from German translations, so being able to provide them with German reference as it becomes available, as they translate, will help increase their efficiency and quality. Another use case are languages such as Quiche where it is difficult
  to find a translator who speaks English well enough. In this case, we translate into Spanish first, and then provide Spanish as a Reference language for translators, while reviewers and editors who typically speak better English, can benefit from the English
  source.


  Thanks,

  ryan
From:
    [
mailto:
]
  On Behalf Of  Helena S Chapman
 Sent:  Tuesday, December 18, 2012 7:44 AM
To:  Shirley Coady
Cc:  Dr. David Filip; Ryan King;   ; Yves Savourel
Subject:  RE: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>


  Maybe I am missing something but can someone explain to me why a 3rd target language (or 4th, 5th, 6th, 100th for that matter) for the segment has to reside in the same XLIFF file and cannot be
  managed through other outside structure? (file system, directory etc.)
From:          Shirley Coady <

>
To:          Helena S Chapman/San Jose/IBM@IBMUS, "Dr. David Filip" <

>
Cc:          "Dr. David Filip" <

>,
  Ryan King <

>, "

"
  <

>, Yves Savourel <

>
Date:          12/18/2012 10:28 AM
Subject:          RE: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>

 Sent by:          <

>



 I am personally in favor of having the third target language specified for matches – I understand at IBM the situation is a bit different, but as a tool provider, I need to accept that the XLIFF created by my tool is not necessarily going to be handled or processed
  within my tool. Being able to ship reference matches – and read other tools’ reference matches because they are in a standardized format my tool can accept – would be ideal for this type of cross-tool situation.


 Shirley
From:


[
mailto:
]
  On Behalf Of  Helena S Chapman
 Sent:  December-17-12 11:11 AM
To:  Dr. David Filip
Cc:  Dr. David Filip; Ryan King;

; Yves
  Savourel
Subject:  Re: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>


 I personally disagree with having the third target language specified for the matches. We do not do so at IBM and I believe this unnecessarily complicates the XLIFF, an interchange format, file with added complexity. We manage those complexity outside of XLIFF
  interchange process. XLIFF is not a container, it is merely an interchange format which can be used by some other container specification.
From:          "Dr. David Filip" <

>
To:          "Dr. David Filip" <

>
Cc:          Ryan King <

>,
  Yves Savourel <

>, "

"
  <

>
Date:          12/16/2012 08:56 AM
Subject:          Re: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>

 Sent by:          <

>



 Everyone, there were no comments on this one for some time.
 Can we assume consensus and change the spec accordingly?
 Summary:
 Reference language was approved as an additional feature for the matches module by a TC ballot.

 In this thread stakeholders have agreed that source will be mandatory also for reference matches

 Matches will remain the same structurally but will be able to carry matches with a third target language if marked by the optional reference flag.

 Thanks
 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
 mailto:

On Tue, Dec 11, 2012 at 11:59 PM, Dr. David Filip < 
> wrote:

 Thanks Ryan, I am OK with the whole proposal now.
 Cheers
 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

 mailto:

On Tue, Dec 11, 2012 at 11:10 PM, Ryan King < 
> wrote:

 Thanks David for the clarifications. I agree there is no need to have more than one <matches> module then as long as the following is allowed:



<unit id="1">

  <segment>

    <source>hello world</source>

  </segment>

  <mtc:matches>

    <mtc:match>

      <segment>

        <source xml:lang=”en-us”>hello world</source>

        <target xml:lang=”ca-es”>hola món</target>

      </segment>

    </mtc:match>

   <mtc:match reference=”yes”>

     <segment>

       <source xml:lang=”en-us”>hello world</target>

       <target xml:lang=”es-es”>hola mundo</target>

     </segment>

   </mtc:match>

 </mtc:matches>

</unit>



As for process requirements, it states this for <target> in the core spec:



·


When a <target> element is a child of <segment> or <ignorable> and the optional xml:lang attribute is present, its value must be equal to the value of the tgtLang attribute
  of the enclosing <xliff> element.



My comment on a needed processing requirement was to override this for <mtc:matches>  . E.g.



·


When a <target> element is a child of <segment> contained in an <mtc:match> element whose reference attribute is set to “yes”, and the optional xml:lang attribute is present,
  its value is not required to be equal to the value of the tgtLang attribute of the enclosing <xliff> element.



Thanks,

ryan
From:
Dr. David Filip [mailto:

]

 Sent:  Tuesday, December 11, 2012 1:11 PM
To:  Ryan King
Cc:  Yves Savourel;

Subject:
Re: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>


  Ryan, all

  I do support reference matches in matches module. It [the whole module] will however need more PRs than just saying that th ereference can be in a different language, which is even NOT a PR :-)


  Provided that source remains obligatory as so far..
  +---<match> +


      +---<xlf:source> 1


      +---<xlf:target> 1



  It was possible upfront to have + = one or more matches in <matches>
  <matches> 1


  +---<match> +



  Or do you mean something else? I do not think that the top element should be duplicated, you can mix reference and leverage matches in one IMHO, what would be the advantage of having more top level elements?


  Cheers
  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

mailto:

On Tue, Dec 11, 2012 at 8:08 PM, Ryan King < 
> wrote:

Do we have consensus on this proposal? E.g. Add an optional attribute reference=”yes no” with no as default. PR for a “reference match” would be to allow an xml:lang on the target different
  from the document. Additionally, we’d need to a llow more than one <mtc:matches> where we currently only allow one sine we could have both recycling and reference language present at the same time.



<mtc:matches>

  <mtc:match reference=”yes”>

   <segment>

    <source xml:lang=”en-us”>hello world</target>

    <target xml:lang=”es-es”>hola mundo</target>

   </segment>

  </mtc:match>

</match>



Thanks,

ryan
From:


[mailto:

]
  On Behalf Of  Ryan King
 Sent:  Monday, December 3, 2012 11:46 AM
To:  Dr. David Filip; Yves Savourel
Cc:

Subject:
RE: [xliff] 1.2 to 2.0 Gaps and Proposals



Sounds good. Let’s keep source in Reference Language.
From:
Dr. David Filip [
mailto:
]

 Sent:  Saturday, December 1, 2012 11:17 AM
To:  Yves Savourel
Cc:  Ryan King;

Subject:
Re: [xliff] 1.2 to 2.0 Gaps and Proposals


  Yves, Ryan,

  the source should be required in all matches, reference or not. This was one very specific piece of feedback from the toolmakers on the 2nd XLIFF Symposium in Warsaw. SDL, Kilgray, Atril, and more agreed on that having no source in alt-trans complicated
  the processing unnecessarily and said that they would provide better support to an XLIFF local matching mechanism if it had mandatory source. We should honot this wish in the matches module IMHO


  So it might seem as redundancy but actually is not so bad and explicitly supported by the voice of an important constituency..


  Cheers
  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

mailto:

On Thu, Nov 29, 2012 at 3:47 AM, Yves Savourel < 
> wrote:

  Hi Ryan, all,

 Sorry for the delay: I'm just swamped and can't find the time to read emails anymore.
> 1. Be able to specify optional custom values
> for match type in <mtc:matches>
  I suppose some mechanism similar to the subType we're using in inline codes and other places could allow for custom values while making sure a top-level category is also declared.

 Since we are discussing values for match type: I'm still not convinced that the latest list makes sense:

 am - Assembled Match
 ebm - Example-based Machine Translation
 idm - ID-based Match
 ice - In-Context Exact Match
 mt - Machine Translation
 tm - Translation Memory Match

 - 'Example-based Machine Translation' should not be there IMO: it's just MT, what type of MT is not relevant (but could be a candidate for the subtype)
 - 'In-Context Exact Match' IMO should be 'in-context' only: the fact that's an exact one is captured in the similarity (and it could be an in-context fuzzy too).
> 2. Support Reference Language in <mtc:matches>
 > • Allow zero, one or more <mtc:matches> at each extension point, because
> you might have both recycling and reference language data.
  I assume you mean: allow more than one <mtc:matches> where we currently allow one? Not in *all* extensions point. right?

 > • Add an optional attribute reference=”yes no” with no as default.
> Additionally, PR for a “reference match” would be to allow an xml:lang on the target
> different from the document and allow the <source> not to be present
> as it would be redundant information with the core <source>, e.g. Spanish
> reference for Quechua might look like this:
  - reference='yes
o' and allowing a different language for xml:lang in those with reference='yes' seems ok to me.
 - source not being present... I don't know. If we do that for those 'matches' why not for the normalmatches as well? If the source is the same.
 I think we mandated the source originally that's to simplify processing: testing for the presence of not of the source may be cumbersome for some processors (XSLT maybe?).

 We would need to update the definition of what a "match" is as well.

 hope this helps,
 -ys

---------------------------------------------------------------------

To unsubscribe, e-mail:
 
For additional commands, e-mail: