Localization

Once we have built a successful bot and rolled it out for one market, we want to be able to expand that bot. Aside from expanding it in terms of functionality and use cases, we may also want to introduce it into different languages and markets. However, simply translating training data and bot answers into a different language would be an inefficient approach, and is often not enough; a different market tends to mean various cultural differences that dictate which use cases should be included in the bot, and in some cases, the backend systems our bot interacts with will differ between regions and markets as well. Languages, markets, and other project specificities all determine how our bot should look and act, and achieving this to the highest standard requires a more fine-tuned approach.

1-icons

In Teneo, Localization is solved through the concept of branching.

Localization using branching in Teneo

Branching allows us to efficiently solve the localization problem. By first designing and developing our main master solution for one specific language and market, and then branching from there, we can easily reuse whichever parts we want in our new local solutions. In this way, our local solutions are created with all of the parts of the master solution that we want to include, and we're free to create and add all the other content that might be necessary to support the local language and market.

In Teneo we call these solutions 'Master' and 'Local', where the Master solution is the main solution every Local solution is created from. The full list of terminology can be found in our documentation.

We recommend for one common language to be chosen when creating the main Master solution. In large companies where the common language is English, this may mean that the best approach is using a solution in English even if the bot was developed in a different language. This is because the local solution owners must be comfortable with the content inside the Master solution to be able to create accurate Local solutions.

A detailed explanation of these steps can be found here.

The button used for branching a solution can be found in the solution overview and looks like this:

Branching solution view

The buttons used for establishing the content of your local branch inside your solution can be found in the 'Branching' section in the top bar and look like this:

Top navigation bar for branching

High-level process

Part of the general process for localizing a bot is to get an overview of the use cases. Knowing the content will help us to better plan, as the localization depends on the specific language, market, and content.

The first step is to decide on what parts of the content to localize in the Master bot and enable these for branching.

What to Localize

Selecting the flows that are relevant for localization is not always an easy thing to do. That is why we recommend for the developer to have a deep understanding of how the Master bot works before adding everything to the Local solution. Consider the following recommendations when choosing what content is relevant:

  • Cultural aspect - for countries that use similar language but have different cultures, it is important not to create these flows inside the Master solution. These should instead be manually added to the Local solution.
  • Lingual aspect - Paths inside flows might differ depending on the language of the solution. The solution owner should think of vague use cases that work for specific languages and create these in the Local solutions.
  • Market-specific cases - one thing that is relevant for a certain market might not be relevant across all markets. For example, there may be a promotion going on in Europe that might not be relevant to the Asian side of the business.

Once you have finished choosing the relevant content, you can branch from the Master solution to create your new Local solution. The next step is to then go through the solution flow by flow and localize the content of the flows.

The first step is usually to go through the flow trigger and match requirements and starting by translating the example inputs which should trigger the flow.
Understanding and translating the example inputs will give a good idea of the scope of the flow and transitions inside the flow and let you decide on the most suitable match requirements.

Class Match Requirements

For Class match requirements you will in most cases just need to translate the training data. This can be done through the Class Manager.

3-class_match_req

However, please note that in certain cases, some flows may need to make use of Linguistic Modelling Language based match requirements as well to get the precision needed in the specific language.

Entity Match Requirements

For Entity match requirements you will need to localize the content inside the selected Entity. This can be done in one of the following ways:

  • Editing the current Entity by
    • Opening the Entity from the flow - This can be done by selecting the relevant node and holding Ctrl while clicking once on the Entity. This will open the Entity in a different window.
    • Locating the Entity from the solution window - This can done by locating the relevant Entity among the Language Objects created inside the solution and opening it in 'Edit' mode.

Once you have opened the Entity, make sure to localize both the Entry and the String variable.

4-entities

Note that Script variables do not need to be localized as they are usually written as a Script.

  • Creating your own Entity with the relevant use-case in your own way. A guide on how to create your own Entities can be found here.

3-entity_match_req

Language Object Match Requirements

For Language Object match requirements you will need to localize the content inside the selected Language Object. This can be done in one of the following ways:

  • Editing the current Language Object by
    • Opening the Language Object from the flow - This can be done by selecting the relevant node and holding Ctrl while clicking once on the Language Object. This will open the Language Object in a different window.
    • Locating the Language Object from the solution window - This can done by locating the relevant Language Object among the Language Objects created inside the solution and opening it in 'Edit' mode.
  • Creating your own Language Object with the relevant use-case in your own way. A guide on how to create your own Language Objects can be found here.

3-lang_obj_match_req

Conditional Match Requirements

For Condition-based match requirements, you will need to construct Conditional Match Requirements.

  • This is easier if your language has language resources, as you can make use of the pre-built language objects to match a large number of expressions.
  • Normally we recommend that you create and use language objects to represent your domain-specific language, as these will help you scale your solution. These language objects are likely to be inherited from your Master solution.

3-condition_match_req

Depending on the language you need to localize, you now have a few different options. For languages with language resources, the localization process will be much easier and take less time. This is because the Teneo Lexical Resources are large collections of predefined language objects that can be used in language conditions. The developer will have the option to use existing Language Objects and only need to create language objects .

For languages without any Language Resources, this localization will take a bit longer as it's recommended to create Language Objects to have reusable language assets.

In the How to section, we will demonstrate how the localization can be done.

Was this page helpful?