Structured Translation: The Case for XLIFF
Posted on Tue, Nov 10, 2009
Today Jim Compton's thinking about XLIFF and its use in structured translation.
In the early nineties, as CAT (computer-assisted translation) tools started to really take off, so was born the translation pivot file: an intermediary format that bridges translatable material from its native environment into the world of structured translation. The development of the pivot format facilitated the use of practices that we take for granted today, including translation memory, electronic glossaries, rule-based QA, etc.
At that time, the de-facto translation pivot format was RTF - a clever application of the RTF standard that used character styles and hidden text to perform a variety of functions, including segregation of translatable from non-translatable material, and storage of the bilingual content within the file itself.
In 2002, the translation pivot format enjoyed an evolutionary jump with the advent of XLIFF, an XML-based format that performs its entire magic using xml markup - you know, "tags."
If you're not using XLIFF with your own structured translation endeavors, here are a few reasons why you might want to consider doing so:
Solid Character Encoding
XLIFF uses Unicode to define encoding, which is straightforward, unambiguous, and relatively safe from transcoding errors and other forms of encoding corruption.
This may seem like an obvious "must", but the translation pivot format has not always been based on Unicode, and has historically been prone to transcoding and encoding issues that can be expensive and time-consuming to correct.
While the risk of encoding trouble isn't absent with an XLIFF-based translation process, it is certainly greatly minimized when compared to non-Unicode-based alternatives.
Strong, Normalized Metadata Support
The flexible support for standard and custom metadata at various levels (at the file level and at the translation unit level) opens up a world of possibilities for improving the localization process, including, but not limited to:
- Improving TM leveraging through the inclusion of context
- Pairing of content to specific glossaries or reference material
- Including length-limits and other "handling instructions" for translators
- Including information as to the content's state of completion or likely reliability
- etc.
Rules-based Pre-Processing
While technically not inextricably bound, XLIFF is closely affiliated with rules-based pre-processing, mostly because there are very few non-rule-based mechanisms for converting source files into XLIFF files.
The issue here is consistency. Rules-based pre-processing encourages pre-processing consistency, which in turn encourages segmentation consistency, which in turn encourages effective TM leveraging and therefore a lower overall translation costs.
Extensibility
As a type of XML - the format itself is extensible, meaning that it is free to evolve into whatever it needs to become. Today, as OASIS, the organization that developed XLIFF works on version 2.0 of the specification, the format continues to evolve and improve.
Openness and Standardization
That XLIFF is an open standard encourages participation from the world of developers and would-be tool developers, and ensures that their solutions are likely to be interoperable - creating operational freedom and flexibility.
And in fact, CAT tools built around the XLIFF standard continue to get better and better.
At Lionbridge, our own collection of XLIFF-based tools (which I would argue has become one of the best in existence) is helping us to automate more-and-more previously manual activities and to bring the localization process entirely online - moving us further toward the "El Dorado" of Localization 2.0.
Some Online Resources
Have I inspired you to research further? Here are some links that you may find helpful:
Of course, Lionbridge is willing and able to help you to establish an XLIFF-based structured localization process.
As always, your feedback is encouraged and appreciated. Thanks!