What kind of Localization Tech Stack do I need?

What kind of Localization Tech Stack do I need?

Before we answer this question let’s address the paradigm divide that lives within the question: the process-first vs. the software-first paradigm. Each different paradigm will result in different answers and rationale for these answers.Let’s start by defining these paradigms.

The process-first paradigm

The process-first paradigm takes the process and establishes it as a relatively immutable given. The search is for a tech stack that best fits the process. The process is typically broken down into smaller components and each component is then mapped onto a kind of software.

In the process-first approach, people in Localization typically begin by listing their process as their requirements. But this process-first approach also has a great divide: people who are beginning to build their tech stack from the ground up and people who already have systems for several of their processes in place.

Let’s begin by examining people who are building from the ground up assuming they have at least a CAT (computer-aided translation) tool at their disposal. So for instance let’s start with this process as an example:

1. Stakeholders request via email
2. Project Managers meet with stakeholders over requirements
3. Project Managers prepare the assets for quoting
4. Project managers load the assets onto the CAT tool
5. Project Managers download the log file and generate a quote based on the logfile
6. Stakeholders approve the quote
7. Project Managers prepare assets and send files, translation memory, and glossary kit to translators
8. Translators complete the task in their own CAT tools
9. Translators send files back to Project Managers
10. Project Managers QA assets
11. Project Managers deliver back assets to stakeholders

It is common for people to break down their process into categories: business management, translation management, accounting, communication, quality management, connectors. In this context, the CAT tool is the fundamental software component in any tech stack. Without it, you will not be able to leverage knowledge in the form of translation memory and termbases.

The software-first paradigm

The software-first paradigm looks first at the different software available in the market and then tries to build out an effective process that leverages what each software does.The other tech stack components are typically layered onto the CAT tool. A big upgrade for instance would be to layer a business management system such as Plunet or XTRF to keep track of the different receivables and payables in each project as well as project status, ownership, vendors etc…You can then think about adding a quality management such as Content-quo, you can use middleware software to integrate your connectors, add an accounting software such as Xero or Quickbooks and ta-da! You are done.Literally done. You now have a tech stack, but the question remains: what is the simplest and most effective way to predictably manage your translations? With all these different softwares you are looking at:

• Steep license fees,
• lots of engineering overhead to keep all these different platforms working,
• lots of back and forth with different support teams and
• the intensely frustrating process of trying to connect systems that fundamentally were not made to connect to each other.

Lesson #1

Having the software stack that covers all your use-case needs from a feature vs. use-case compatibility does not ensure you will have an effective software infrastructure in place. Keeping it simple, lean and easy to manage has immense impact in your overall management overtime. As an evolution from this paradigm, many companies choose to go with a translation management system such as Memsource, MemoQ, Trados or others. And while Translation Management systems are great and offer a more seamless integration with translators, translation memories, project managers and clients you are still stuck with the remaining tech-stack that won’t be rendered obsolete.And here it comes:

Lesson # 2

There is an abyss between software intended to automate vs. accommodate. Most people I encounter look for software that will accommodate a use-case. They will consequently typically require a combination of different softwares to accommodate the different dimensions of their use-case and most-importantly, they will favor software with lots of customizable fields, and data-entry flexibility. For instance:

• I want a field for my translator’s t-shirt size
• I want a field for my client’s birthday
• I want to be able to enter different rates for the weekend and night
• I want to be able to charge per word, per sentence and per paragraph

You get the picture. You can go crazy over what you would like your software to accommodate and in many ways you would be right in doing so. But on the flip-side you could reconsider the relevance of all these requirements and focus on the most basic and abstract concepts that you are trying to accomplish, for instance:

• Minimize time-to-market
• Minimize human intervention
• Maximize customer engagement
• Maximize quality governance tools

When you look at the bigger picture those hard specific requirements fade out into softer and dimmer ideas that are not hard asks anymore. The picture then changes and a software like Bureau Works becomes very appealing.

Give birth to the new

Bureau Works was built to tackle the end-to-end localization workflow including:

• Quoting/scoping,
• Translation memory,
• Content management,
• Automatic job dispatching to translators and other relevant parties,
• Payables and receivables,
• Quality management.

You can replace 5 different software components with Bureau Works:Bye, Translation  Management System, bye-bye Business Management System, bye-bye Quality Management System, Hello Bureau Works! :)Obviously, Bureau Works while integrated across different user needs, is not an ultimate panacea for all your pains. It’s great if you are looking for ultimate efficiency and are not looking to work with exception after exception as your rule. As an automation-first software Bureau Works was designed to keep fields and manual data-entry to the bare minimum. So it’s not a great software if you want a field for your translator’s favorite pet or if you want to manually add as many fields as necessary. It’s also not a great fit if you want to keep your translators working in whatever CAT tool they like (although it’s possible) and if you are looking to maximize your team’s headcount and need for manual work.

But that’s really what it comes down to: the why?

Are you looking for software to maintain the status quo or are you looking for software that will allow you to redesign how you work fundamentally? This question changes everything. While intimidating and seemingly risky, the re-design approach opens endless possibilities if relentlessly pursued. It’s also fine to keep things as they are and assemble and patchwork of systems to cover that use-case.It’s like building a house thinking about past requirements versus building thinking about future possibilities. While I don’t believe there is a categorically correct approach, it’s a matter of having clarity on where you stand so that you don’t end up unknowingly somewhere in the middle.