Resourcen wie TM, Terminologie und Chat kommen vom Mutterserver

 

 

General idea

A task will be assignable to another translate5 instance, Instead of assigning a task to another user.

For each task the following data will be transferred to the other instance:

• Data imported for
  • translation or review
  • pivot language
  • visual layout
  • reference files
• Assigned language resources
  • TM
  • Terminology

 No user information will be transferred between the instances.

The Language-resources need to be compartmented on the child-system so they cannot be used for other tasks and they can be removed when the task is finished

Details

Handling of inline mark-up (in the segment):

• The following inline mark-up will be kept:
  • inline tags (standing for code mark-up in orig file)
• The following inline mark-up will be stripped, when transferred back and forth between the instances and re-calculated on (re-)import:
  • MQM and Auto-QA (including terminology and spell-, grammar- and style-checking)
  • TrackChanges

 Defining access projectForward specific configurations

The "clients" section of translate5 will be renamed to "Business partners" to cover clients and service providers alike (both sides of the delivery chain).

A new section "projectForward" is added to system configuration with the following 6 new fields:

• Text field "URL of partners translate5 server" (overwritable on client level)
• Boolean field: Receive projects from partner (info text: "Partner must enable this also")  (overwritable on client level)
• Boolean field: Send projects to partner (info text: "Partner must enable this also")  (overwritable on client level)
• Boolean field: Save translations automatically to TM on re-import (info text: "if checked, translations are automatically re-saved to TMs, that are assigned with write permission to the task")  (overwritable on client and import level)
• Boolean field: Create new analysis automatically on transfer of task (info text: "if checked, right before the task is transferred to the child instance a new analysis is run) (overwritable on client and import level).

• • To ensure, this does not create unnecessary server load, a new timestamp for a language resource is added in the DB, that contains the time, when the last time a segment has been saved or updated in the language resource. If this timestamp is older than the timestamp of the last analysis, no new analysis will be run.
• Default PM for received projects: Selection list with all PMs in the system (if the current user as only client-PM rights: All PMs of the client) (overwritable on client and import level)

CHANGE: we better have a seperate datamodel for configuring the Forward/Remote-Instances. The crucial drawback of the above concept is, that there can be no foreign-key relation pointing to a specific Forward/Remote-Instance, what we surely to set up proper associations

Assigning of tasks to / Receiving them from a business partner

This will be possible completely analogous to the assignment of tasks to users:

If in the config the partner url is configured and "Receive projects from partner" is active, this partner URL will be selectable as assignable user for a task an task level (user assignment tab), in the task import wizard and in the client defaults - just like a usual user.

Directly after assignment the task will be send to the partner instance. It will create a project and a task in the partner instance by using the translator package (see section "transferring of data") and the meta data (see section "meta data of projects and tasks"). It will save the project and task IDs or GUIDs of the task in the foreignID and foreignName fields. In addition the workflowstep name will be added to the foreignID/foreignName fields. If the project to which the task belongs already exists on the child server, it will be added as task of this project, but only, if the workflow step matches.

The workflow step name will be added to the project name of the created project.

Once received on the child server, the task is treated similar as if it had been created locally:

• PM that is set in the config is set as PM and informed via mail about the new task. The mail is triggered via cron every 15 min and contains all tasks, that have been received in that time grouped by project.
• Pre-defined users are assigned and notified
• Pre-defined additional language resources are assigned and if there are new language resources the pre-translation is run again.
• The autoQA is run

The task will be transferred back to the parent server as soon as the workflow of the task has the status "workflow ended".

ForwardedTasks are locked for local users and can only be edited on the remote system.

We may need two new task-types: "Sent Forwarded Task" & "Received Forwarded Task"

Several "Remote" workflow-Steps will create several taks on the child/remote-system

Meta data of projects and tasks

The following meta-data of the task on the parent instance is used to create the task on the child instance

• Project name (workflow step name of the assigned workflow step is added at the end behind a pipe)
• Project description
• Source text is editable
• Edit 100% Matches
• Source language
• Target language
• Pivot language

As pricing preset the one is used, that is set as default on the child instance for the business partner.

Transferring of data

The basis should be the current translator package feature. When used inside the projectForward feature, the data for visual and pivot should be added and a new translate5 task should be created in the target instance based on this package.

Xliff and pivot xliff

• For translation data exchange not the original files are used, but the generated xliff 1.2 files. Same for pivot data.
• This implies, the projectForward feature is only available at least in the first stage for projects that stem from okapi converted data or from xliff 1.2 files, that are directly imported into translate5.
• As it is the case in the translator package, TrackChanges data and autoQA markup are deleted from the task data, when fueling it into the translator package
• Applied pre-translations will be part of the transferred task data - as in the translator package
• Original source files will not be transferred and thus no export of original source files will be possible
• Import in the "Child" translate5 instance will work analogous to the usual translate5 import (from the technical side), but of course via API between the 2 instances
• Re-Import of the data of the child instance into the parent instance will parse the translation/review xliff and update the segments in the task.
• Important addition to the translator package behavior: Currently all TrackChanges data that existed prior to the re-import is deleted from the task. With this feature this should be changed, so that the existing trackChanges markup is kept and changes to the segments are inserted as new additions and deletions.
• After Import/Re-import auto-QA will be run

TM and Terminology

• Data is transferred as TMX and TBX between the instances and imported in newly created language resources based on what is implemented in the translator package
• Those language resources are listed in the language resource overview, but are not assignable to any other "Business partners" then the one, they are stemming from. In addition it is not possible to export them
• As soon as the task is transferred back from the child to the parent instance, the TM and Terminology data for that task is deleted from its server
• TMX and TBX data is only transferred from parent to child server, not vice versa
• After a task is returned from the child server to the parent server, the task can be re-saved to the TM to "clean" the translations into the TM. An option "save task to writable TMs" is added to the language resource association tab of the task.
• If this re-saving is done automatically after returning of the task can be defined on "Business partner" level (see above).

Analysis

• As analysis the last analysis for the task on the parents instance is transferred to the clients instance as part of the translator package and imported in the child  instance.
• No new analysis or pre-translation is triggered on the child instance if there are only the transfered languageResources assigned. Then the imported analysis is shown. Otherwise a Analysis has to be generated on transfer
• The reason this behavior is, that their might be new segments in the assigned TMs since the analysis has been run. And for business reasons it is important, that the last analysis of the task in the parent system matches the analysis in the child instance AND that it matches the analysis that has been used on the parent system to create a translation order.

Auto-QA

• Auto-QA is automatically re-run after the (re-)import is done, since no Auto-QA information is transferred between the instances.

Access: Roles & Rights & AppTokens

Accessing the remote-system and vice-versa must be limited to the tasks and related data that is transferred only. The access generally must be setup with an App-token but we cannot use the API-role but must add new roles to achieve this level of protection (presumably "RemoteSender" and "RemoteReceiver"

Error-handling

 A good focus must be on error-handling for this issue. Tasks where the project-forwarding did fail for some reason must be marked with a warning icon in the task, and project grid and in the assignment grid  itself. A click on the warning icon must lead corresponding entry in the task log table in the GUI.

Transfer could fail for example, if

• The other side has not TM resource configured, but TM data should be transferred with the task
• The other side does not allow the current translate5 instance to transfer the project to it
• The other side runs into a translate5 error

Implementation Ideas

New Datamodel "RemoteSetup" to be able to store the configuration for a Remote-System.

• seperate GUI like File-Format-Settings
• Holds Data representing a "Child" on a parent system and "Parent" on a child system (distinguished by flag)
• When a "Parent" entry is created automatically a 1:1 related "Remote User" is created having an App-Key-configured that is to to be used for Associations
• When a "Child" entry is created there is a 1:1 related Client/Customer created (representing the parent system and needed to bind the "Remote tasks" to) AND a "Remote User" (to be used to provide the app-token).
• A "Remote Relation" is meant to have fixed Parent & Child roles. Whenever a two-way relation would be needed, two configurations must be set up
• has a unique hash-value/GUID that identifies the RemoteSetup. This hash is generated on the parent and must be provided alongside the app-token on the child-system when the remote-Setup is done. This hash/GUID is sent with any remote-request to identify the RemoteSetup

Introduce a "RemoteUser" that represents the Forward/Remote System in the workflow-perspective on the Parent System

• has a foreign key to the "RemoteSystem"
• Remote-users will not show up in the User-Management
• Are used to identify /trigger the special actions when workflow steps are started/finished
• Have a special display-name that represent the Configured Forward-System
• Can have two roles "remote_parent" or "remote_child" to be able to distinguish their use
• Only "remote_parent"s can be assigned to tasks
• "remote_child" users are only to hold the App-token and are otherwise invisible. Assigning users to child-tasks is to be done on the child-system by pm's (-> child-tasks are all bound to the "Remote Client/Customer" created on setup)

Connection/Security:

• There is a single Controller providing the Endpoints for all needed Requests between both systems
• Only remote-Users have access to this endpoint
• the roles introduced for the remote stuff can not be assigned to normal users

Maintenance

• There should be an API / Button in the "RemoteSystem" management to check if the sytem is properly set up: All users are created with their correct roles, all customers, the remote system can be reached and everything is set up correctly there as well (-> "check"-Endpint in Controller)