[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]