[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>
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: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Helena S Chapman 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.)
<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:David.Filip@ul.ie]
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: david.filip@ul.ie
On Tue, Dec 11, 2012 at 8:08 PM, Ryan King <ryanki@microsoft.com> 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 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”>
<segment>
<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 Sounds good. Let’s keep source in Reference Language.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
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: david.filip@ul.ie
On Thu, Nov 29, 2012 at 3:47 AM, Yves Savourel <ysavourel@enlaso.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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]