Re: [xliff-comment] re: How to embed XML in <source>

[wax@xs4all.nl]

Hi Yves,

Since I'm not aware of the ongoing discussion on how to extend XLIFF to
include XML elements from foreign namespaces this mail might echo things
that have already been discussed elsewhere.

This use case highlights one of the major gripes I have with XLIFF at the
moment. XLIFF is XML, and I don't see the advantage of demoting the
original XML content to plain text. I think this has to do with XLIFF's
history and that it aims at covering many different formats. I would
suggest taking a U-turn and transscribing these non-XML formats into XML
and deal with them as such.

Escaped content - often in the form of HTML to bypass well-formedness
rules  - is a problem with a lot of XML that is created from CMS exports.
I don't expect it to go away but let's not make it worse ;-)

If every application of XML (such as XLIFF) would add their own layer of
escaping this will become an even bigger problem. Another (proprietary)
loc. doc format, Trados TTX, is similar in that it also reduces XML to
plain text.

I currently advise to avoid using XLIFF when source XML content is
concerned    (I may borrow the odd XLIFF element if the source XML doesn't
already provide enough structure to support localization).

Redefining XLIFF, or creating a variant, as a namespaced vocabulary makes
a lot of sense in order to make it mix better with XML. This would
probably involve major changes though.

Such a namespaced-mix would mean that the loc. doc can be validated during
the course of the whole localization process. This could involve
validation of the XLIFF and/or of the original XML (including business
rules such as string length checks etc.).

Regards,
--Marc

>
> Hi Zartaj,
>
> XLIFF is meant to be use with various file formats, XML
> being one of them, so it has a mechanism to markup inline
> codes regardless of the format.
>
> If your original file is like this:
> <myxml:string>File <myxml:accelerator
> platform="windows">O</myxml:accelerator>pen</myxml:string>
>
> You could extract it to XLIFF as:
>
> <source>File <bpt id='1'>&lt;myxml:accelerator
> platform="windows"&gt;</bpt>O<ept
> id='1'>&lt;/myxml:accelerator&gt;</ept>pen</source>
>
> One also could use place-holder instead of enclosures:
>
> <source>File <g id='1'>O</g>pen</source>
>
> Where the codes for <g> are in the skeleton file.
>
>
>
>> Why not let <source> and <target> support user-defined
> elements, so I
>> could just embed <myxml:string> without modifications?
>
> Mostly it's because the content of the <source> and <target>
> is expected to be a 'pre-parsed' content, where all inline
> codes are represented by in well defined elements. This
> allow to 'abstract' the content and make it very much easier
> for the translation tools to work regardless of the
> underlying format.
>
> However, when XML is the original format, there are
> advantages to allow extension, as you are pointing out. This
> has been a topic of discussion for some time now. And there
> are chances that <source> and <target> could allow
> extensions at some point. We are still working on how
> exactly tools would behaves when running into non-xliff
> elements.
>
> There are discussions in the mailing list, you are very
> welcome to look at them and express your opinions and ideas,
> it would help us.
>
> Thanks for taking the time to post your email.
>
> Kind regards,
> -yves
>