[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>
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: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Helena S Chapman 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.
<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]