Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | sybil-carter |
View: | 220 times |
Download: | 0 times |
Internationalization:Implementing the XLIFF
StandardJon Allen, Producer
instructional media + magic, inc.
JA-SIG Summer Conference 2003June 10, 2003
Westminster, Colorado
uP
ort
al
& J
A-S
IGThe 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
uP
ort
al
& J
A-S
IGThe 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
uP
ort
al
& J
A-S
IGSome 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.
uP
ort
al
& J
A-S
IGWhat 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
uP
ort
al
& J
A-S
IGWhy 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
uP
ort
al
& J
A-S
IGXLIFF 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
uP
ort
al
& J
A-S
IGCurrently 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
uP
ort
al
& J
A-S
IGXLIFF - overview
• Contains the localisible content • Bi-lingual format• Meta data
• Workflow, Management information
• Support material • TMs, Alternate translation
uP
ort
al
& J
A-S
IGXLIFF elements - overview
• <file>• <header>
• <phase>
• <body>• <trans-unit>
– <source>– <target>
uP
ort
al
& J
A-S
IGXLIFF element – alt-trans
• Alternate translation – French translation available to French Canadian translators
• Used to aid workflow• Previous translations• Rejected translations
uP
ort
al
& J
A-S
IGChannel 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
uP
ort
al
& J
A-S
IGTechnical 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.
uP
ort
al
& J
A-S
IGTechnical 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
uP
ort
al
& J
A-S
IGTechnical Approach (part 3)• After the XLIFF is generated the translations can
begin – either directly with the XML or using one of the localization tools
uP
ort
al
& J
A-S
IGTechnical 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
uP
ort
al
& J
A-S
IGWhy this approach?
• Run-time translations would be a performance problem
• Build time translations can be cached
uP
ort
al
& J
A-S
IGOpportunities?
• Translation channel• Translation memories at a central
location• Other Opportunities?