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.
In Teneo, Localization is solved through the concept of branching.
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:
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:
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.
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:
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.
For Class match requirements you will in most cases just need to translate the training data. This can be done through the Class Manager.
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.
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:
Once you have opened the Entity, make sure to localize both the Entry and the String variable.
Note that Script variables do not need to be localized as they are usually written as a Script.
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:
For Condition-based match requirements, you will need to construct Conditional Match Requirements.
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?