Internationalization: Implementing the XLIFF Standard Jon Allen, Producer instructional media + magic, inc. JA-SIG Summer Conference 2003 June 10, 2003 Westminster, Colorado

uPortal & JA-SIG 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

uPortal & JA-SIG 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

uPortal & JA-SIG 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.

uPortal & JA-SIG 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

uPortal & JA-SIG 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

uPortal & JA-SIG 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

uPortal & JA-SIG Currently involved with XLIFF Alchemy Software Bowne Global Solutions GlobalSight HP Lotus/IBM Lionbridge LRC Moravia IT Novell Oracle Microsoft RWS Group SAP SDL International Sun Microsystems Tektronix

uPortal & JA-SIG XLIFF - overview Contains the localisible content Bi-lingual format Meta data Workflow, Management information Support material TMs, Alternate translation

uPortal & JA-SIG XLIFF elements - overview –

uPortal & JA-SIG XLIFF element – alt-trans Alternate translation – French translation available to French Canadian translators Used to aid workflow Previous translations Rejected translations

XLIFF and the uPortal Framework

uPortal & JA-SIG 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

uPortal & JA-SIG Language Gathering

uPortal & JA-SIG Example XLIFF

uPortal & JA-SIG Technical Approach (part 1) Channel author writes XSL With namespace xmlns:upl=" sig.org/uPortal/internationalization/"> And trans unit markings elements for Cdata for attributes XSL is the skeleton file Channel author is the authority on what elements of the markup should be translated.

uPortal & JA-SIG Example

uPortal & JA-SIG Technical Approach (part 2) XSL skeleton becomes the input file to an XLIFF generation transformation. Three templates Root template creates the XIFF Header template creates the CData source and target blocks upl: attributes template creates attribute source and target blocks

uPortal & JA-SIG Example

uPortal & JA-SIG 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

uPortal & JA-SIG 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

uPortal & JA-SIG Example

uPortal & JA-SIG Example Localized to Japanese

uPortal & JA-SIG Why this approach? Run-time translations would be a performance problem Build time translations can be cached

uPortal & JA-SIG XLIFF and Non-XML Files An XLIFF application by Peter Kharchenko

uPortal & JA-SIG Opportunities? Translation channel Translation memories at a central location Other Opportunities?

XLIFF for Instruction and Research The XLIFF Viewer channel

uPortal & JA-SIG XLIFF Viewer Channel (1) English Only German Only

uPortal & JA-SIG XLIFF Viewer Channel (2) Both Languages Side-by-Side