Fix <g> codes when adding/changing segmentation in XLIFF output
Issue #202
new
Original issue 202 created by @ysavourel on 2012-01-23T12:51:51.000Z:
Currently the output of XLIFF files using the filter can create new segments, but the inline code <g> is not fixed to ensure well-formness.
Other XLIFF inline codes (except <mrk> for which 1.2 has no solution) should be fine as they do not cause overlaps.
Comments (3)
-
Account Deleted -
Account Deleted Comment 2. originally posted by @ysavourel on 2013-07-10T14:34:33.000Z:
Could that be resolved with un-segmenting and re-segmenting?
To try. -
- removed responsible
- changed version to M38
- edited description
- Log in to comment
Comment 1. originally posted by @ysavourel on 2013-07-06T03:41:30.000Z:
We can't fix this by modifying expandCodeContent() and checking if it's an isolated marker and change the original data to the new bx or ex code.
the reason is that when a code is isolated in a fragment, it may be ok in the complete output.
For example: "<g id='1'><mrk mid='s1' mtype='seg'>text</mrk></g>"
That's 3 segments, with isolated codes in 1 and 3, but they should be normal opening/closing g tags on output.
It seems that having a TextContent-level knowledge of the codes is (again) needed for this.