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

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

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

Localization Platform RecommendationsIn the first part of the series, I tried to convince you that there were more compelling reasons to not build a tailored localization platform than there were to do so. But what if you have carefully analyzed your situation and concluded that, if you were to build your own platform, it would bring improvements that — taken across the volume of your localization work — would outweigh the cost of building and supporting it? Congratulations, now you should start worrying about how to build your own platform!

If you are in a situation where a localization platform really needs to be developed, I have three recommendations for you on how to do this, because, sooner or later, there will come a time when your new platform is deployed into a live environment and, invariably, your project managers, developers, testers, engineers, LSPs, and translators are going to tell you — hopefully in much more polite terms — that “your platform sucks.”

This outcome is perhaps inevitable. Nevertheless, there is a lot that can be done during the planning and development of your platform that will influence how many real and serious reasons there would be for people to feel that way — and how much of that will only be a manifestation of people’s reluctance to adopt something new, something that will prove itself much better than what was used in the past.

1. Decide on guiding principles

Your platform will impact the work of many people in multiple teams inside and outside of your organization — people with different roles, goals, perspectives, and responsibilities as well as different requirements and expectations of the system. Somebody might say, “A very good system will take care of the needs of everyone involved.” But the reality is that these needs are not always compatible.

When you realize that the assumption “a good platform will fix everything” is incorrect, it becomes clear there will be some tough decisions ahead, and this in turn means that the first thing you should establish is a clear guiding principle. Your project will be more likely to succeed if the design philosophy and related decisions are made consciously and consistently with defined guiding principles, than if they were made ad hoc.

2. Assign responsibility

Next, you should decide who will be responsible for the design and building of the platform. Because there are important decisions and trade-offs involved, it is not simply a matter of identifying an in-house or outsourced development team that should go about building it.

As a translator, I could immediately tell whether a particular localization tool was designed and developed by someone who was downstream (close to the translation tasks) or upstream (concerned with engineering and builds). The bias of the people responsible for the development was clearly visible in what they built. When it comes to the responsibility for developing your platform, the who will end up shaping the what and the how.

3. Involve localization service providers early on

It then makes sense to involve all of those who will be interacting with your platform so they can provide their inputs. This should be done early — already during the design — and maintained during the development and testing. During the design stage, many localization buyers choose to limit this involvement to their internal teams and to approach the LSPs only once a beta version is ready for testing.

Such an approach limits your chances of creating the best platform possible however, because you are excluding contributions from the key users of your system. You need to be cautious though: Every supplier you use will have their very own special process and workflows that need to be supported by the platform. Given the chance, they will flood you with requirements that will be (once again) irreconcilable. Might it therefore be better to leave the LSPs out of this? Judging by the number of sub-optimal platforms that are missing core functionalities for translators and LSPs, hurting both productivity and quality, I recommend that you find a way to involve your suppliers.

At Localization World in Vancouver, Elise Lee from Microsoft described how they were developing their platform by taking feedback from five suppliers. They all said that it was important to support their workflow needs with various steps, statuses, ownership, et cetera. Elise said, “We pared the feedback down to a common base that had real impact on quality, time, and cost.” In other words, Microsoft was able to take feedback from five LSPs because it stayed clear on what its guiding principles were.

Defining the guiding principles and involving your LSPs early on is important for another reason too: Some of the features of your platform will be so ingrained in its inner workings that should you later change your mind, it might be very difficult to make adjustments to them. You and everyone else would be stuck then with a platform that “sucks.”

I hope the above ideas are helpful. Hopefully, when you roll out your new platform, everyone will be on board with what to expect and that subsequent feature requests will be relatively easy to implement. If you have good or scary stories around this, feel free to share them with us!

There is one ultimate trick that bypasses many of these thorny questions, makes your job easier, and results in happy and effective buyer-supplier dynamic. We’ll talk about it in the third part. Spoiler alert: APIs.