[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Cloning of <g> elements
Hi
Magnus,
I believe that
(a) is a reasonable assumption to make. If you don't carry across all the
attributes (DNA?) of the original tag then would it really be a
clone?
As I understand
it, the cloning ability is there primarily to allow for formatting that needs to
be split in the <target> element because the original
text span has been split in the translation. For example:
<source>The <g id="1" ctype="bold">big black</g>
cat.</source>
<target>The <g id="1" ctype="bold">gros</g> chat <g
id="1" ctype="bold">noir</g>.</target>
I understand that
you might want to clone the <source> tags in order to
segment the original source text. Although I'm not overly familiar with the work
of the segmentation subcommittee I would guess that you're looking to introduce
something along the lines of <seg>....</seg> in the
<source> element and that XML rules dictate that you're
not allowed to have <seg>...<g>...</seg> so
you'd be looking to replace this with
<seg>...<g>...</g></seg><g> with
the <g> being cloned (I have an HTML verifier which does
something similar).
What makes me
nervous is the fact that the <g> might not be "clonable"
and that the original XLIFF filter wouldn't be able to handle multiple
occurrences of a particular <g> tag. Is there a reason
why it's not possible to simply use an empty <seg/> tag
to indicate where the text should be segmented? This would mean that you
wouldn't have to clone elements from the original
<source> and also has the added advantage that
this element can simply be ignored when the XLIFF file is merged later in the
process.
FWIW, I
think that an element would have to have an explicit
clone="yes" before it can be cloned with
confidence.
Regards
David Pooley
Software Architect SDL International -----Original Message-----
From: Magnus Martikainen [mailto:Magnus@trados.com] Sent: Tuesday, January 25, 2005 11:13 PM To: xliff Subject: [xliff] Cloning of <g> elements Hi all, Following a discussion in the
segmentation subcommittee today I took an action item to post a question to the
main XLIFF committee requesting a clarification on how cloning of <g>
elements should work. As you may be aware, the <g>
element has an optional attribute named clone, with a default value "yes". This
implies that all <g> elements that do not have an explicit clone="no"
attribute value may be cloned by any tool processing the XLIFF
content. This functionality is of special
interest to the segmentation subcommittee, and our current work-in-progress
proposal for representation of segments relies on the ability to clone <g>
elements that span segment boundaries in order to be able to introduce
segments. For these reasons I would like to
have the following assumptions confirmed: a)
When a <g> element
is cloned, all attribute values of the original <g> element, including the
id and xid values, are replicated into the clone. Example:
<source>Some <g
id="1" ctype="bold" xid="42" ts="offset:983">marked-up</g>
text.</source> <target>Some <g
id="1" ctype="bold" xid="42" ts="offset:983">translated</g> marked-up
<g id="1" ctype="bold" xid="42"
ts="offset:983">text</g>.</target> b)
The current specification
mentions that multiple copies of the source <g> element may be placed in
the <target> content. For segmentation purposes we would also need to
clone them inside <source>. Would this be a reasonable
extension? Whatever the outcome I would suggest
that we update the XLIFF 1.1 specification to clarify how this mechanism is
intended to work. Best
regards, Magnus
Martikainen |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]