[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Call for testers: xliffRoundTrip Tool upgrade to XLIFF 1.2
Hi Bryan, I can spend some time trying out the compiled version. BTW: xliffRoundTrip is the base for one of the extract-merge module
in Drupal :) Cheers, -ys From:
bryan.s.schnabel@tektronix.com [mailto:bryan.s.schnabel@tektronix.com] Hello, I've
finally begun updating my open source xliffRoundTrip Tool. I'm asking for
testing help. First, (1) if you have time, please read the explanation of what
I've done, and comment on whether you think I'm on the right track. Second, (2)
if you have even more time, please volunteer to let me send you a compiled
version of my new program, give it a try (test it with some of your samples),
and let me know if you think I'm on the right track. Third, (3) if you have
even more time, and are comfortable compiling source code, please volunteer to
let me send you my new source code, compile it, give it a try (test it with
some of your samples), and let me know if you think I'm on the right track. If
you volunteer to do either (2) or (3), I will include a list of known bug fixes
in the works, so you don't waste your time commenting on them. As
for timing, anyone interested in helping at level (1) can do so starting now,
by reading the rest of my note. By mid-next-week (maybe May 20) I'll be ready
to send compiled beta test versions to those who are interested in helping at
level (2). And if you're interested in testing at level (3), I hope to have my
source code somewhat presentable by early June. If
you don't have any time, that's understandable. If you have time to do at least
(1), please read on. Hopefully
many of you already know that the xliffRoundTrip Tool works like this: -
begin with any well-formed XML source file* - push the "XML to XLIFF"
button, and get an XLIFF file -
translate the target strings -
push the "XLIFF to XML" button, and get an identical translated XML
file *
(at the moment non-namespaced XML source works better - but I hope to handle
namespaces in the next version as well) Here's
the track I'm taking. The first modest goal is to update the
xliffRoundTrip Tool to use XLIFF 1.2 instead of 1.1 (if I'm going to ask
tool makers to keep up-to-date with current XLIFF versions, the least I can do
is keep my tool up-to-date). The second goal is to incorporate a
minimalist approach. i.e., embed the XML
source file structure in the XLIFF header (unfortunately I
cannot embed XML in the skl element, so it must be embedded into the closest
extensible place in the header, which is adjacent to the skl). The third goal
is to modify (and debug) the GUI a little bit; pretty it up. Future goals
include adding support for ITS, xml:tm, and to make a DITA-specific version. Here's
how far I've gotten with my update. Start
with any well-formed XML, like this: (intentionally
used a file with very exaggerated nesting, and mixed content) <rooty
sort="o12345"> Push the
"XML to XLIFF" button, and get this: <xliff
xmlns="urn:oasis:names:tc:xliff:document:1.2"
xmlns:xmrk="urn:xmarker" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2
xliff-core-1.2-strict.xsd
urn:xmarker xmarker.xsd"
version="1.1"> Translate
the target strings, like this: <body> Press the
XLIFF to XML button, and get this <rooty
xmlns:xmrk="urn:xmarker"
xmlns:xlf="urn:oasis:names:tc:xliff:document:1.2"
sort="o12345"> Believe
it or not, upgrading to XLIFF 1.2 was not as trivial as one might expect. In
order to support the embedded skl file, a separate XML schema is required
(because we have the processContents="strict" set in the schema - I
personally think we should set it to "skip" or "lax" for
XLIFF 2.0). Anyway,
please let me know if you'd like to help me test. Thanks, Bryan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]