MHonArc v2.5.2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xliff] Current XLIFF schema. Converting XHTML to XLIFF.
Yves and others,
It seems to me that there are really two distinct XML vocabularies.
1) XLIFF which is the structure or framework used to transport the content.
This part is really the interchange file format. It is extensible with
optional "any" attribute and elements allowed throughout the structure as
long as the namespace is different. Here the specification acknowledges that
it does not cover all possible uses for XLIFF. Even though XLIFF is for
interchange between disparate systems, it allows for system-specific
extensions that survive the round-trip.
2) The second vocabulary is for the content itself. This specification is
closed and minimalistic. It does not include extensibility, presumably
because the content editors are implemented only for the small set of
placeholder tags. This also implies that new tags cannot be added to the
specification without causing problems to the editors. It appears to me that
this part of the specification is very similar to the TMX tags for content.
This is my mental model of how the translation process works. My background
is as a user of translation services, not a provider. As I see it, the XLIFF
data will be passed to an XML processor to extract the <source> and pass it
to an editor for translation. That editor is not completely XLIFF aware, but
knows only the few tags allowed within <source> and <target> elements, for
example, <g> and <ph>. Once the translation is done, the content is
re-packaged by an XML processor to return the XLIFF data back to the
recipient.
XLIFF data <----> XML processor extracts content <----> content translation
(allows only a few tags)
Please let me know if I am misunderstanding it.
To convert any XHTML tag to <g> or other appropriate XLIFF tag, the values
for the 'ctype' attribute would have to be either open-ended, allowing any
value, for example, ctype="textarea" or have a predefined value, like
"other", that would be generic. For example, I would need to convert XHTML
paragraphs (<P>) and tables (<TABLE><TBODY><TR><TD>) to <xlf:g> elements.
This is how I converted hyperlinks (A) and images (IMG) to XLIFF.
<xlf:source>Enter the body text of your <xlf:g ctype="link"
id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image"
id="IDAGB4R"></xlf:g>
</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>
Now that prop-group and prop are deprecated, I would use a custom namespace
element instead, for example:
<xlf:source>Enter the body text of your <xlf:g ctype="link"
id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image"
id="IDAGB4R"></xlf:g>
</xlf:source>
<xlf:target>...</xlf:target>
<my:tag name="IDA5A4R">
<a href="http://www.w3.org/xhtml"; target="_self" title="eXtensible
HTML"></a>
</my:tag>
<my:tag name="IDAGB4R">
<img src="fig1.gif" alt="fig one" width="11" height="21"
align="right"></img>
</my:tag>
The <my:tag> elements store the original tag name and attributes. BTW, the
id values were automatically generated in an XSLT using the XPath function
generate-id().
Does this conform with the basic principle behind tagging content?
On a slightly different topic, I also have a proprietary vocabulary that I
use in the original XHTML document to indicate which parts should be
extracted to an XLIFF document for translation. The original XHTML document
is essentially an XLIFF skeleton (skl) file. I know there has been some
discussion of putting XLIFF tags into XHTML documents, but I did not see how
to apply them, so I can up with my own. I only needed two tags: <skl:text>
and <skl:block>. Each has a required 'id' attribute, which must be unique.
This would seem to be a third XLIFF vocabulary that applies to skeleton
files that are XML compliant.
I've only recently joined and I don't want to delay the specification
process. My hope is to be able to use XLIFF with original XHTML content in a
process that is automated as much as possible. I am willing to have these
discussions deferred to a more convenient time. Perhaps a case-study or
"best practices" document would help me. Do any exist yet for XHTML
applications?
Regards,
Doug Domeny
Ektron, Inc.
+1 603 594-0249
http://www.ektron.com