E.g., 03/31/2020
E.g., 03/31/2020

Who Doesn’t Like Standards?

Earlier today we hosted a webinar on GALA’s standards efforts. For obvious reasons, there are a lot of questions about what we intend to do in this area at GALA. One of the questions that came up but which we did not really get to address in the webinar was who, exactly, it is that opposes standards. Such questions are often loaded with an obvious expected answer, but the answer isn’t actually as obvious as may be intended.

In subsequent discussion on LinkedIn, Bill Sullivan (IBM) addressed this issue, and I think his comments (http://linkd.in/eDjdRS) hit the nail on the head: nobody opposes “standards” per se, but very often they oppose specific standards if they get in the way of a particular business purpose. We’ve actually seen this problem in practical terms with tools that use TMX or other standards as a way to import data into the tool, but that export TMX that is hardly usable: in other words TMX is seen as a one-way street rather than a vehicle for interchange because getting data in serves an obvious business purpose for the developer, but getting it out does not.

More recently I’ve become aware of multiple initiatives and individuals that claim to support openness in standards but which define that openness by excluding various vendors or parties. While I suppose some may fear that those parties will dominate the discussion, excluding them is hardly a way to build goodwill or true interoperability. You cannot expect companies to support something in which they have no stake and which may well have been created as a club with which to beat them.

So, in response to the question “Who doesn’t like standards?” the answer could be almost anyone. At the same time, even if we all really “♥ standards,” there are a lot of reasons they can fail. Bill outlines many of them in the post I linked to (and I encourage you to read it), but there are also others, such as:

  1. Standards may try to do everything/too much. Take a simple problem and hand it to a committee that expands the scope and pretty soon you end up with a standard that is neither fish nor fowl. It’s classic feature creep. Or perhaps it’s “jack of all trades, master of none.” When you have competing interests, the consensus-building approach of standards bodies makes it natural to try to appease them all, but the result may be standards that are so loose and rich in features that the original purpose gets lost. Take XLIFF, for example. I would argue that it is the best thought-out localization standard we have (and I mean that as a real compliment to the XLIFF community), yet an examination of feature support shows that no tools implement all of its features and that some have scarcely any overlap with others. I know that some users actually have XLIFF ↔ XLIFF filters (seriously). What does it mean to use a standard if you have to convert between versions? So one of the tasks we need to consider is how to make standards into standards that work. (Lest anyone think I’m sniping at XLIFF, the same could be said of TMX as well, and its scope is even more limited so that result is even less acceptable!)
  2. Technical standards are yet another format. Unless everyone uses a standard format, it may be just another format you have to support. Many translators, in particular, are skeptical of standard formats because they still have to support all the non-standard formats and deal with them as well. We have to show the particular value of using a standard versus business as usual, and this task can be difficult since standards have to be both flexible enough to accommodate real-world issues and firm enough to actually work. It’s an inherent tension, and if you get the results wrong, people won’t use standards. Unless standards solve problems, they are just an added burden.
  3. Standards are often theoretical, not practical. This issue is another way of stating what Bill called the “Superabundance of Genius” and is hardly limited to localization. The people who create standards are the ones who care passionately about the issues. Because they care, they want to get things right (rather than get things done). To use the old saying, we shouldn’t let the perfect become the enemy of the good. Having a theoretically perfect standard that is too complex results in something nobody will use.
  4. Sometimes you can’t square the circle. This is the thorniest problem of all. Suppose Tool A requires W, X, and Y to do its job and Tool B requires W, X, and Z to do the same job. In other words, they have a fundamentally different approach to the same task. As a result, Tool A can’t produce Z (or use Y) and Tool B can’t produce Y (or use Z). So how do you interchange between them? No standard will be able to resolve that difference. We’ve actually run into that issue in localization with standards like TMX and these issues can create real problems. I don’t know how to solve this problem.

There are other reasons why efforts may fail. Some of the problems are more serious than others. But what we do need is a concerted (and funded effort) to address these issues and the one Bill raises. Such an effort cannot be (only) grass-roots, although it must have real support and commitment from the community.

I often find myself in the odd position of being the supporter of standards who has to play devil’s advocate against them in order to clear up what I see as misconceptions, but I believe if we don’t understand the issues that create problems for us we cannot overcome them. The GALA plan we are working on is being designed to overcome these problems and the ones Bill described as much as possible.