As a Localization Engineer, Ben Miller’s job is to ensure the translation process runs smoothly – so the technology nerd is the go-to person at MEINRAD when interfaces need to be programmed. Ben discusses the requirements, the process and the challenges involved in developing interfaces for translation projects.
In 2020 you spent a lot of time working on interfaces. What exactly did you do?
In my role as a Localization Engineer, I’ve focused on all the technical issues involved in the translation process for a number of years. My aim is to create and optimize a translation process for our clients that works as smoothly and efficiently as possible. Automatic connectivity between interfaces already has a big role to play, and it’s only going to become more and more important. There’s huge potential when it comes to interfaces in the translation process – automation can save time and money and minimize errors like those caused by copying and pasting. I want to support our clients as effectively as possible, so in 2020 I focused on the issue of interfaces and improved my programming skills. The thing is, there isn’t a course called “Creating interfaces for translation management”, so you have to think outside the box a little bit and develop your skills more generally. Ultimately, the best way to learn is on the job, as each interface is unique and has different challenges.
What challenges do you mean?
There are lots of different source systems. Some of them were developed with localization technology in mind – that is, they were designed to be multilingual and facilitate the translation process. Programming interfaces for these systems is a lot easier than it is for other systems where the developers didn’t consider the multilingual aspect and more of the infrastructure needs to be put in place. But that doesn’t mean there’s nothing you can do: there’s just more work for both sides.
Who do you mean by “both sides”?
I don’t create these interfaces on my own. Clients know their own systems inside out, and as a translation agency we know ours inside out too. There are some things they have to implement themselves, and some things we have to implement ourselves – but it doesn’t have to be one of the in-house team. External specialists, such as advertising agencies, are often tasked with maintaining websites that need to be translated.
What do you need in order to create an interface?
You need two systems: the client’s source system, and the translation agency’s translation system. The source system can be an authoring system, a tool like MadCap Flare, a data management or version control system – in short, any system used to produce and manage text that needs to be translated. Basically, the two systems need to talk to each other so that data can be sent from one to the other, and to do that you need interfaces that bridge the gap. So first of all the two systems have to enable that, for example through functionality that allows basic file export and import.
This isn’t always easy, so both clients and translation agencies need people in their team with specialist expertise.
What are the individual steps involved in implementing an interface?
The first step is to discuss what everyone wants, requires and expects from the interface, which includes agreeing time frames and who’s responsible for what. So you have to be crystal clear about what the interface needs to do and how translations should be processed. It’s easier if each translation project is the same – e.g. if it’s always Word files that need to be translated and reviewed in the same five languages – than if there are different file formats in different languages, if reviews are sometimes required and sometimes aren’t, or if the client wants to do an in-country review, as can happen.
Once the service design level has been clarified, both the client’s specialist and I can get down to brass tacks. The next step is thoroughly testing the programs to be used. It’s much better to do this in a test environment, rather than in the live software environment, because that way the bugs, whether serious or minor, can be ironed out as part of the programming process. And once you’ve done that, you should be good to go.
Is programming the same for all interfaces?
The fundamentals don’t change, of course, especially if you’re working with the same systems. But each interface is unique, and specific solutions need to be programmed depending on what you’re trying to do. Ultimately, no two systems will talk to each other in the same way.
How long does it take to implement an interface?
There’s no straightforward answer to that, and you have to distinguish between actual working time and total implementation time. It’s not just me working on the interface – the specialist at the client is too, and neither of us will be able to spend a full eight hours a day on it. An interface can take anything from a few weeks to several months to implement, so you should always discuss the time frame with the client in advance.
Broadly speaking, the amount of work involved depends on the source system used and the client’s requirements. With off-the-shelf systems like WordPress, a lot of the work has already been done by the software developers, so it’s quicker to implement the interface. But if you’re working with systems you’ve developed yourself, or systems heavily adapted to meet the needs of a specific business, it’ll take a lot longer, simply because you have to program a lot more yourself.
Are these kinds of interfaces crucial for business that need translations?
Not necessarily. You should think carefully before implementing an interface, because setting it up can involve a lot of hard work and expense depending on the system you’re using. The best case scenario is that the investment pays off very quickly – that is, if you regularly have big translation projects. But there’s not much point having advanced interfaces like these if your translation requirements go no further than one simple file every few weeks.
Who benefits from these interfaces, and what do they have to offer?
As I say, advanced interfaces are only worthwhile if you have enough translation projects to justify the effort and expense. The main benefit of interfaces is that they save you time (through more efficient translation management and faster turnaround times), and therefore money: the translation agency can often give you bulk discounts because they can handle bigger projects in less time.
But an expensive “hot interface” isn’t the only option. For instance, you can set up monitored folders which both the client’s system and the translation agency’s system can access to enable automated file transfer. Even this, one of the simplest forms of automation, makes file management much easier and more efficient. Think of it as the Light version of an interface.
How does it make file management easier and more efficient?
It makes handling the translation files simpler. Clients can use the system they’re familiar with – they don’t have to send files by e-mail or log in to a portal and create translation projects there. Instead, they can launch translation projects straight from their own software environment. If in-house automation processes are already in place, monitored folders like these can go a long way.
Main image: © MEINRAD
