Localization
Introduction
The Localization structure is a feature of Teneo Studio intended to ease development and maintenance of groups of solutions that share the same business processes.
Typically, this structure is useful when customers need to implement the same or similar solutions for different languages, countries or regions.
The feature can also be applied to other situations, for examples, solutions which cover the same elements but market different sectors, or internal and external versions of the same solution.
The advantages of the Localization structure are the ability to develop and distribute re-usable processes (such as Flows, Global scripts, Language Objects, Entities, etc.), update processes for several solutions in an easy way and notify when such updates are available.
Benefits
The main benefits of the Localization structure are:
- Reusability: Once a Flow structure has been created in the Master solution, the content can easily be translated or modified to meet the purpose of the Local solution.
- Easier development: Developing a Flow from scratch is more complex than adapting an existing one; therefore advanced users can create the main Flows and objects in the Master solution and share with Local solutions, where users adapt the content to the scope of the Local solution.
- Easier maintenance: When the structure of the Flow in the Master solution is changed, this is presented as a pending update in the Local solution; the update can - with a few clicks - be applied to the Local solution and the Local user can adapt the inherited content.
- Assurance: By using the Localization structures, projects can ensure that all Local solutions implement the same business processes in the same way in all solutions, securing that these Flows represent a standard covering the required project areas in the same way.
- Comparability: When using Log Data, the user can compare the solutions because they can share the same metadata definitions and assignments, and the reporting will behave in the same way for the different solutions with only the content of the report changing.
Localization structure
A conversational AI application can only access one solution and every solution is based on one language, so when a conversational AI application should communicate in several languages, as many solutions as number of languages need to be build in the Teneo Platform.
For example, if a company has a global website in 4 different languages and wants a conversational AI application for each of those languages, 4 solutions need to be build in Teneo Studio.
In this case there will often be a lot of content which can be re-used between the different solutions, for example the Flow structures, and the main differences will be in the content, such as the answers in Output nodes or the Match Requirements (for example, the condition of a Syntax Match Requirement).
This is where the Localization feature becomes relevant as it allows to create "copies" of selected content in an existing solution (Master) and share the content with other solutions (Locals), creating a link between the Master content and the Local content to receive updates when the content is modified in the Master solution.
Furthermore, solution-specific content can be created in each of the solutions when needed, for example solution-specific Flows, Language Objects or Entities, which are independent and do not have a Localization Relation.
Main elements in Localization structures
Master solution
- The Master solution is the owner of all shared processes and documents and provide them (and any changes to them) to the Local solutions
- The Master solution shares selected documents with the Local solutions
- The Master solution is a working solution, just as the Local solutions, which can contain its own documents which are not related to, nor provided to, the Local solution(s).
Local solution
- The Local solution is a branched solution that inherit processes and documents from the Master
- The Local solution can see pending updates from the Master solution and local users can decide when they want to apply those updates
- The Local solution is a working solution, just as the Master solution, which can contain its own documents which are not related to, nor provided by, the Master solution.
Solution objects
The Master solution shares selected documents (Flows, Folders, Language Objects, Entities, Global scripts, Global Script Context, Emotions, Metadata, etc.) with the Local solutions. Local users must accept the changes before they are available in the Local solution.
Terminology
| Term | Description |
|---|---|
| Master | The Master solution |
| Local | A Local solution can inherit documents from a Master solution |
| Linking | When a relationship between a document in the Master and the Local solution exists |
| Inheritance | Means that a document in the Local solution inherits all the properties form the Master solution as specified in the inheritance rule tables |
| Branch/Branching | Creating a Local solution from a Master solution |
Linking and inheritance
Linking is the relationship that exists between an object in the Master solution and the Local solution, so objects in the Local solutions are linked whenever they have a relation to the Master solution and are unlinked if not.
Linking happens when one object in the Master solution and the Local solution share the same internal Id. This can only happen in the following situations:
- When creating a new Local solution through branching
- When a Local solution inherits new objects from the Master
- When importing a new Local solution from files with objects with identical Ids as the Master.
By default, all Local linked objects are attached to their Master counterpart. this means that the Master forces some of the property values and the Local user cannot change them in the Local solution.
Not everything in the Local solution can be edited; this is the basis of the Master and Local relationship, where some property values are provided by the Master solution, allowing to keep consistency between the solutions and removing a lot of the work needed in creating a complete solution. Therefore, some things like Flow structures are "forced upon" the Local solution, while the language used inside the Flow in nodes such as the Trigger node, Output node, etc., is solution dependent and modifiable in the Local solution.
Remember that some properties are not owned by the Master; therefore, some modifications in the Master do not appear as pending updates.
Language of the Master solution
The language of the Master solution is often chosen to be English, but of course there can be reasons to select another language.
Bear in mind that all owners of the Local solutions should be comfortable with the language of the Master solution to be able to adapt the Master content available in the Local solution.