xliff-inline — archive

[Fredrik Estreen]

Hi Yves, I thought a bit about this (re-ordering targets) and I think it has some interesting implications for both inline codes and BiDi. For inline codes it means we need the ID of the codes to be unique in the unit and not segment. And we need to allow the user to use codes from any segment in the <unit> in any other segment as well as mix inline tags from multiple segments in one segment. That in turn will complicate tag checking as you need to check the whole unit and not just a segment at a time. It also complicates match target generation from TM operations as you will send a source segment with possibly a different tag set then you need in target. En example when this arise would be if you have a text with multiple segments that are reordered in the translation for linguistic reasons but need to keep a span starting inside the first and ending inside the last for stylistic reasons. Add some references or index markers which follow the language and you get a mix. How match generation would be able to get a copy of the actual source tag in another segment into target I do not see now. And we need to really copy in order to preserve potentially unknown data in module or third party namespaces. So the processing expectations has to allow this and generally operate at the unit level instead of segment level. For BiDi it provides the answer to where we reset the Unicode BiDi algorithm, segment or unit. I think we need it to be at unit level with re-orderable target. But that seem most in line with the normal per paragraph behavior. It will however be a bit more difficult to implement. Regards, Fredrik Estreen >