[xliff-tools] XLIFF usage

[Josep Condal]

Hi Steve,

> Steve is fine (only my mum calls me Stephen!)

Sorry about my strange message, due to - hopefully temporary - mental
turbulences. For some reason I had arrived to the conclusion that Steve
and Stephen were two completely different names and all of a sudden I
had a strong urge to apologize. :)

>>>> START OF QUOTE
So here's my dilemma.  We currently have tools  that extract
translatable content from whichever file formats we're  interested in.
So, I take a PO for example, it gets parsed (LEX/YACC) and then
translated within a tools environment.  The complexities of the
meta-data schema are hidden (as it should be) and the parser also comes
with a generator to create the translated output format - end to end
process.  The database format might proprietary or represented in XLIFF
but the interface to this data would be open.  

I've understood your comments correctly, then in the "new world order",
I'd do this....

[ Develop ]-->Src PO-->XLIFF-->[ Translation ]--> Tgt PO-->[ Test ]

But in the current model it would be...

   [ Develop ]-->Src PO-->[ Translation ]-->Tgt PO-->[ Test ]

So now, I have to create a PO parser AND a forward and reversion XLIFF
to PO transformer.

Seems like I have to do more work.  I do however see the benefit in
having, say, an Alchemy Catalyst dump it's TTK format to XLIFF so I
could use the same translated content with gTranslator/KBabel or
whatever other GUI tool made use of XLIFF repository information.

>>>> END OF QUOTE

The idea would be that XLIFF is the preferred representation of any
given home format, and the closer it appears to the real source (for
example if gettext generated XLIFF instead of PO and back), the most
sense it makes (as your diagram above reflects).

>>>> START OF QUOTE

Understood, absolutely, but isn't the value in XLIFF really to do with
helping me move my translated assets (with their meta data) between
systems rather than create yet another file format?  The benefit for me
is a loss-less transfer when  tooling technologies become available that
afford me a higher % and quality of leverage.

>>>> END OF QUOTE

XLIFF is per definition an exchange format, but in practical scenarios I
personally see most of the opportunity into making the subject format
more stable as a starting point for development of tools and therefore
be able to adjust the chosen tool to the characteristics of the project.

In an scenario where the roundtrip filters are essentially available and
the best ones prevail (with the help of representation guides as
official guidance), the tool developers can focus in the features of
their software to the user rather in solving the same problem of
interpreting the new format in town.  

I see less opportunity, but still an option at Alchemy's choice, in the
Alchemy Catalyst scenario that you mention, because the TTK format is a
little bit away from the home format.

In other words, an .RC file (home format) is willing to be translated so
XLIFF can help build a process behind that, while a TTK file is probably
willing to be translated with Catalyst so XLIFF could be not a practical
option here. Let's say it depends largely on Alchemy willingness to do
so, even if you decide to reverse-engineer the TTK file and build a
filter for it.

Also XLIFF allows for exchange. While I see a relatively high risk of
trouble by exchanging without extensive interoperability tests, what is
clear is that many quality-oriented features (LINT-like stuff but
linguistic, for example) can be built into into a more stable format
such as XLIFF.  This way, sometimes you buy, sometimes you make.

>>>>
My view would be that a good tools environment abstracts this complexity
anyway.  I certainly wouldn't send raw XLIFF out because I'd then have
to add LINT checks to the inbound materials.
>>>>

Yes, I meant actually that the opportunity of making the format more
stable, allows for interesting tools to be developed on it more easily
than if the project implies complex home formats. Some of the tools in
the market are very good at what they do and may fulfill all your needs.
(Or apparent needs as perceived by you. For example, I hadn't needed the
"concordance" function for a few years (before 1998 more or less)
because I had used always CAT tools without it and life continued
without trouble, but when I discovered it, I saw that the value it
brought was enormous and cannot imagine a single translation process
without it playing a important role.  That's why we developed ApSIC
Xbench, to be able to bring concordance to the system level rather than
at the application level).

Regards,

Josep.