This is an expanded version of a short talk I previously gave last fall about why localization standards always fail. This time, I applied some of the same analysis to the problems encountered in the past by XLIFF 1.2, as well as the ways in which the upcoming XLIFF 2.0 standard hopefully addresses them. It also discusses new challenges to adoption and includes gratuitous pictures of mole rats.
This talk was the keynote at FEISGILTT 2014 in Dublin.
6. ● Pretty ugly
● Unusual adaptations to their environment
○ Eusocial
○ Thermoconformat
○ Impervious to some types of pain
○ Enormous jaw muscles
The Naked Mole Rat
Citation
7. ● What was learned from XLIFF 1.2?
● What has changed in XLIFF 2.0 that makes it
better adapted for the l10n ecosystem?
XLIFF 1.2 → XLIFF 2.0
15. ● Simple vs Complex
● Rigid vs Flexible
● Commercial vs Academic
● Descriptive vs Prescriptive
Design Tension in XLIFF
16. ● 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?
Simple vs Complex
17. ● How to provide interoperability guarantees while also
allowing for extension mechanisms?
● How to support future innovation while keeping control of
the standard?
Rigid vs Flexible
18. ● 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?”
Commercial vs Academic
19. 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
Descriptive vs Prescriptive
20. “I find it rather puzzling that this small industry has such
difficulties designing robust standards.” - Anon L10n Technologist
21. 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)
Carl Cargill, “Why Standardization Efforts Fail” (2011)
http://dx.doi.org/10.3998/3336451.0014.103
23. 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.”
24. 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...)
25. 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
XLIFF 1.2 vs 2.0 - Features
26. 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
28. “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
29. 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
30. "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."
One Strange Thing about XLIFF 1.2
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!
31. 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
XLIFF 1.2 vs 2.0 - Consistent Implementation
32. ● 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
More to be done to improve consistency
33. The Market Ignores the Standard
https://www.flickr.com/photos/12023825@N04/2898021822
34. "If the standard is published after a piece of technology is
moving to obsolescence, the market usually ignores the
effort."
Will the Market Ignore XLIFF 2.0?
Is there a chance that XLIFF 2.0 will too late
to be widely adopted?
35. 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?”
36. 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
38. ● 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
39. ● 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
Promoting XLIFF 2.0 - TC Activity
41. 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.
42. The Strength of Buyers
https://www.flickr.
com/photos/mugley/8701710046
43. ● Large translation volumes
● Deep technical knowledge
● Respected experts on l10n best practices
XLIFF TC Member Companies are a Strength
44. ● 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
Translation buyers are uniquely well-suited to...
46. ● XLIFF 2.0 is a clear technical improvement over
XLIFF 1.2
● XLIFF 2.0 contains mechanisms for adapting to
future l10n developments
● XLIFF 2.0 will require a sustained, concerted
effort to achieve the level of adoption it
deserves
Final Thoughts