When convenience collides with translations

[Alex Coope - SN]

So I wanted to start this week's blog with a bit of a thought experiment, which might be a bit controversial to some, however I think it's an important topic to help those who don't necessarily know to be fully aware of the options available. That is to say, let's explore when on-the-fly MT is suitable vs when it's not.

On-the-fly (Machine) Translation vs Static Translation

Before we get too far into the weeds of the details, "MT" or "Machine Translation" is a technology that can translate a source string / sentence / piece of text into another language aka a "target language". Over the years it's been revolutionary for many reasons. Did you know that the concepts of Machine Translation has been around since the 1950's?

It has the potential (when harnessed in the right ways) to significantly reduce cost and effort, yet it can also introduce new challenges, such as a lack of desired context to make a significant determination on the desired style. To combat that there's also another concept in the industry called a "TMS" or "Translation Management System" which is a bit like a middleware that sits between the translation capability and the MT capability to control the styles and glossaries of a given translation. Now, to be fair this is a fairly mature concept with regards to translation processes, as in a TMS is not often used by less experienced Organisations or those with smaller budgets, it's just to say they exist.

A "static" translation is not really an industry term, however I'm going to use it here to convey the idea of a translation being performed for a given piece of the UI and it is stored in the application's stack to be served for a user of that language preference (imagine our 5 translation tables contents for example). How those are populated is entirely up to you, they can be manually translated, they can be Machine Translated or even a hybrid, however the key take away here is that the translations are fully stored for use and not just cache'd.

So we know that there are many options out there for us as platform owners, developers etc, so let's discuss why one might be better than another in a given scenario:

Convenience vs Cost vs Quality vs Speed
On-the-fly translations can be very convenient as they physically scale quite easily. For example if a Cloud MT Provider adds a new language, then you can benefit from it immediately with very little effort on your part. The cost however can become quite daunting quite quickly, because typically the costs are per translation request via their respective API's which can also vary based on how much is being translated.

It's therefore best to consider the use-cases you are trying to cover and how they would benefit, as well as how they are being utilised as there could be a different / better way:

For example:

People to People chats / communication across languages

• Small / short amounts of content (sentences vs pages of documents).
• Quality is less important due to content being more conversational in nature.
• Speed is crucial to ensure time to serve is maintained.

This use-case is a good candidate for leveraging on-the-fly translations, there's no way human translators could translate fast enough within a given chat;

• The in-platform solution for this would be "Agent Chat" with "Dynamic Translation" to a Cloud MT Provider such as Google, Microsoft Azure or IBM Watson spokes.

Rapid content publication

• New content being generated frequently with a rapid need to have them available in other languages quickly.
• Many different types of authors of this type of content, such as Support Agents needing to provide notices, workarounds etc to Customers (internal / external) in other languages quickly.
• Sharing the knowledge is crucial for the time to serve being maintained (possibly due to established SLA's).
• The content is not legally binding content, or detailed policies.

This use-case is a good candidate for leveraging on-the-fly translations (as the quality control isn't as needed as what would be required for legally binding documents or detailed policies);

• The in-platform solution for this would be "Translation Management" (within Knowledge Management) with "Dynamic Translation" to a Cloud MT Provider such as Google, Microsoft Azure or IBM Watson spokes.

UI translation

• A complex UI needs to be available in multiple languages.
• New content is being added all the time.
• 100% coverage is very important.
• A new language might need to be added at any time.

For this example I'm going to use a Service Portal, and to make it easier let's pretend we can translate what you see in the Service Portal on-the-fly into any language (like Klingon because I like a bit of Star Trek every now and then). 

Q1 - is this technically possible? - yes, yes it is
Q2 - is this feasible? - I would argue no it's not and there's some good reasons why

Leveraging on-the-fly translation capabilities for a UI presents a few business problems:
1. Quality & Consistency of terms

With the strings being sent to the MT being as short as they are (sometimes single words or acronyms), it will be very difficult to ensure consistency and good business quality across the UX journey as a Cloud MT does not factor in your style guides and glossary of terms. Which means it's quite possible the translations might not convey what you need them to.

2. Cost

Typically, with these types of set-ups an API call takes place per visit / per view, which means there is the potential that it could get very costly the more people view your content in languages other than English as it's being translated each time.

3. Scale

With more languages, are they all performing as desired?

One way of combatting the cost (for UI's at least) is to translate the UI (either MT, Human or Hybrid) and store the translations in the application for re-use. Meaning the cost of translation is only performed once and used multiple times.

For example, if I wanted to translate a menu, I could do that, store it in the necessary translation tables in the languages I need, then anyone can consume those translations. Where as if I leveraged on-the-fly translations I could benefit from many languages but each visit / view of that menu potentially is a new translation each time, which might not be very efficient in terms of scaling up (depending on which way you look at it). 

You could think of it like this;

• One-the-fly translation is a 1:1 relationship (need : use)
• Static translation is a 1:many relationship (need : use)

Summary

So, as with any Solution Design concept and considerations, it's always important to start with the "why" then review all of the options available so that the best informed decision can be made. Because the seemingly easiest might not necessarily be the best for your specific needs. When-ever I'm designing something new I always do a pro vs cons list, then the option with the most pro's wins. As you can probably tell, there's no right or wrong answer as it comes down to your specific needs and use-cases at that time, however the most important aspect is knowing what's possible and what the potential implications are for any of the options available.

If you'd like to learn more about the concepts and features in the platform, please check out my "In-Platform Language Support Guide" here. And if you'd like to learn more about translations work in the platform, check out our dedicated Learning path on NowLearning here.

If you found this helpful, please like, share and subscribe for more as it always helps