Is XLIFF 2.0 A Successful Evolution? Chase Tingley Spartan Software, Inc
My Life Exaggerated for effect. But only a little bit.
I have a complicated relationship with XLIFF.
Section 4.7.2.3.1 XLIFF Version 2.0 Candidate OASIS Standard 01
Pretty Ugly https://www.flickr.com/photos/nationalzoo/6257372409
The Naked Mole Rat ● Pretty ugly ● Unusual adaptations to their environment ○ Eusocial ○ Thermoconformat ○ Impervious to some types of pain ○ Enormous jaw muscles Citation
XLIFF 1.2 → XLIFF 2.0 ● What was learned from XLIFF 1.2? ● What has changed in XLIFF 2.0 that makes it better adapted for the l10n ecosystem?
Supply Chain Complexity https://www.flickr.com/photos/paulmccoubrie/6792412657
The Localization Ecosystem Vendor Customer
The Localization Ecosystem Vendor Vendor Customer Vendor
The Localization Ecosystem Vendor Vendor Customer Vendor Vendor Vendor
The Localization Ecosystem Vendor Vendor Customer Vendor Vendor Vendor
But XLIFF isn’t just an interconnect. It’s also trying to move higher-level process data from one end of the chain to the other.
Competing Design Objectives https://www.flickr.com/photos/boston_public_library/8291454054
Design Tension in XLIFF ● Simple vs Complex ● Rigid vs Flexible ● Commercial vs Academic ● Descriptive vs Prescriptive
Simple vs Complex ● A “simple” scenario: “Translate this file” ● But... ○ “Also obey terminology, use my TM, provide revision history” ○ Software strings != HTML != Office != … ■ Different notions of context or preview ■ Different layout constraints How to make simple things easy and hard things possible?
Rigid vs Flexible ● How to provide interoperability guarantees while also allowing for extension mechanisms? ● How to support future innovation while keeping control of the standard?
Commercial vs Academic ● Academic Concerns ○ “How can we leverage XLIFF to introduce the benefits of research in other fields into localization?” ● Commercial Concerns ○ “How am I going to get everything done by Friday?”
Descriptive vs Prescriptive XLIFF is a data interchange format, but that data dictates certain functionality: ● Extractors must convert source content to an implicit data model ● Inline code modification places demands on other tools ● Support for translate annotations may require new workbench functionality
“I find it rather puzzling that this small industry has such difficulties designing robust standards.” - Anon L10n Technologist
Carl Cargill, “Why Standardization Efforts Fail” (2011) Six major categories of standards failure: 1. The standard fails to get started. 2. Lack of consensus / deadlock during standard creation. 3. “Feature creep” causes the standard to miss the market opportunity. 4. Standard is finished and the market ignores it. 5. Standard is finished, implementations are incompatible. 6. The standard is accepted and is used to manage the market. (IP encumberance) http://dx.doi.org/10.3998/3336451.0014.103
Feature Creep http://www.flickr.com/photos/pennstatelive/8490121138/
Feature Creep “The most frequent use of feature creep in a standards committee is by organizations that have an implementation that is very similar to the proposed specification except for “a little bit extra here ….” Do this ten times, and suddenly you have a bloated spec or a spec that just plain can’t work.”
Feature Creep in XLIFF 1.2 ● Redundant concepts ( <x> / <bx> / <ex> vs <ph> / <bpt> / <ept> ) ● Process info with no clear semantics ( state- qualifier, phase) ● Mysterious inclusions ( menu-name, menu- option, coord, csstyle, exstyle... )
XLIFF 1.2 vs 2.0 - Features XLIFF 2.0 streamlines a lot of XLIFF 1.2 cruft, but it also adds a lot of new functionality: ● Preview and External Context ● Size and Length Restrictions ● Terminology
Feature Creep in XLIFF 2.0? XLIFF 2.0: new features, but are they creeping? I say no: ● Generally, the new features fill functionality gaps acknowledged by the market ● They reflect best practices rather than attempts to unify disparate existing implementations ● The module mechanism provides clearer separation in the model
Incompatible Implementations https://www.flickr.com/photos/eurleif/255241547
Incompatible Implementations “ In software standards, there is almost always ambiguity, usually through omission . If an attribute is poorly (or sometimes, not at all) defined in the specification, or if the statement lends itself to ambiguity, there is a possibility that the implementers will choose a different response or implementation than that which was originally intended.
Incompatible Implementations of XLIFF 1.2 ● Lack of consistently implemented feature set ● Feature overloading ( <alt-trans>, <mrk> ) ● Ambiguity (Does match-quality allow decimals?) ● Lack of processing expectations ● Open-ended extension mechanism ● Lack of reference implementation / test suite
One Strange Thing about XLIFF 1.2 "There is high incentive to fracture the standard if it advantages your product set and simultaneously disadvantages competition…. [A] company can establish itself as the de facto implementation of a formal standard and force competitors to play catch up." This has never happened in l10n, despite frequent fracturing of the standard! This indicates that interoperability is so far-fetched an idea among tool vendors, there is active disinterest in achieving it, even through power!
XLIFF 1.2 vs 2.0 - Consistent Implementation XLIFF 2.0 improves on a lot of the problems with 1.2: ● Clearer documentation, including processing instructions ● Overloaded features split apart ● Modularization defines clusters of functionality and creates stronger consistency in the core
More to be done to improve consistency ● Continue to push for reference implementations ● Be wary of module-related fragmentation in the tool space. ● I would like to see the XLIFF TC more actively define the <unit> data model underlying XLIFF. ○ Help non-l10n implementations of XLIFF which have historically had problems
The Market Ignores the Standard https://www.flickr.com/photos/12023825@N04/2898021822
Will the Market Ignore XLIFF 2.0? "If the standard is published after a piece of technology is moving to obsolescence, the market usually ignores the effort ." Is there a chance that XLIFF 2.0 will too late to be widely adopted?
The Worst-Case Scenario ● Size and complexity of specification slows implementations ● Modules are a double-edged sword ○ Easier to prioritize feature development in one tool ○ Harder to consistently utilize features across a tool chain ● Lack of backwards compatibility slows adoption by limiting migration possibilities. ● Lack of education among client-side decision-makers: “Doesn’t this tool already support XLIFF?”
Do industry changes threaten XLIFF 2.0 success? ● Enormous interest in web service APIs with simple, JSON- based data models ○ Not in any way standardized, but simple to implement a narrowly-tailored feature set ● Cloud-based translation platforms reduce the number of integration/data exchange scenarios
Promoting XLIFF 2.0 https://www.flickr.com/photos/brooklyntyger/3261587503
Promoting XLIFF 2.0 ● Make adoption manageable by prioritizing the core ● Push for high-quality open source implementations ○ As standalone, embeddable implementations (Okapi XLIFF Toolkit) ○ In existing tools (OmegaT) ● Education and outreach, focusing on high-impact scenarios and comparative analysis with XLIFF 1.2
Promoting XLIFF 2.0 - TC Activity ● Investigate mechanisms for forward-conversion of XLIFF 1.2 to XLIFF 2.0 to assist in migration ● Work with tool vendors to publish custom modules (if necessary) ● Consider defining fragment formats (XML and JSON) based on the XLIFF 2.0 unit model, to enable XLIFF-consistent data transfer via web services
Who Drives Adoption? http://www.flickr.com/photos/swthomson/3759243339/
Do I have a volunteer? Incentives for tool vendors to support XLIFF are limited ● Standards constrain functionality ● Standards make software components interchangeable ● Standards reduce tool lock-in Incentives for LSPs to promote XLIFF are complicated ● Many LSPs regard any technology they possess as competitive advantage. ● Standards reduce LSP lock-in.
The Strength of Buyers https://www.flickr. com/photos/mugley/8701710046
XLIFF TC Member Companies are a Strength ● Large translation volumes ● Deep technical knowledge ● Respected experts on l10n best practices
Translation buyers are uniquely well-suited to... ● Collaborate on open implementations to support XLIFF 2 and use cases it enables ● Work to promote XLIFF 2.0 through forums like LocWorld ● Work with LSPs and tool vendors to set timelines for supporting XLIFF 2.0
Final Thoughts https://www.flickr.com/photos/nationalzoo/4691121090
Recommend
More recommend
