Considerations in choosing an enterprise-level TMS

Although in a previous article entitled “Disruptive innovation in translation management systems” I asserted that the software as a service (SaaS) delivery model has produced great end results, I do not recommend buyers concern themselves too much with buzz words (or in this case, acronyms) such as SaaS when selecting a translation management system (TMS). It is buyer criteria that matters when choosing a TMS, and each situation is different. With that in mind, let’s take a look at considerations in choosing a solution for enterprise buyers.

It can be difficult to put the variety of offerings into context simply by studying and comparing marketing materials or feature lists. Begin instead with a list of your own criteria. Enterprise customers may be interested in TMS for a variety of reasons, including automation, cost savings, transparency, process ownership, branding consistency across business units, improved context, increased speed of workflow, multivendor support and the list goes on. How do you choose?[bctt tweet=”Most language service providers (LSPs) are using solutions behind the scenes already.” username=”multilingualmag”]

Identify your deal-breakers, your must-haves and your nice-to-haves. Think about not just immediate needs, but potential future needs. Then engage technology vendors to ask how they can address your particular needs. And by the way, you are bound to encounter some exciting functionality you had not imagined or realized you needed along the way!

Here is a list of considerations in choosing a TMS for enterprise, in no particular order. Some items in this list touch only lightly on subject matter that can go quite deep, and might prompt more questions. Please reach out if there is a particular topic you would like to see covered in more detail.

And now some food for thought:

What file types require support? Consult TMS manuals for the list of supported file types and, importantly, get a Statement of Work (SOW) for any file types not supported out-of-the-box. Pricing for this type of customization (custom parsers) can range anywhere from hundreds of dollars to tens of thousands of dollars. Without a parser for your file type you are opening yourself up to hourly engineering fees for repeated manual pre- and post-processing tasks.

Do you require any level of customization? Consider requesting an SOW for some small piece of customization in order to gauge the cost of professional services. Keep in mind per-day or per-hour costs are less meaningful when one technology vendor would take three weeks to accomplish what another can do in five days.

Are you intending to process software files containing metadata such as character limits, string identifiers or developer comments? If so ask your technology provider if the tool can make use of the metadata and ask for a demonstration using your own files.

What technical issues do you wish to solve? If you have specific reoccurring issues in your translation deliveries, make a list of those for discussion with technology vendors. As an example, here are some I have endeavored to address in the past:

  • Regression bugs due to inability to store multiple translations for matching source text with varying translations, including
    1. Plurals, which were recognized as repeat text, rather than distinct translation memory (TM) entries
    2. English words that can have multiple translations, depending on context (e.g. “Free” as in “free disk space”, and “Free” as in “at no cost”)
    3. Source text that can require shortened translation in some cases, but not others, depending on placement in a mobile application.
  • Inability to in-context extract and match software strings that have changed order and general lack of ID-based matching.
  • Inability to see developer comments in the translation environment.
  • Lack of native support for some of our main file types.

[bctt tweet=”Be wary of sales pitches involving percentage discounts based on consolidation of tools and language services with a single vendor.” username=”multilingualmag”]Do you have a strict budget? You may be able to immediately eliminate certain solutions based solely on price.

Most language service providers (LSPs) are using solutions behind the scenes already. Does your LSP offer a one-size-fits-all solution or have they selected a solution with your particular needs in mind? In the latter case it might be sensible to consider adopting the solution they have selected for you.

Do you have the in-house expertise to understand the nitty-gritty details around the process and tooling? If not, you can compensate for that by consulting unbiased sources, such as other enterprise customers and tool-agnostic LSPs or independent consultants who have experience with a variety of solutions. Do not rely solely on salespeople.

By that same token, be wary of sales pitches involving percentage discounts based on consolidation of tools and language services with a single vendor. The complexity of TM leverage statistics and the hourly charges associated with localization make percentage discounts offered by LSPs that control processes you do not understand pretty meaningless, particularly if you are locking yourself into a situation where you have nothing with which to compare costs and no direct access to or understanding of the data.

Adopting tools that are not the best fit for your content will result in increased language services fees, either due to inability to optimize TM leverage or due to repetitive manual processes that incur engineering fees. Some of these inefficiencies will be difficult if not impossible to measure after implementation. An ounce of prevention is worth a pound of cure. Avoid potential conflicts of interest whenever possible.

Are you using multiple vendors? An LSP-agnostic solution will give you the maximum flexibility to use any LSP or translator you would like and to move projects between vendors as needed without incurring leverage loss or disrupting processes.

Do you want a hosted system or will you host your own?

Are your development teams using agile? It’s possible to implement a TMS that allows for constant updates, even for files already out for translation.

Check on the ability of the system to provide context during translation. Can the solution display screenshots? WYSIWYG? Ask for a demonstration. The more contextual information you can provide during translation, the fewer the issues you have to fix during review or linguistic testing.

What content management systems (CMSs) might require support now or in the future? Even if CMS admins are not immediately planning to connect to your TMS, you should check for connectors, keeping as many doors open for other organizations across your company as possible, since centralization of TM assets has many benefits.

Are you interested in automation now or potentially in the future? Make sure an API is available and run it by your engineering team if possible. If you plan to outsource engineering work, make sure the cost of professional services is within your scope. There are also third-party developers available with localization expertise.

How long would it take to implement the TMS? It’s a question well worth asking. Hint: some take months to get up and running while others take days.

Do you use software with string IDs? ID-based matching is a must-have for anyone translating software files containing unique string identifiers.

Do you require third party linguistic verification? If so, check to see if the workflow can send a single project between multiple vendors or other users, such as in-country reviewers. Some systems simply cannot be configured to send a single project between multiple LSPs.

Pricing models vary greatly. Some pricing is posted openly on websites. However, some pricing is not as transparent and you will need to request a quote. I have encountered all of the following pricing models:

  • Number of languages (rare, but it has happened)
  • Base cost + throughput
  • Number of licenses
  • Number of concurrent licenses (simultaneous logins)

The level of support included is extremely important. Contact other clients, if you can, and ask about their level of satisfaction with the support.

  • Does support include TM imports?
  • Does support include TM alignments?
  • Does support include filter creation?
  • How quickly does support respond?
  • How user friendly is the ticketing system?
  • Pricing for support

Do translators and/or vendors have to purchase licenses to work with the tool? Is there a free desktop client available for the tool?

What will be the cost of the initial migration effort? Most of us have existing TM by the time we are selecting a TMS. There may be a cost associated with migrating your existing translation assets if you require outside help.

Ask the technology vendor about their favorite “cool” features. See what they have to offer that you may not have even imagined.

Test for TM leverage loss and consult the technology vendor about possibilities for mitigation. A certain level of leverage loss for docs is usually inevitable, but worst-case scenario is hopefully no more than 20%, and ideally much lower. Leverage loss for docs should be carefully evaluated. I have seen as much as 40% salvaged from a handful of global search and replaces in TM. For software files with string identifiers, alignments should be done and zero leverage loss can be expected.

Run a pilot project before you commit!

This list is not comprehensive, and not all items are critical for every enterprise, but I hope it gives you some food for thought when selecting an enterprise-level TMS. It is difficult to find a perfect solution, but if you plan carefully you might come pretty close, considering the variety of offerings now available.

Implementing a TMS is no small task and it would serve you well to engage your LSPs early in the process. Check at both the management and at the project team level to make sure you have your LSPs’ support before you implement a TMS. Be open to making adjustments if an LSP is resistant rather than collaborative, or if an LSP is not able to take ownership of and demonstrate accountability for new processes. As with any big change in process, there is a possibility it may not work for everyone who signed on under different circumstances. I guarantee there are LSPs eager and able to help you succeed.

Happy TMSing!

Jenny Reid
Jenny Reid recently joined Guidewire Software as a senior localization project manager and is scrum product owner for tooling to support continuous localization and contextual translation. She has worked in a variety of localization roles, including QA testing, linguistic quality management, localization engineering, vendor management and project management. She has ten years of experience in TMS implementation and administration.

RELATED ARTICLES

Weekly Digest

Subscribe to stay updated

 
MultiLingual Media LLC