[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Interesting XLIFF Application
Hello, Tony and Yves suggested I should share this with other who might find this interesting. It's in the very early stages, but could be an interesting approach. In short, I've roughed out an application that takes any well-formed XML, transforms it into a "generic" XLIFF file, and then transforms it back to its original doctype (presumably after the XLIFF file has been translated). It's got many rough spots, but it should convey the concept. Please feel free to run your own XML file through, and see what happens. Thanks, Bryan -----Original Message----- From: Schnabel, Bryan S Sent: Wednesday, March 10, 2004 3:39 PM To: 'tony.jewtushenko@oracle.com' Cc: 'ysavourel@translate.com' Subject: Interesting XLIFF Application Hi Tony, You might find this interesting. I was pondering the difference between the science of writing XLIFF filters vs. the art of writing XLIFF filters. I concluded that one could actually create a reliable algorithm and write a generic application that would take any XML instance, transform it to XLIFF, and then transform the XLIFF back to the original doctype. So that's what I did. If you're interested, and have a few minutes, feel free to take a look at the attached group of files. Please feel free to test this with any of your own xml files. A caveat, this is currently in early development stages. I expect to have to fix it once it undergoes tests. This is just meant, for now, to demonstrate my strange idea. But it's worked on the variety of samples I tried so far. I'd like to get your opinion. If it's just a bad idea, please feel free to say so. If it could be polished, developed, and useful going forward (maybe the subject of an article, i.e., the kind you've encouraged me to write in the past), I'll be happy to take it a bit further. Or if it's just good for a chuckle, that's fine too; we could all use a good laugh I suppose. I included the following: -- toGenXLIFF.xsl This is an xslt that transforms any* well-formed instance into XLIFF (the XLIFF is valid, but some of the mapping I chose might need to be improved. . .). -- fromGenXLIFF.xsl This is an xslt that transforms the XLIFF back to its original doctype (the idea would be to have the target strings translated first). -- pid.xml -- ru-qsum.xml These are a couple sample input xml files I grabbed (and to some degree, hacked together for testing), that represent different doctypes and source languages. -- gen-pid.xlf -- gen-ru-qsum.xlf These are the same files, after I transformed them to XLIFF, with toGenXLIFF.xsl. -- back-pid.xml -- back-ru-qsum.xml These are the same files, transformed back to their original doctype, with fromGenXLIFF.xsl. -- GenXLIFF.bat This is a simple bat file that performs the round trip via the saxon xslt processor (any xslt processor will do). I copied Yves because I our work on the HTML project got me thinking about strategies for mapping elements depending on their content (mixed vs. #PCDATA vs. wrapper vs. EMPTY, etc.). If you feel other people from the TC would be interested, feel free to share this with whoever you like. Thanks, Bryan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]