290 likes | 320 Vues
Learn about XLIFF standard for localization, its benefits, history, and technical implementation for multilingual applications and documents. Explore how XLIFF enhances interoperability and streamlines translation workflows.
E N D
Internationalization:Implementing the XLIFF Standard Jon Allen, Producer instructional media + magic, inc. JA-SIG Summer Conference 2003 June 10, 2003 Westminster, Colorado
The Needs • JA-SIG’s uPortal framework itself • must be available in many user languages • and support language-aware channels by providing user language preferences. • Research and instruction has a number of translated documents with source and target—translated—content. _____________________________ These are two different purposes
The XLIFF standard XML Localization Interchange File Format “The purpose of this format is to store localizable data and carry it from one step of the localization process to the other,while allowing interoperability between tools.” • Source text • Translated text • Information about the translation process and status OASIS Translation Web Services Technical Committee
Some Background • Currently there exist a number of applications and workflows that have been developed to assist linguists to translate projects. • These applications were typically developed to read in the Resource bundles of an application and expose each of the translatable messages. • Some examples of this might be TRADOS to translate Microsoft RC files or KBabel to translate UNIX based PO files. • Some of these translation assistant applications have been made XML aware in their latest versions • Some have built in capability for interoperability with other translation applications using an XML based interchange format called XLIFF.
What is XLIFF • XLIFF is an initiative within OASIS to define the XML Localization Interchange File Format. • The purpose of this format is to • Store localizable data • Carry it through steps of the localization process • Allow interoperability between tools
Why XLIFF was created • Tools for linguists stored translation memories in proprietary formats • Vendor lock-in • Lack of Interoperability • Translations of the translations • XML was a flexible and appealing Markup Language for building an interoperable standard • Tools vendors were concentrating on being able to deal with many formats rather than improving features • Lack of support for standardized localization workflow
XLIFF History • September 2000 group formed to look at the issue of localisation file interchange • Original group included Oracle, Sun, IBM, Novell, Berlitz GlobalNET. Moravia-IT RWS and Alchemy joined soon after. • Agreed spec 1.0 but didn’t publish due to legal issues (Intellectual Prop) • Joined Oasis December 2001 • Working draft 2a, 15 October 2002
Alchemy Software Bowne Global Solutions GlobalSight HP Lotus/IBM Lionbridge LRC Moravia IT Novell Oracle Microsoft RWS Group SAP SDL International Sun Microsystems Tektronix Currently involved with XLIFF
XLIFF - overview • Contains the localisible content • Bi-lingual format • Meta data • Workflow, Management information • Support material • TMs, Alternate translation
XLIFF elements - overview • <file> • <header> • <phase> • <body> • <trans-unit> • <source> • <target>
XLIFF element – alt-trans • Alternate translation – French translation available to French Canadian translators • Used to aid workflow • Previous translations • Rejected translations
Channel Developer Process • Build XSLT (Skeleton) • Identify Translatable Units • Run ANT Target to generate XLIFF libraries • Translate XLIFF libraries (change flag from in process to complete) • Run ANT Target to generate Localized XSLT by combining "Skeleton" XSLT and "complete" XLIFF • Framework chooses appropriate Localized XSLT according to user and portal settings
Technical Approach (part 1) • Channel author writes XSL • With namespace • xmlns:upl="http://www.ja-sig.org/uPortal/internationalization/"> • And trans unit markings • <upl:tu> elements for Cdata • <meta name="test1" content="test2" upl:content="content" /> for attributes • XSL is the skeleton file • Channel author is the authority on what elements of the markup should be translated.
Technical Approach (part 2) • XSL skeleton becomes the input file to an XLIFF generation transformation. • Three templates • Root template creates the XIFF Header • <upl:tu> template creates the CData source and target blocks • upl: attributes template creates attribute source and target blocks
Technical Approach (part 3) • After the XLIFF is generated the translations can begin – either directly with the XML or using one of the localization tools
Technical Approach (part 4) • After the translations are complete another transformation has been written to create localized versions of the original XSL skeleton. • A locale parameter is passed to the transformation • The transformation uses the document function to import the XLIFF files and replace the appropriate phrases
Why this approach? • Run-time translations would be a performance problem • Build time translations can be cached
XLIFF and Non-XML Files An XLIFF application by Peter Kharchenko
Opportunities? • Translation channel • Translation memories at a central location • Other Opportunities?
XLIFF Viewer Channel (1) EnglishOnly GermanOnly
XLIFF Viewer Channel (2) Both Languages Side-by-Side