[xliff] RE: [xliff-comment] Thought in allowing other namespaces insegments

[Doug Domeny <ddomeny@ektron.com>]

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


-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Tuesday, January 14, 2003 9:49 AM
To: xliff-comment@lists.oasis-open.org
Subject: [xliff-comment] Thought in allowing other namespaces in
segments


Hi everyone,

One thought in that topic:

One of the features of using only a standard set of XLIFF inline element
inside segments is that it allows to control any text that is inside tags.
For example, when using only XHTML elements in a segment how would we be
able to isolate the text of the ALT attribute in the following example?

<source>Click <html:img src='button.png' alt='Start Button'/> to
start.</source>

It would require the tool to know about what attribute is translatable in
HTML, or other XML namespaces as if we allow XHTML I don't see why we
wouldn't allow others vocabularies.

In the current XLIFF syntax we can isolate the data:

<source>Click <ph id='1'>&lt;img src='button.png' alt='<sub>Start
Button</sub>'/></ph> to start.</source>

In my mind, this is not the only problem with allowing extensibility in
segment content, but this one may be a good illustration of how using a
standard tag set to encapsulate the inline codes makes the format more
portable from tool to tool.

Just a thought.
-yves

PS: Actually, in my opinion, using <sub> isn't cool: the best way is to
extract the text into a separate segment so it could be leveraged regardless
where it's located and the initial segment could also be leveraged
independently of the content of ALT. And that also illustrate the fact that
'things' need to be done to the inline codes to be really re-usable in
translation tools.

-ys


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>