MHonArc v2.5.2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xliff] RE: [xliff-comment] Thought in allowing other namespaces insegments
All,
Thank you for your comments Yves. They help explain some of the reservations
to allow extensions in the segments.
Extensions in other parts of the XLIFF document are not interpreted by the
XLIFF processor. They are ignored, but preserved through the round-trip.
That is, any elements with a non-XLIFF namespace are not lost or modified
during translation.
Likewise, non-XLIFF tags with <source> and <target> are ignored. They are
not interpreted. Therefore the XLIFF processor does not need to understand
or do any 'thing' with them. They just must be preserved. In the example of
the <xhtml:img> tag, the ALT text would not be translated as shown in the
example. If the ALT text were to be translated, the original author would
create a separate <trans-unit> for it (this is how I implemented anyhow).
Hyperlinks (<xhtml:a>) would also typically be broken up into separate
<trans-unit> elements. This way the XLIFF process need not know anything
about the xhtml tag or their attributes.
So, with <xhtml:img> and <xhtml:a>, there is any significant benefit to
allowing them in <source> and <target>. However, more comment xhtml tags
like <p>, <b>, <strong>, <i>, <em>, <font>, <span>, <div>, should, in my
opinion, be allowed (and ignored) in <source> and <target> elements.
This is an example of allowing non-XLIFF namespace tags, but only for tags
to be ignored. Note that the <img> and <a> tags are converted to standard
XLIFF placeholders (<xlf:g>), but <p> tags are left as is. The <xlf:prop>
elements are used to store the original XHTML needed to convert the <xlf:g>
elements back to XHTML.
<xlf:trans-unit id="para1" datatype="html">
<xlf:source>
<p>Enter the body text of your <xlf:g ctype="link"
id="IDA5A4R">XHTML</xlf:g> document here</p>
<xlf:g ctype="image" id="IDAGB4R"></xlf:g>
<p>second Enter the <xlf:g ctype="link" id="IDAPB4R">body</xlf:g> text of
your XHTML document here</p>
</xlf:source>
<xlf:target>
</xlf:target>
<xlf:prop-group name="IDA5A4R">
<xlf:prop prop-type="tag">
<a href="http://www.w3.org/xhtml"; target="_self" title="eXtensible
HTML"></a>
</xlf:prop>
</xlf:prop-group>
<xlf:prop-group name="IDAGB4R">
<xlf:prop prop-type="tag">
<img src="fig1.gif" alt="fig one" width="11" height="21"
align="right"></img>
</xlf:prop>
</xlf:prop-group>
<xlf:prop-group name="IDAPB4R">
<xlf:prop prop-type="tag">
<a href="#" target="_blank" title="opens in new window"></a>
</xlf:prop>
</xlf:prop-group>
</xlf:trans-unit>
Of course, now that <prop-group> and <prop> are deprecated, I would use a
custom element instead. BTW, the
id values were automatically generated in an XSLT using the XPath function
generate-id().
I believe this approach fully meets the intent of XLIFF. As you can see, the
XLIFF processor does not need any intrinsic knowledge of the foreign
namespace. Of course, if it did, it could use the XHTML tags for display
purposes, but should NOT examine attributes for translatable text.
Regards,
Doug D
Ektron, Inc.
+1 603 594-0249
http://www.ektron.com