[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, Yves Savourel said: > As you have said, the use of <bpt>/<ept> and other XLIFF > inline elements rather than allowing other namespaces inside > <source>/<target> is coming from the fact XLIFF is meant to > handle any format not just XML. Transcribing those other > original formats into XML is, alas, not always possible. I > know that currently most of the data I see going through > XLIFF in real-life projects are non-XML and would not be > easy to transcribe to XML. Hopefully this will change as XML > makes progress. I agree, the thing that bugs me a bit though is that when it comes to XML data XLIFF currently is not such a good fit because all data is currently treated the same, as plain text with XLIFF tags in it. As an example take: <b>hello</b> which would get encoded like <bpt><b></bpt>hello<ept></b></ept> (leaving out the attributes) Trying to check if the translator accidentally switched the b tags is a lot more difficult then it should be. Special XLIFF tools might be able to do this but it is beyond the reach of standard schema languages - except maybe for some XSL based constraints checking language such as Schematron. > It seems that the case to allow namespaces in > <source>/<target> is gaining momentum. The TC is currently > looking at how this could be implement and what rules the > XLIFF tools could follow to deal with unknown elements. Rightly so, but I also think that a kind of mental U-turn could still be beneficial for localization of XML (ignoring tool implementation issues at the moment). With that mindset the source XML would not be a structure of unknown elements that are embedded in XLIFF but rather first-class XML where 'XLIFF' elements/attributes and structures are added to (through an annotation process). This may have to be a kind of variant because I don't see how this could directly fit into the current XLIFF standard. It also means that this variant would limit itselves to XML only which is something which may not be feasible for XLIFF proper. The big XML localization picture for me currently looks like this. Source XML is annotated using a low-impact annotation language for localization information and then this annotated XML gets progressively enriched during the localization project with the elements, attributes and structure from this 'XLIFF' vocabulary. Only as much as needed for the project (modular). In a light application maybe only the trans-unit, source and target elements and structure. At the end of the process the translated XML can be filtered by removing all of the 'XLIFF' namespaced stuff. In my view the source XML is king and the localization information and structures are added to it. Maybe it's too drastic for XLIFF or XLIFF tool implementors but I value the ability to maintain the original structure and the ability to have localization information live in the same 'space' with the original XML very highly. It enables us to apply standard XML technologies on the files more easily. I think adding XML-Namespaces should definitely be considered. Namespace aware validation is becoming a little easier nowadays. It's still not easy but it is being worked on very hard (see http://dsdl.org/). > Comments such as yours are very important as they help us > move XLIFF in a direction more in tune with the users' > needs. Thanks, > Kind regards, > -yves > --Marc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]