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

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

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

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

</segment>

</mtc:match>

</match>

Thanks,

ryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Monday, December 3, 2012 11:46 AM
To: Dr. David Filip; Yves Savourel
Cc: xliff@lists.oasis-open.org
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:David.Filip@ul.ie]
Sent: Saturday, December 1, 2012 11:17 AM
To: Yves Savourel
Cc: Ryan King; xliff@lists.oasis-open.org
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

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 Thu, Nov 29, 2012 at 3:47 AM, Yves Savourel <ysavourel@enlaso.com> 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\no' 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: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

xliff message