The Watson Assistant Guide to Multilingual Chatbots

We talk a lot about personalizing assistants to your users’ needs, and what’s more personal than speaking in the language they prefer? You can’t deliver a great experience if users struggle to understand your assistant in a non-native language. This guide outline 3.5 (not a typo!) strategies for delivering an assistant that can speak multiple languages.

Automatic language translation has come a long way in the past decade, but it’s still not perfect. That said, in most cases, it performs more than well enough to get the job done. If the number of users requiring additional languages is relatively small, and your use case isn’t full of jargon, then adding a translation API, like Watson Language Translator, can get this done in a day’s worth of effort.

The flow is simple: a user sends a message to Watson and Watson sends a response back. We’ll use the pre- and post-message webhooks to intercept and translate in between.

1. Take the user’s message

2. Identify the language in the message with the Language Translator Language Identification endpoint, and then translate the message to the language of the assistant

3. Get the response from Watson

4. Translate it back to the user’s language based on context set in step 2

5. Send response user.

We’re quite confident that Watson will understand the incoming message with a high degree of accuracy. You can overcome any issues with the machine translation with small additions to your intent training data, and our classifier can pick up the rest of the context to accurately identify your user’s intent.

But this simple approach has a tradeoff in lower level of accuracy, and that happens when Watson responds back to the user. It’s difficult to translate personality, tone, and idiom perfectly. For example, if you intend to respond in a formal voice, the translation might be less formal than you’d like. The meaning is the same but the way it comes across is not. In some use cases this won’t be a problem. Where this does matter you can consider strategy 2.

In cases where a perfectly translated response is required, you can still save time and effort by using a single dialog skill for multiple languages, just like in strategy 1. However, in this case, you have a team of native speakers writing the responses for each answer. You don’t need to worry about intent training data, which is always changing and improving, and you don’t need to worry about your dialog logic, which can be difficult to reproduce or maintain a second copy.

With this strategy, simply add a context variable for the input language. Then, using the Multiple Conditioned Responses configuration on your dialog node, write a bespoke response with perfect tone and semantics in the response language.

Note: add a final condition of ‘true’ to capture cases where the user doesn’t need a translation and the assistant can respond in the same language.

This strategy adds only a small amount of maintenance overhead to the assistant, while expanding your user base exponentially. It also gives you a higher degree of control over how your assistant will behave, which increases confidence when venturing into new territory.

Strategy 2 is typically the route we suggest customers take, and many of them have proven its efficacy in production. It gives more control without adding much maintenance. However, in some cases, bringing in language experts and dropping them into a complex enterprise dialog tree doesn’t go smoothly. You start to worry that someone inexperienced will break other’s work, or edit work they shouldn’t be editing. Our Enterprise plan has audit logging, but that only helps you point the finger, not prevent the problem.

To implement this pattern, we need to set up a few things first:

1. Create a Cloudant NoSQL Database

3. Set up an IBM Cloud Function to implement the pre- and post-message webhooks from the original git repo in pattern 1.

Creating answer units will look something like this:

Now that we have all the prerequisites, we need to understand the flow:

Looking like this:

This is the last resort. Just as you would hire an additional employee who speaks a foreign language when needed, you can train a second Watson Assistant skill to do the same. I suggest you resort to this only when the above strategies don’t give you the degree of accuracy you need, and you have a user base large enough to warrant this additional effort. Of course building something a second time will go much faster than the first, but over the long term maintaining two versions of the same skill, and keeping them nearly in sync is going to cause headaches. However, if you have a large enough business case to warrant investing in a separate skill to allow yourself complete control over every aspect of the solution, then a second assistant will certainly open up any configuration you need to get hands on with.

Related posts:

If you are looking for unique Country Quiz about countries in Europe, North America, Asia and other continents of the world, you have come to the right place. We have compiled some of the hardest…

To love is to value what is in the best interest of another person. This could be a romantic partner, a friend, your child(ren). This can require sacrifice-in fact it is almost guaranteed to require…