Next in thread →
Next in month →
Re: [xliff] RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and Proposals>
I can confirm that Oracle has a similar use case as MS'. There are
a few language pairs of French, Spanish, Chinese and Portuguese
for which we consider to apply such use case.
For the moment, we have a two-pass process. After the first pass
builds XLIFF files for the primary target language, the second
process runs to add the match suggestions from other languages to
the XLIFF files as 'comment' (not as part of <alt-trans>).
Therefore all references are in the same XLIFF files. No
additional materials are delivered.
The point of having them as part of comment is similar as the
point of having the "reference" attribute. I believe the original
suggestion aligns with what we have been doing.
However, processing requirements would be quite important to avoid
any different expectation/implementation for the same feature.
On 18/01/2013 12:34, Helena S Chapman
wrote:
In that case, the
XLIFF TC could seriously
consider taking in the entire Lingport effort which Arle is
quite familiar
with. Bottom line, if we plan to build a kitchen, might as well
install
the sink. From my stand point, I disagree with this approach but
that is
a bigger issue for the TC to debate.
From:
"Kevin O'Donnell"
<>
To:
Helena S Chapman/San
Jose/IBM@IBMUS, Ryan King <>
Cc:
"Dr. David Filip"
<>, Shirley Coady
<>,
"" <>,
Yves Savourel <>
Date:
01/18/2013 01:40 AM
Subject:
RE: [xliff]
RE: Reference Language <was: [xliff] 1.2 to 2.0 Gaps and
Proposals>
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 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:
[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\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:
For additional commands, e-mail:
--
Jung Nicholas Ryoo | Principal Software Engineer
Architecture Review Board | WPTG BIS Dev
| OSN
Phone: +35318031918 | | Fax: +35318031918 |
Worldwide Product Translation Group (WPTG), European
Development Centre
Oracle Ireland | Block P5, Eastpoint Business Park Dublin 3
Oracle is committed to developing practices and
products that help protect the environment
Next in thread →
Next in month →