RE: [xliff-comment] using xliff to translate html

["Yves Savourel" <ysavourel@translate.com>]

Hello Brian,

>> Readability of the inline marked up text.

Yes, the <bpt>, <ept>, <it> and <ph> elements make the segment much larger
than the original, even if you strip them down to the minimal (only an id
attribute). It's also especially true when the original file is an SGML or
an XML file as all the '<' and '&' of the code parts need to be escaped.
That is, alas, the price to pay for having the codes pre-parsed and in the
segment itself.

As you pointed out one solution for this is to use the <g> and <x/> elements
instead. But it has the drawback to not give access to the original code.

I think an XLIFF-enabled tool should be able to provide a display that
remove any clutter from the translator view.

The tools that would have more issues with this would be the tools enabled
for XML only, which don't know what to do with the content of <bpt> etc.
except that they should be protected. Some of those tools, like TagEditor
from Trados have option to reduce the display of tags to almost nothing on
screen, so --at least in some cases-- the bulk of <bpt>-like elements is not
too much of a problem there.

The worst case senarios would be when you translate an XLIFF file in a
format where everything is visible, like when adding a color-coded RTF layer
to a XLIFF and working with in in Word.


>> Using the <g> tag.

The <g> and <x/> tags are meant to be used a little bit differently than the
example you gave. The original codes is not inside the XLIFF content (i.e.
not in other <trans-unit> elements). Instead, it resides in the skeleton,
the file where the non-localizable parts of the original file are kept.

How you do store them there is completely up to the filter creating the
XLIFF document. For the time being XLIFF provides only:

1) a way to either embed the skeleton in the XLIFF document
(<internal-file>) or externalize it (<external-file>).

2) a way to link the <g> and <x/> elements back to the corresponding their
codes in the skeleton (by using the id attribute).

So to reuse your example, the segment would look like:

<source>Some text in <g id="g2">bold</g>, <g id="g3">italic</g>, <g
id="g2"><g id="g3">bold and italic</g></g>, and a <g
id="g4">link</g>.</source>

[Note that unlike in your example, the <p> element would not be part of the
inline codes as it's a "structural" code and shouldn't be in the segment (or
it would cause problem if you wanted to leverage the segment somewhere
else).]

As for the original codes ("<b>", "</b>", "<i>", etc.) they would be
somewhere in the skeleton.

The main drawback with this mechanism is that, because there is currently no
standard way to represent the skeleton, only tools knowing the given type of
skeleton created are able to access the original codes if they need to. The
others are left with whatever information is in the <g> and <x/> elements.

Will we have a standard skeleton format (as John also asked in his email
yesterday)? There has some talks about it in the TC meetings, but so far
nothing has been decided.


Cheers,
-yves