OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-comment] Feedback from OpenTM2 XLIFF interoperabilityenhancements


Yves,

> > However, even that is problematic, because there is no way in
> > XLIFF to correlate markup in the source with markup in the target.
> 
> I believe the id of each inline element would drive the correspondence between the source and the target.

That makes sense, but the XLIFF spec doesn't say it anywhere.  It even gives
an example where the id attribute is used differently:

    For example: <bpt id='5'>xx</bpt> ... <ept id='5'>xx</ept>

    http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Struct_InLine

It also violates the common convention that the id attribute is unique
within the document (declared as "ID" in the DTD).  But I don't think
it's required so that's not a show-stopper.

So I would propose to clearly specify that the id attribute on <ph>,
etc. give the source/target correspondence.  I would further require
that markup with the same id must be identical (up to some
normalization), otherwise it creates an ambiguity of how to interpret
different markup with the same id.

We should also decide whether the correspondence is only between a
source and the parallel target, or whether it might extend to markup in
alt-trans source/target within the same trans-unit.  TM systems that are
smart about markup might want to indicate that markup in the alt-trans
target can be used as-is in the trans-unit target, but giving it an id
matching markup in the trans-unit source.  (I'm not sure anyone would do
this, but there is little harm in specifying this, because it's not hard
to generate unique ids.)

> It's how many translation tools work at a basic level. In fact there
> is no real need for much more than an id to handle inline codes in
> most use cases.

I agree, and I think it's an important use-case to keep in mind.

Andrew


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]