# Multilingual Projects on the NLG Platform
Translating just like writing did not scale in the past. The production of translations was as dependent on the number of translators involved as text production was on its writers.
# What to expect from this guide?
# (Machine) Translation vs Automated Text Generation
Today there are automated solutions for translation (as well as text production): On the one hand automated translation (also machine translation) and on the other hand the automated multilingual text production.
Automated text-generation is not equally automated translation. In automated translation, finished texts in one language are translated by machine to one or more languages. It's roughly the same as you work with Google Translate: you put in a finished text, choose your source language, and then get the translation. In contrast, with automated text generation, translation does not take place after generation, but is part of the text project. In these projects, data, logics, structure and variance of the texts are processed centrally. The texts in different languages are generated out of one project.
In automated translation . The semantic rules are created separately from the language and can therefore be applied to any language. Only the linguistic elements have to be adapted. These synergies lead to the fact that with AX Semantics you can localize contents much faster into several languages.
# Benefits of Automated Text Generation
What are the benefits of automated text creation in comparison to the translation of texts? (also machine translation)
- reducing costs for external translators
- reduced effort for managing translation processes
- ensured content conformity across languages
- It’s possible to work on several languages at the same time (in traditional process the main language has to be completed before translating. Every minor change lead to high efforts.
- The text structure and message/statement of the copy is the same for all languages
# Preparing Multilingual Projects
General Questions to ask: In what ways will the content differ? To what extent does this affect the automated text project? In some cases you will decide to automate only a part of the content if the requirements are too different.
- composing different content/stories (for different languages)
- selecting different products: Choosing only a part of the product range for different languages
- checking out product names/licenses checks, think also on different data/number formats
- taking into account legal questions for the generated text
- defining overarching target groups for the languages
# Preparing your data - how do they should look like?
The situation that on the NLG platform different languages are created in a common project and not produced by a translation after the output of the first language, leads to the fact that special requirements are made on the form and structure of the data.
Same data structure - translated values
First of all, this applies to the language of the data. Data is not per se language neutral. Of course, there are cases in which all data are available as numbers, for example, and it therefore does not matter in which language the target text will be formulated. But in most cases, there will be words or other values in the data that do not apply to all languages to be generated. Therefore, data has to be available in all target languages. So, if you haven't data in multilingual form, you have to translate the values.
The second important requirement applies to the structure of the data. To be able to set up the project properly it is necessary that the data has the same or at least very similar structure in all languages.
This means, that the data must have the same data fields in all languages. Since all logic operation and relationships in the project, such as containers or triggers, refer to the data field names, the data fields must have the same name in all languages.
Working with Lookup Tables for translating data values? In principle, it is possible to skip the translation of the data before creating the project and to translate the data values via a lookup table. For this, one can use the same data for all languages and translate them within the project. This procedure only works as long as there are only a few data sets that need to be translated and if the data sets will not change.
As a rule, it is faster and less error-prone to translate the data in advance. Especially the maintenance effort afterwards is significantly lower.
Language settings are attached to Collections
On the AX platform, the properties that affect the data, as well as language, are organized in collections. For multilingual projects each language has to have its separate collection. When a collection is created, the corresponding language is selected from the very beginning.
If you have assigned a language to a collection, the language modules for these languages are activated. That means:
- The software ensures the grammatical correctness of the content in the containers, with regard to the respective languages.
- You can set the respective language as preview language.
- You have language-specific selection options when configuring containers, such as pronouns, cases or grammatical genders.
# The Setup of Multilingual Projects
When managing multilingual projects, the first decision to be made is which language will be the main language in which the project will be developed with conditions and logics, as well as in which the copy will be composed. In this main language, the project is created in the same way as any monolingual project. Then it is extended with the additional languages by creating the corresponding collections and translating the text parts.
- Copying Logics: Multilingual projects can be set up in such a way that the conditions and logics are developed in one language and then copied and adapted for the second (third, fourth, etc.) language. This works quite well, but can lead to double maintenance effort if changes are still made to the logics after copying in the main language.
- Managing centrally: The slightly different method of setting up the logics in a main language and apply the logics and conditions to the subordinated languages as well has proven to be the most efficient way of handling multilingual projects.
The method of setting up the logics in a main language and transfer the logics and conditions to the subordinated languages has proven to be the most efficient way of handling multilingual projects.
# Adjusting Collections for Centrally Managing Projects
At the data level, this means that the data in each project within a collection must be available in the main language as well as in the new language so that the project runs without errors. While the values of the main language are used for processing the data within the project, the values of the target languages are then displayed in the texts.
# Adding Languages to the Main Languages within the projects
As soon as you have created the collection of the main language, work on your text project begins, which proceeds in the same way as for monolingual projects: You write your statements based on a test object and take care of the right calculations, logics and triggers in the Transform.
In the next step you change the preview language and the Test object for the second language you want to use.
# Translating the statements
Then translation starts: You have to translate the parts of the project, that are not build up of the variables out of the data. For this you have to copy your statements with all associated branches and triggers and translate the statements into the sublanguage.
When translating, it is helpful to open the project in two tabs: one with the settings of the main language and the finished statements, and the other with the settings of the target language for translating the statements.
# Multilingual Projects – Step-by-Step
- Define your text concept for different languages (see localization )
- Customize your data structure according to your text concept and ensure consistency across languages. (see )
- Translate your data values (if necessary)
- Create your project with your main language collection
- Create your collections for the various languages
- Define a test object for testing each languages
- Run the analysis for the main language
- Write your statements for your main language & define the logics and triggers
# Maintaining Multilingual Projects
Quality Assurance - how to manage it (proofreading translations, different test objects) Writing once and just one translation. Statement Loops for
// ## Notizen
Die Texte müssen nicht 1:1 in den Sprachen gleich sein, sie können unterschiedlich sein, vor allem, wenn man Trigger setzt, die auf Zufall oder Gewichtung basieren für Branches oder Synonyme.
es fehlen Einstellungen Testobjekte.