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

[David Fraser]

Bruno Haible wrote:

>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 agree, this is a good summary of the current state of affairs...

>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.
>  
>
As an aside, have you ever used poedit?
There may be an interim step where a translation editor that handles 
xliff PO-based files but doesn't handle all the other elements yet (or 
handles them in an un-userfriendly way) is produced more quickly

David