XLIFF 2.x… the translator’s panacea?

In the last year or so many articles have been written about XLIFF 2.0 explaining what’s so great about it, so I’m not going to write another one of those.  I’m in awe of the knowledge and effort the technical standard committees display in delivering the comprehensive documentation they do, working hard to deliver a solution to meet the needs of as many groups as possible.  The very existence of a standard however does not mean it’s the panacea for every problem it may be loosely related to.  It’s against this background I was prompted to write about this topic after reading this article questionning whether some companies were preventing translators from improving their lives.  The article makes a number of claims which I think might be a little misguided in my opinion… in fact this is what it says:

XLIFF 2.0 is a “new” bilingual format for translation that attempts to do a handful important things for translators.

  • Improve the standard so that different translation tools makers, like SDL, don’t “need” to create their own proprietary versions that are not compatible with other tools
  • Creating true interoperability among tools, so translators can work in the tool of their choice, and end-customers can have flexibility about who they work with too
  • Allow businesses to embed more information in the files, like TM matches glossaries, or annotations, further enhancing interoperability

I say “new” because XLIFF 2.0 has been around for years now. Unfortunately, adoption of the XLIFF 2.0 standard has been slow, due to tools makers and other players deciding that interoperability is not in their interest. It’s one of those things where commerce gets in the way of sanity.

Continue reading “XLIFF 2.x… the translator’s panacea?”

Good bugs… bad bugs!

01What the heck is a good bug? I don’t know if there is an official definition for this so I’m going to invent one.

An unintended positive side effect as a result of computer software not working as intended.

I reckon this is a fairly regular occurrence and I have definitely seen it before.  So for example, in an earlier version of Studio you could do a search and replace in the source and actually change the source content.  This was before “Edit source” was made available… sadly it was fixed pretty quickly and you can no longer do this unless you use the SDLXLIFF Toolkit or work in the SDLXLIFF directly with a text editor.  In the gaming world it happens all the time, possibly the most famous being the original Space Invaders game where the levels got faster and faster as you killed more aliens.  This was apparently not by design but it was the result of the processor speed being limited, so as you killed the aliens the number of graphics reduced and the rendering got faster and faster… now all games behave this way!  Another interesting example in the Linux/Unix world is using a dot at the start of a filename to hide it from view.  This was apparently a bug that was so useful it was never “fixed”.

Continue reading “Good bugs… bad bugs!”