How (Not) to Build a Localization Platform (Part 3)
Share
Click here to close
Click here to close
Subscribe here

How (Not) to Build a Localization Platform (Part 3)

How (Not) to Build a Localization Platform (Part 3)

Localization Platform API

Before diving into the final part of the series on How (Not) to Build a Localization Platform, let us take a quick look at the key points of the previous articles and pay a tribute to the newly Oscar-decorated films as we do so:

In the first part, my goal was to paint a sufficiently painful image of what it takes to create “Yet Another Localization Platform” to convince you to stick with open, interoperable standards and to adapt available and suitable modern TMS and CMS systems. If you have an unequivocal cost-benefit analysis proving a fully customized system is required, and you have the resources to build one, you should still consider the question Michael Keaton’s character was asked in Birdman — “Do you really think you’ll be ready for opening tomorrow?” — and his answer.

In the second part, we discussed how building a platform differs from cracking Enigma: Don’t work on it in secret, avoid trial and error, establish clear priorities, and get a buy-in from everyone on both the advantages and disadvantages of your design. Benedict Cumberbatch has a delightful line in The Imitation Game when he dismisses two members of the team: “You’re both fired … You’re mediocre linguists and positively poor code breakers.” Yes, your poor mediocre linguists on the supplier side are not well equipped to handle software development but, since your end users are not MI6 agents but translators, involving them early in the design process and throughout development will be invaluable.

Provide a Public API. Always

There really only is just one message in this article: provide a public API to your platform. But the importance of providing an application programming interface to your tools and platform is so critical that I want to spend time to back it up by my personal experience, logical arguments, and opinions of other people in the industry.

When I started in localization in 1999, Trados Translator’s Workbench was the de facto standard translation memory tool. If there were Academy Awards in localization, it would have been nominated in all categories and swept up the golden statues in most of them.

Does it mean that Trados was perfect? Definitely not. It was missing small things that could boost productivity, such as the ability to return to the previous segment to make a correction. It did not have more powerful features that directly improve quality, such as propagating changes in identical units within one file, let alone across multiple files in a project. It did not allow you to enforce terminology lists. But it was possible to make it almost perfect.

Unlock the Full Potential

Because Trados had a publicly accessible API, I could program and distribute modifications that enabled all the functionality listed above. But there is even more power in an API than that. By opening your API, you give people the key to unlock complete paradigm shifts that are limited only by their imagination and willingness to harness your features in new ways.

In my experience with Trados, it was possible to use the API to enable single-user editions of Trados to exchange and update all newly translated segments across a team of translators in real time. I doubt this was an intended use of the freelance edition by the manufacturer, but the point of this story is exactly that: You will not be able to anticipate all the things other people will be able to do with your tool and, in our context, that is a very good thing.

This brings me to the logical arguments for including an API. People will wish that your tool had features it does not have, that it did things it cannot do, and that it integrated into their own tools and systems. As I illustrated, it is the API that makes the extensibility by other people possible.

Don’t Go It Alone

The only alternative is that you, as the tool developer, code all the requested features yourself. But you will not have the time and budget to do all that so you will have to say “no” to most of the requests because you will need your development time to fix bugs and to implement critical issues in your core product and not to serve would-be-nice features. By publishing your API, you are effectively crowdsourcing that development.

Some goals, such as integrating your platform with tools on your suppliers’ side, could not be achieved without a documented and open interface at all. In the previous article, I mentioned the challenge during the design phase of where to draw the line between upstream and downstream. What steps of the process happen in your platform, and what steps happen outside of it? Do you provide an editor? Validators? Terminology? Recycling? Machine translation? Workflow management and assignments? These are tough decisions.

By including an API, you allow your supplier to draw the line where it is the most efficient for them, which is in turn where it brings the most efficiencies, quality boosts, and turn-around time reductions for you.

With a modular design, you will even be able to mix and match the best pieces. Maybe your supplier has a better machine translation engine. Maybe you have a superior translation editor but they have better validators for grammar and stylistic rules. Maybe they are good at fine-tuning your MT engine or other things you do not want to be doing in house. By having your system built in components based on interoperable standards, you will be able to maximize these benefits.

The Beginning of a Beautiful Friendship

Speaking about the value and evolution of localization platforms, at LocWorld Vancouver 2014, Sergio Pelino shared the experience Google had while evolving their own platform. “Every one of your suppliers is going to want to do something different,” he said. “For us, the solution was to create APIs and give our suppliers the freedom to build whatever they need.” As a result, the whole is greater than the sum of its parts.

Klemens Waldhör and Achim Ruopp (TAUS) contrasted the simplicity of the API of popular web service Twitter with the powerful implementations that result from its fairly minimal set of instructions. “Web APIs offer the ability to simplify the process of interacting with translation resources and services,” they write in the TAUS Translation API User Guide, “while also allowing complex tasks to be broken down into several small and simple requests.”

So please, whatever you do, don’t forget to provide APIs and invite your suppliers to help. They will be happy that you did, and they might even seem to have all the answers on how (not) to build your own platform. Which brings me to the closing quote from the Oscar films: “I miss being sure of things. There’s no peace in being unsure of everything all the time.”

 

Comments