[xliff-tools] XLIFF usage

[Asgeir Frimannsson]

Hi,

On Tue, 12 Apr 2005 22:35, Stephen Holmes wrote:
> On Tue, 2005-04-12 at 21:11 +1000, Asgeir Frimannsson wrote:
> > 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!

XLIFF might be a more complex *file format*, but translators should never see 
the XML (if they do, we localisation engineers have failed somewhere), so 
XLIFF is never more complicated than the Localisation Tool in use. 

Hence, with PO and present PO editors we have these common problems:
 - No workflow support. In larger projects like the Fedora Project, it would 
be beneficial to have a 'translation' phase, a 'review' phase etc.. PO does 
not have support for this in the file format, other than the simple 'fuzzy' 
flag
 - Very limited context information.
 - No abstraction of inline tags and codes. This is a big dis-advantage for 
formats like XML Docbook, which are presently converted to PO for 
localisation because of good PO tool support.
 - No support for sub-segmentation. (This will be implemented in the XLIFF 
specification over the coming few months)

By using a standard file format in the localisation process, we also give 
translators choice; They are not locked in to using a PO editor, but can use 
any editor that supports XLIFF. 

> > 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 agree, what we want is process simplification - And XLIFF can deliver on 
that in an open source environment. Say in a large project like Gnome or KDE, 
with 100s of active developers: When a developer introduces a new file format 
in his application that needs localisation, all he needs to do is make sure 
it is extracted to XLIFF in the build system. The localisation process does 
not stop because the localisation tool now have to implement support for a 
new file format in the localisation tool, ...and everyone is happy. That's 
exactly what happens today in Gnome and KDE, but using PO and not XLIFF as a 
common file format.

> 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.

With modern tools solutions, I guess you're referring to Trados or other 
commercial alternatives? Those tools are not valid options for open source 
localisation, as they cost $$, and many companies advocating open source are 
committed  to only using open source tools in the localisation process. - And 
we can't expect our community contributors to pay money for their 
localisation tools.

But I do however see your point, there are two main approaches to dealing with 
file formats in the localisation process:
1) Convert to a common localisation format (like we do presently with PO, and 
we're trying to implement for XLIFF)
2) Have localisation tools that can handle a multitude of file formats 
internally.

Option 2 has the advantage that the localisation tool can fully take advantage 
of the native file format (e.g. by having visual editors for file-types like 
MS powerpoint). Option 1 makes it easier to write more generic Localisation 
tools, and tools that are forwards-compatible with future file formats (as 
these would be converted to XLIFF). If Trados was free and open source, then 
yeah, we would probably go with option 2, but hey, until someone creates such 
a tool, I see XLIFF as the best solution. 

cheers,
asgeir