[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
<source xml:lang=”en-us”>hello world</target>
<target xml:lang=”es-es”>hola mundo</target>
Sounds good. Let’s keep source in Reference Language.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
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..
Dr. David Filip
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Thu, Nov 29, 2012 at 3:47 AM, Yves Savourel <email@example.com> wrote:
Hi Ryan, all,
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.
I assume you mean: allow more than one <mtc:matches> where we currently allow one? Not in *all* extensions point. right?
> Additionally, PR for a “reference match” would be to allow an xml:lang on the target
- reference='yes\no' and allowing a different language for xml:lang in those with reference='yes' seems ok to me.