Translate (Tab)
In general, translations can be performed directly in the project in the Write Tab. For projects that require more organizational effort for translations, the Translate tab is provided. This is where Translation packages are created and then edited in the Translate App. This is also where these Translation Packages are reviewed and merged. Our machine translation is powered by deepl and supports the same languages.
Basic description of working with multilingual projects
Conventional translation - including machine translation with Google Translate or Deepl - translates the finished texts as units. In contrast, with automated text generation, translation does not take place after generation but is part of the text projects. In these projects, the data, logics, structure and variance of the text are processed centrally. The texts in different languages are then generated out of one project.
Instead of making multiple copies of one text, on the NLG Platform the semantic rules are created separately from the language and can therefore be applied to any language.
The start language of each project is requested when the project is created. In the project settings, you define the additional languages you want to have access to in this project. 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.
Activate the language modules
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 have language-specific selection options when configuring containers, such as pronouns, cases or grammatical genders.
- You can set the respective language as a preview language.
- Preview Test Objects can be assigned to a specific language
Translate the translatable parts
To translate a text project from one language to another, the statements in the Write tab of the first language are copied, then the new language is set as the preview language and the statement is pasted there. After that, the parts that need to be translated are changed in the statement.
Machine Translation with copy and paste
You can have the copied content automatically translated when you paste it into the same or a different statement or phrase in another language (branching and containers included). This works both from the context menu and from the copy/paste keyboard shortcuts.
In the advanced settings of your account you can set the mode for this machine translation:
- Always translate
- never translate
- be asked
Translation Packages
Translation packages let you create an isolated, workflow-based environment for translators to translate a project's content from one language to another.
Translators exist! They don't know the cockpit and they actually don't need to, and you don't want them to touch random shit in the ruleset, so here's a feature that provides you with:
Isolation
When you create a translation package, a copy of your project is created with it, isolating translators from your production project.
Simplified
Our translate app lets translators focus on just the parts of the ruleset that contains language-sensitive (?) content, hiding complexity like the transformer and vertigo. (see object types).
Workflow
In contrast to a ruleset, which can be updated again and again, translation packages and the translate app center around a translation workflow that can be completed. Each translation package is broken up into smaller translation items, something something smaller progress?
Rights Managment
Something something translator role, assignees, translate app.
Workflow
Translation packages represent a roundtrip of:
create & assign -> translate -> review & merge -> archive
Translation packages are designed to be finished and archived, don't reuse them for multiple translations. Create new translation packages instead.
Create Translation Packages
You can initiate the translation process with Translation Packages in the Translate tab of the Composer area as soon as you consider the generation project and its ruleset are sufficiently completed in the source language.
To do this, you create Translation Packages that cover the translatable parts of the text generation project, like statements with containers and branches, as well as the content of Phrase nodes, Lookup entries.
Conditions and logics from the Transform area or Stories are not shown to translators, because they do not need to be translated.
Once created, Translation Packages are automatically displayed on the dashboards of assigned translators.
What can you do with Translation Packages?
- multiple Translation Packages for a project, each of which reflects the state of the project when it was created.
- can be assigned to one or multiple translators
- status archived Translation Packages.
Translation Items
Translation items track the state of translation for each object in the ruleset of a package. They get their label and type from the object that's referenced. They have a state and a timelime of comments and state changes. One translation item is created for each object when then translation package is created, with the exception of lexicon entries. When syncing, items might be created or deleted.
Only objects for which a translation item exist can be translated in the translate app.
There are four types of translation items / objects (they refer to the corresponding elements in the AX Cockpit):
- Statement
- Phrase Node
- Lookup Table Entry
- (Lexicon Entry) – This item is not automatically created in the Translation Packages, but is created as needed for the target languages in the Translation App.
Translation Item States
Each translation item is in of the following states at all times:
Not Started | Translation item has never been touched. Up for grabs to be worked on. |
In Progress | A translator is currently working on the item, be aware. (The translator might have gone home for the day, but we'll give them their in progress items first in the list again). |
Needs Editing | Marks the item as needing work from a translator. Set by a translator. Either "I'll get back to it later" or "Some other translator needs to have another look". Look out for comments. The state is changed only after one translator mark the item as done. |
Blocked | Marks the item as unresolvable by a translator. Request for help by a platform user. The "bad" intermediate end state for the translator. Often needs to be coupled with a comment, so your colleagues know what the problem is. |
Unblocked | Marks the item from blocked to resolved. Passes the item back to the translator which blocked it. |
Submitted | Marks the item as translated. The "good" intermediate end state for the translator. The item will be reviewed by your colleagues on the main APP. Lexicon entries created directly by translators start with this state. |
In Review | A platform user is currently reviewing this. Similar to in progress. |
Rejected | A translator needs to work on this again. Set by a platform user while reviewing. Often coupled with a comment. The state is changed only after one translator mark the item as done. |
Merged | End state, translation has been successfully merged into the source project by a platform user. |
Outdated | After sync when an item was done and the source content changed, a translator needs to check it again. |
Deleted | Only set when on sync the source has been deleted. |
Translation Item Sub-Workflows (?)
Happy Path
This is the ideal path a translation item can take. A translator translates the item in the translate app in one go, submits it, after which you or another cockpit user reviews it and merges it back into the project.
Rejection and resubmit
If you notice a problem when reviewing a submitted item, you can reject it, giving it back to the translator to improve it. When rejecting you should write a comment letting the translator know what you found.
After fixing the problem, the translator will submit the item again, at which point you can review it, ultimately merging it, or, if there are still problems, rejecting it.
Needs editing
If a translator encounters a blocker they think they can solve themselves later, they can mark an item as needs editing, moving it out of in progress. This leaves the item in control of the translators.
Blocking and unblocking
If a translator thinks they are stuck and need help from you or another cockpit user, they can mark an item as blocked and write a comment, signaling a problem to you.
This is intended for cases when there are problems in parts of the ruleset that aren't visible to translators, like vertigo expressions.
To fix such a problem in the ruleset copy of a translation package, use the sync feature and then mark the item as unblocked.
Sync
You can sync your production project ruleset to the project copy of a translation package at any time with the sync button. This will update all parts of the project not editable by translators.
If a translation item is new it will be silently updated or removed completely if the underlying object is gone. If an item is in any other state, it will be either marked as outdated or deleted to indicate the update to translators.
We recommend to use sync only to roll out small improvements to a package, since syncing a lot of changes will result in A MESS.