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

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

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

Tough Decisions AheadAs the title of this series suggests, I have set out to write about the how of building a platform. There is, however, a far more important matter that this direction avoids, a question that should be asked first — one that when answered, paradoxically, might cause most of you to skip reading the rest of the articles. This question will come naturally to many of you localization buyers because it makes pragmatic business sense.

So before you tackle the how of building a platform, ask yourself this: Why should you build your own localization platform or tools?

All Good Reasons

If you are reading this, you have probably already listed out several reasons for why you should build your own localization platform.

  • You believe that a custom solution would best support the needs of your core team.
  • You believe you have a product with unique engineering processes or delivery mechanisms that requires a custom solution.
  • You believe a custom solution will help your company better meet its efficiency, turn-around, and quality goals.

Are these then good reasons for building your own platforms? Probably not.

Why?

You probably also realize that designing, building, and maintaining a bespoke localization platform requires a sizable investment.

You probably know, too, that the brief history of the localization industry has already taught us that such an undertaking often resulted in failure.

A Beautiful Hindrance

Christine Vukusic is the manager for SAP Language Services North America. At a panel called “The Value and Evolution of Localization Platforms” at Localization World Vancouver 2014, Christine shared her insight on SAP’s beautiful and elaborate CMS localization system … and its disadvantages. “Your CMS will inevitably change,” said Christine, “And your beautiful system will become a hindrance.”

In effect, by coding your platform to meet your specific needs, you are tying your hands and preventing future agility. I would argue, further, that even the most successful examples of custom platform development could be matched or even outperformed (in cost-benefit analyses) by third-party solutions that have been adapted to your needs.

Consider this:

  1. Everyone believes that their business processes are completely unique. While I will be the first to assure you that they are, I would also try to help you see that, in principle, globalization and localization requirements are inherently comparable. This is why open standards work and why they can be tailored to your specific conditions. As the American cultural anthropologist Margaret Mead (most likely) said, “Always remember that you are absolutely unique. Just like everyone else.”

  2. Your mileage may vary on tolerance for walled gardens. Tool providers (sadly) often view interoperability as a necessary evil while its opposite is a huge risk for buyers. Luckily, there is a variety of solutions out there. If, for example, you are wary of having your localized content hosted by a third party, you can find solutions.

The Exception to the Rule

If you are a very large organization or if building localization tools is your core business, I would encourage you to concentrate on supporting best of breed industry standards, such as XLIFF 2.0, so that everyone else in the industry can avoid building their own platforms.

If you are not that organization, however, the answer to should you build your own platform is that, no, you probably shouldn’t. But the wisdom of (not) doing so does not, unfortunately, represent the complete answer. Building your own platform could still be necessitated if there is a lack of tools that (a) are suited to your company’s workflow requirements or (b) provide a level of interoperability and dependence that is acceptable to your business.

In the end, building your own platform might very well be the correct answer. I would still recommend that you build it in such a way that it would connect to existing standards-based tools, and that it is modular in nature, so that it could be extended or quickly adapted to meet future business needs.

 

To look at this in more detail, the next articles in the series will return to the how part of the equation. I’ll discuss:

  • How to decide on the guiding principles for your design
  • The importance of involving localization service providers throughout planning and development
  • The value of open APIs in closed systems

But, what do you think, have I convinced you that building your own platform is the wrong direction for your business? Responses welcome below.

 

Comments