[xliff-tools] Comments about XLIFF and the Mapping Guide

[Bruno Haible]

Hi,

Before all technical comments, a few thoughts about the XLIFF format,
tools and open source.

Let me present myself: I'm maintaining GNU gettext, and am nowadays
responsible for the PO and GNU MO file definitions.

The XLIFF format, with all its specific elements, is obviously meant
for professional translators and for workflows inside companies.
The PO format, on the other hand, was designed for a simple workflow
consisting of developer and translator only. (This is most visible from
the simple "fuzzy" flag.) This is entirely sufficient for 95% of the
open-source projects.

XLIFF open-source support appears desirable to me because
  1) For the 5% biggest projects, such as OpenOffice, GNOME etc.
     some specific wishes (e.g. more complicated workflows, or
     disambiguation of GUI messages by context) are not taken into
     account by the PO files and tools.
  2) For companies that produce open-source products, XLIFF support
     is part of the credibility.

So a seamless integration of the XLIFF world with the PO world is desirable.

About the XLIFF tools, in particular editors for translators: The PO file
editors are simple and easy to use because the format is simple. The
acceptance of XLIFF based tools in the open-source world will depend on
their ease of use (because in the open-source world there are few professional
translators who would buy and use a non-ergonomic tool). In particular, this
means that such editors must have a customizable GUI: Given the wealth of
elements and attributes available in the XLIFF schema, a GUI can always
only display a small fraction of the elements. A GUI that, say, spends
50% of the screen estate on the <skl> skeleton, the <group> structure, the
<context context-type="record-title"> elements, the <trans-unit>'s resnames
and <bin-unit>s, will be unusable for editing PO files, because these elements
never occur in XLIFF files converted from PO files. For Java Resources,
on the other hand, the <trans-unit>'s renames display is mandatory.

I don't expect XLIFF based open-source translation editors in the next 3
years: It took ca. 2 years until KBabel was built, which is so far the only
good open-source translation editor. (gtranslator 0.43 doesn't even support
plural forms, and Emacs PO mode is just not my taste.) An editor which not
only has to accomodate a hundred of different elements and attributes, but
also a configurable GUI around it, is not going to be seen in the open-source
world soon.

Nevertheless, I believe the PO - XLIFF converters are essential.

OK, now some comments on specific topics of the Mapping Guide.

Bruno