Type |
Presenter(s) |
Title |
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
Christian:
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
Christian
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
General
Christian:
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
Christian:
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
Christian
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
General
Christian:
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 |
|
Panels |
Moderator: Christian Lieske; Panellists: Asgeir Frimannsson, Christian Lieske, Stefan Pries, Friedel Wolff |
Minimal and modular XLIFF |
Observations related to XLIFF Implementation Status Quo
Christian:
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
Christian
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
Christian:
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
Christian
1. introduce powerful annotation mechanism; should cover segment and sub-segment, source and target, flagging as "read-only"
General
Christian:
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 |
General
Christian
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 |
General
Christian
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 http://fabday.fhpotsdam.de/~sasaki/its/ (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? |
General
Christian:
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
Christian:
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
Christian:
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)
General
Christian:
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
Christian:
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
Christian
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 )
General
Christian:
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 |
General
Christian:
1. XLIFF helps with QA, growing or using Translation Memories and terminology-related activities
|
|
Friedel Wolff |
XLIFF from a volunteer's point of view |
General
Lucía:
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
General
Christian:
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
|
Posters |
Jörg Schütz, Alexandra Weissgerber |
Localising Business Process Repository Content |
Observations related to XLIFF Implementation Status Quo
Christian:
1. Formalism shortcomings and overall complexity (elaboration needed)
2. Still unresolved relations to language issues (elaboration needed)
Ideas/Recommendations related to XLIFF
Christian:
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)
General
Christian:
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 |
General
Christian
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) |