[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff-comment] re: How to embed XML in <source>
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'><myxml:accelerator > platform="windows"></bpt>O<ept > id='1'></myxml:accelerator></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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]