[xliff-tools] XLIFF usage

[Stephen Holmes]

Thanks Josep,

<< Apologies for not in-lining my response, the mail is getting quite
large!>> 

So would it be fair of me to distill this down to say that the thrust of
the XLIFF deployment in the context of this Freedesktop.org effort is to
push it as a native resource file format to replace/consolidate 1..n
existing formats?  In this specific domain to migrate from PO to XLIFF?

Is this sensible?  

What about XAML, XUL, Glade and others that have been specifically
crafted for this purpose?  Microsoft, for example, have gone to great
lengths to enhance XML markup for application specific purposes in their
Longhorn technologies (avalon etc).  This will impact Linux through the
mono technology.  I know from my own experience in localisation business
that even something like a "standard" Windows RC specification to have a
large number of interpretations - this is why we moved to binary
localisation because RC content is largely unmanageable - custom
resource formats etc (binary simplifies but doesn't remove all of the
complexities). 

If you think about it, from a tools perspective we already have stable
and proven parsers for most of the common formats in use today - these
formats are largely stable.  New formats are being intro'd all of the
time but couldn't one simply parse them into a common framework (based
on a standard API) rather than complicate the process with an XLIFF
interim?  I say this, because I simply can't see XLIFF adopt the
characteristics of a Impress Slide, a Macromedia SWF, or a streaming
audio clip - let alone media rich application markup languages.

In my opinion, native XLIFF is way too generalised and too heavy for
native application resourcing purposes.  At my company, we were
compelled (architecturally) to move to a variant that could be used  as
a native resource markup (something I'd describe as XliffLite), but even
this requires a transformer from Xliff to XliffLite and back within the
localisation cycle (not to mention the tailoring of the OASIS DTD - very
bad behaviour, I know!).

The problem, as I see it, is less about the file format and more about
the API that binds a given specification (getNextTransUnit etc).  I do
of course see the advantages of the "One format to rule them all", but
even within GNU/Linux we
have .desktop, .po, .glade, .jpg, .svg, .png, .resx (through mono) - all
formats designed to perform a specific purpose (sometimes legal,
sometimes technological)

I fear that in treating XLIFF as a silver bullet that consolidates
resource formats that we will ultimately commit it to an untimely
demise. 

I would still love to hear about practical applications and case studies
involving XLIFF. I'm extremely keen to understand from a deployment
perspective how the transformation to XLIFF impacted on quality, speed,
flexibility, cost and dependency issues before and after the effort. 

Oh dear, I do sound terribly cynical don't I? It's not really
intentional!


On Tue, 2005-04-12 at 15:14 +0200, Josep Condal wrote:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xliff-tools/attachments/20050412/b00f7dfc/attachment.pgp