[xliff-tools] XLIFF usage

[Stephen Holmes]

On Tue, 2005-04-12 at 21:11 +1000, Asgeir Frimannsson wrote:
> Hi Steve,
> 
> I'm not sure if you're referring to the fd.org XLIFF Tools project or XLIFF in 
> general, but I'll assume the first. If however, you're referring to XLIFF in 
> general, have a look at the XLIFF 1.1 Whitepaper for a good overview of 
> XLIFF: 
> http://www.oasis-open.org/committees/download.php/3110/XLIFF-core-whitepaper_1.1-cs.pdf

I'm familiar with the spec - but it's academic at this stage.  My intent
is to explore the practical implementations of XLIFF in a real world
development and localisation environments.

>  
> On Tue, 12 Apr 2005 19:01, Stephen Holmes wrote:
> > I've read the announcement of the XLIFF Tools Project
> > (http://mail.gnome.org/archives/gtranslator-list/2005-January/msg00001.html
> >) but I must admit to being confused about the ultimate intent of the the
> > XLIFF effort.  Is it the intent of this working group to ultimately replace
> > the various *nix file formats with XLIFF as a native resource file format
> > or is it simply intended to be a round-trip container for use during the
> > translation process. 
> 
> The overall goal of the XLIFF Tools project is to replace file format X in the 
> *Localisation Process* in favour of XLIFF, enabling translators to work 
> directly with XLIFF in XLIFF based localisation tools, and not by using 
> PO-based editors as in present open source localisation practices. 
> 

Why would a translator opt to use XLIFF (a complicated format when fully
exploited) in favour of a simpler format such as PO (which admittedly
simplistic in terms of meta-data to convey context).  What are the real
benefits to the translator?  Surely we'd just be replacing a PO editor
with an XLIFF editor?  

I know I must be missing something here!

> The 'XLIFF PO Tools' sub-project is in a process of change at the moment, and 
> will probably be re-named to xliffize - providing similar functionality to 
> intltool. In other words: xliffize aims to integrate XLIFF in GNU Autotools 
> based projects, using XLIFF as the native resource format in favour of PO. 
> Check out  http://xliff-tools.freedesktop.org/wiki/Projects/XliffPoTools for 
> a diagram of the proposed workflow. Translators will then be able to retrive 
> XLIFF files for translation from the repository. Once we've got the Gettext 
> resources covered, we can go on implementing support for other file formats 
> within this framework. Integrating XLIFF in the build system means that 
> developers can use any technology and file formats in their projects, as long 
> as they can extract the resources to XLIFF - without affecting the 
> localisation process [keeping translators happy]. This is basically the same 
> concept as intltool, but they use PO as the native format.
> 
Understood.  I'm in the localisation business (with Novell) and workflow
is important to us but so is process simplification.  The localisation
process is more than just translation and in particular with software,
it's critical to move efficiently from source to target file in the
localisation supply chain.  It seems to me that by adding additional
touchpoints to the process that one loses this simplification.  Now this
impression is within a software domain.  When I think of continuous flow
content such as Web or news-byte content then absolutely XLIFF is
crystal clear because of it's ability to handle content state.

I certainly don't need to sound negative about XLIFF (in the software
localisation process), I'm an advocate, but I do believe in relevant
standards that enhance a process not encumber it.

Currently, modern tools solution a pretty good job of abstracting
localisation content from its functional parent content and I would see
this as the best way of improving the translators lot.

> There is also the 'XLIFF Tools Java' sub-project which is a set of round-trip 
> filters. 
> 
> > Is it also being considered as a translation memory 
> > repository for use in the localisation process?
> >
> > Seriously, how are you folks using it?
> 
> I'm not aware of any open source projects (based on Gettext) using XLIFF in 
> the localisation process yet. - Much because we don't have any good open 
> source XLIFF editors yet.
> 
> > I know this may seem to be a naive question, but you'd be amazed at the
> > different implementation approaches, opinions,  and thoughts that exist
> > out there.
> 
> I am amazed :) 
> 
> > Looking forward to hearing from you.
> >
> > Regards
> > Steve.
> 
> cheers,
> asgeir
-------------- 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/1ecba894/attachment-0001.pgp