This page is used by the XLIFF Technical Committee to gather takeaways from the First XLIFF Symposium. Deadline for submitting takeaways is 15 October 2010.




Takeaway (Please Prefix by your Name)

Plenary Sessions

Reinhard Schäler (Welcome)

Bryan Schnabel (Keynote speaker)

XLIFF's Place in the Community

Asanka Wasala, Dag Schmidtke, Reinhard Schäler

XLIFF and LCX Format: A Comparison

Observations related to XLIFF Implementation Status Quo

1. tool vendors prefer proprietary formats
2. implementation by tool vendors could be improved: more features, more recent version (namely 1.2), more transparency wrt. supported features, higher accuracy wrt. supported features
3. open source community prefers PO format

Ideas/Recommendations related to XLIFF

1. create object model (similar to for example XML DOM; to allow programmatic access that is transparent to the underlying data format)
2. include mechanism to represent or refer to original data (e.g. binary data for accurate, secure representation of User Interfaces)
3. include mechanism to represent or refer to validation rules
4. include mechanism for flexible annotation for human consumption (might be an enhanced "note" element) of any element of attribute of the representation
5. include mechanism for flexible (typed) annotation for machine processing of any element of attribute of the representation
6. create container-based representation format (similar to for example the ODF or OOXML zip formats)
7. simplify and clarify (so that for example there is a canonical representation, not a choice between different representations) 8. include mechanism for flexible annotation of referenced resources


1. remarks on several XLIFF "unique selling propositions" (e.g. generic inline markup, representation of segmented content, multilanguage content, ...)
2. examples for features supported, or not supported by leading tool vendors
3. examples for minimalistic and maximalistic representation of proprietary format in XLIFF
4. examples for two-phase mapping between proprietary format to XLIFF (proprietary -> XLIFF with proprietary extension -> XLIFF)

Asgeir Frimannsson, Christian Lieske

Next Generation XLIFF: Simplify - Clarify - and Extend

Observations related to XLIFF Implementation Status Quo

1. Too few implementations
2. Implementation covers only a subset of XLIFF
3. Implementation handles XLIFF incorrectly
4. Ambiguous and overly broad (Overly complex, bloated; No defined processing expectations)
5. poor interoperability between tools
6. Poor or non-existing open source tool support (Virtaal notable exception)

Ideas/Recommendations related to XLIFF

1. Simplify: Make it dead easy to get started creating or manipulating a minimalistic XLIFF file, Make it dead easy to create tools that annotate or process XLIFF files, Make the standard understandable for your process
2. Clarify: Clear processing requirements, Provenance of data categories and values – Where from and Why?
3. Extend: New requirements, Format specific data and processing, Re-use existing standards
4. Realize that XLIFF does not need cover all dimensions in a certain context: Think of phases/layers/domains.
5. Shy away from reinventing the wheel. Reuse!
6. Acknowledge that new approaches are available for describing resources/providing meta data


1. XLIFF's comprehensiveness/complexity derives from its large scope: XLIFF covers a broad range of dimensions related to the process of localizing/translating content.
2. XLIFF's promises: Common Container, Interoperability, Processing

JoAnn Hackos, Bryan Schnabel, Rodolfo Raya

DITA and XLIFF: A Great Marriage


Moderator: Christian Lieske; Panellists: Asgeir Frimannsson, Christian Lieske, Stefan Pries, Friedel Wolff

Minimal and modular XLIFF

Observations related to XLIFF Implementation Status Quo

1. overly complex, ambiguous and not practical to implement
2. mainly costly tools for experienced users
3. not easy to convert to/combine with Translation Memory, or TermBases

Ideas/Recommendations related to XLIFF

1. approach enhancements or new version by clarifying phases, framework and, data categories
2. Possible phases: Extraction/Filtering, Constraint Setting, Internationalization, Automated Linguistic Processing, Human Translation, Localization, Reviewing, Inclusion of reviewing results, Workflow Events, Tool-specific Events, Technical QA checks, Packaging
3. Possible framework: backwards compatible whereever possibe, open to address new requirements, drawing on new ideas (e.g. use of Resource Description Framework)
4. Possible data categories: Payload, String length constraints (min. or max. length), Resource type (e.g. different User Interface controls – label, button, …; overlap with internationalization), Inlines („ph“, „x“, …), Identifiers (for processing), Names (ie. the identifier used in the native format – key in a Java property file …), Notes (e.g. explanations and other amonitions; overlap with internationalization), Internationalization (e.g. „translate“) , Domain/subject area, Relationships (e.g. between strings belonging to the same User Interface menu), Creation (e.g. generator, and creation date)
5. "Bundle" data categories into modules (allows the definition of "profiles" that implementers could target)
6. Introduce archive format (cf. Open Document Format and other zip-like approaches)

Moderator: David Filip; Panellists: Gábor Ugray, Lorcan Ryan, Heiko Rölke, Dag Schmidtke, David Filip

XLIFF metadata throughout workflows

Observations related to XLIFF Implementation Status Quo

1. Different approaches to segmentation are an issue
2. Different approaches to inline markup are an issue
3. Use of extension points to overcome XLIFF shortcomings hinder interoperability

Ideas/Recommendations related to XLIFF

1. introduce powerful annotation mechanism; should cover segment and sub-segment, source and target, flagging as "read-only"


1. Requirements for meta data have evolved; XLIFF does not meet all current requirements (example: inclusion of results from automated linguistic processing like part-of-speech tagging)
2. Approach to standardized visualization (for rendering and resizing of target language objects) would be valueable
3. Different views on right approach (non-cosmetic change vs. backwards compatible change)

Parallel Sessions

Niall Murphy

The route to XLIFF adoption in Oracle


1. XLIFF as enabler for getting acquired companies into standard translation processes
2. XLIFF at Oracle previously mainly used for translation kits
3. XLIFF at Oracle previously not used extensively for resources

Felix Sasaki, Christian Lieske

XLIFF and ITS: A secret marriage


1. Explained the W3C ITS standards, the note "Best Practices for XML Internationalization"
2. Highlighted, that it is important to destinguish between abstract concepts/model (e.g. a data category with semantics "Do not translate") and a specific implementation context (e.g. an attribute "its:translate" in an XML world)
3. Showed that W3C ITS and XLIFF can contribute in different ways to globalization-related processes (“a secret marriage”)
4. Presented ITS2XLIFF tool, see (Web-based; converts to and from XLIFF based on ITS)
5. Revealed vision (e.g. for ITS-aware component running in a browser)

Martin Beuster, Gábor Ugray

XLIFF as a potential TM exchange format?


1. State of TMX support causes loss of leverage, provides little metadata
2. Loss examplified by means of TMX creation with Trados2007 and import of TMX into memoQ
3. Suggestion: Use XLIFF as TM ("alt-trans" can contain memory-like data)
4. Advantage of XLIFF-based memory as opposed to for example TMX-based memory: more (structural) metadata/context; more rigorous process traceability

Steve Dept, Andrea Ferrari, Britta Upsing, Heiko Rölke

Case study: XLIFF in a large-scale international OECD-study

Observations related to XLIFF Implementation Status Quo

1. Tools either costly, or insufficiently tested, or not adapted for a wide audience, or do not make the most of what the standard offers

Ideas/Recommendations related to XLIFF

1. Make it easy to manage change in content (e.g. successive source versions)
2. Make it easy to “track changes”
3. Explain mechanisms to minimize tags
4. Make it easy to handle linguistic variants (e.g. plurals, gender)
5. Make annotation capabilities more powerful
6. Provide modular documentation (customized, role-specific user guides)


1. XLIFF 1.1; Open Language Tool to translate xliff locally and offline
2. process included more than translation (namely additionally adaptation/reconciliation); 60 translators, 30 reconcilers, 30 verifiers
3. More than 30,000 archived XLIFF files, several hundreds of thousands temporary XLIFF files

Short Presentations

Micah Bly

XLIFFs in Theory and in Reality

Observations related to XLIFF Implementation Status Quo

1. Low interoperability (different interpretations, use of extensions even for stanadrd bits)
2. Survey on support of 33 XLIFF elements in 1 tools

Ideas/Recommendations related to XLIFF

1. Specification too broad (impossible to support adequately, definitions not clear, no orthogonality - different mechanisms for the same concept)
2. Specification too narrow (where to store project info, terminology, software context - UI)
3. include mechanism for meta data (e.g. version history) for "note"
4. include mechanism for meta data after acceptance of "alt-trans"
5. include mechanism for project info (id, instructions etc.)
5. include mechanism for declarations (e.g. required in the target files) related to character encoding
6. include mechanism for Quality Management info
7. mention best practice/convention for including TBX (or other term file)
8. include mechanism for link to terms (aside: ITS may have it :-) )


1. Background on XLIFF usage at Medtronic (4 years, streamline QA, substitute translation editor, increased UI localization)
2. Notes on importance of interoperability
3. Lock-in regardless of compliance due to use of extensions for critical information

Shirley Coady

Increasing Quality in the Translation Process through the Integration of XLIFF with Advanced Leveraging Translation Memory and Terminology


1. XLIFF helps with QA, growing or using Translation Memories and terminology-related activities

Friedel Wolff

XLIFF from a volunteer's point of view


1. XLIFF needs to fulfill not only very technical issues but also it has to be able to be adapted and be more down-to-earth for translators. Specially for non skilled translators.
2. There are too many complicated features that the normal translator would not use (e.g status attribute).
3. There is a need for a minimal configuration.

Derek Coffey

GlobalSight as a case study in the deployment and use of XLIFF as an interchange format

Thomas Vackier

The problem of extensibility in XLIFF 1.2

Bryan, Christian

Ideas/Recommendations related to XLIFF:
1. Take a look at all of the extensions that the tool makers have enacted, and use this as a clue for what to put into core for XLIFF 2.0


1. XLIFF's extensibility features as double-edge sword: benefits (flexibility) and risks (alternative approaches to standard methods)
2. Implementers have used extensibility feature to adapt & enhance XLIFF; resulted in abundance of custom XLIFF flavours, often with different namespaces
3. Supporting XLIFF for other implementers thus means that they have to deal with different XLIFF flavours (similar information retrieved from different namespace elements or attributes; otherwise valuable metadata.may not be usable; example: QA Distiller: Uses metadata to filter out or report certain translation units)
4. Example data categories for which implementations differ: match rate (qualifies match of <alt-trans>), state and state-qualifier, <note> element


Jörg Schütz, Alexandra Weissgerber

Localising Business Process Repository Content

Observations related to XLIFF Implementation Status Quo

1. Formalism shortcomings and overall complexity (elaboration needed)
2. Still unresolved relations to language issues (elaboration needed)

Ideas/Recommendations related to XLIFF

1. Approach authoring from a semantic modelling, not from a text writing point-of-view
2. Allow for "concept-based" approach to translation (cf. concept-based terminology; ie. allow "source" to contain a concept identifier)


1. Introduce Content/Knowledge Management ideas into Business Modeling to arrive at a Content Collaboration Platform
2. Concept-based approach - if coupled with appropriate globalization-related metadata - may not need XLIFF and ITS
3. Concept-based approach (knowledge matrix) might also support XLIFF and ITS based workflows within traditional authoring and localization environments, in particular term mining and translingual term consistency
4. Dominance of localization and internationalization stakeholders
5. Too little cross-disciplinary work

Naoto Nishio, Ian O’Keeffe, J.J. Collins

Taxonomy of localisation services with XLIFF


1. Investigating a Localization Service Descriptor (to allow for example accurate selection of Service Provider
2. Service Provider might a human (or Localization Service Provider), or a non-human actor (e.g. a capability exposed as a SOAP-based Web Service)
3. The Localization Service Descriptor may for example provide the information which source format can be processed
4. An XLIFF file could refer to a Localization Service Provider (e.g. to encode processing requirements)

Consolidated Takesaways from First XLIFF Symposium (last edited 2010-12-10 14:32:25 by christian.lieske)