Details
-
New Feature
-
Resolution: Duplicate
-
None
-
None
-
None
-
Empty show more show less
Description
This task template is able to define task properties. Eventually all task properties should be supported, for the first version only the properties listed below will be supported.
All properties are optional with one exception (see below). If a property is not defined in the template, the system default is used. Therefore every value needs a system default in configuration. If a task template option corresponds to a configuration which can also be made in the task management window, the task template sets the initial value of this option. It can be changed in the task management window.
The following properties can be used after this development step:
- task template name
- language combination
- workflow steps (the step order in the XML is also the order of step processing). For each step:
- step name
- type of step: (normal / MRC / ranking)
- this has influence on the server side how the data / finish of a task is processed, using type MRC means that MRC-function will be used for the user in this step
- MQM issue types should be offered: yes/no
- MQM issue types (here the MQM-xml-format defined by DFKI will be used as part of ths task template)
- segment wide QM-flags should be offered: yes/no
- segment wide status-flags should be offered: yes/no
- document related QM-criteria offered: yes/no
- task related QM-criteria offered: yes/no
- if the source is
- is the source completly locked
- is it possible to edit it completly
- or is in only possible to enter and edit MQM-tags
- if 100%-Matches are editable
- selection of samples: ranges of segments, which are editable. If not specified, all segments are editable (except 100%-matches, if locked by other option)
- task icon for the auto status
- if an initial filter is set when the proofreader opens the task. This initial filter shows only the segments edited in the previous task step
- workflow steps, whose users have to be notified, when this step is finished
- user(s) that are assigned to the step (in a later development step maybe also groups could be used here; if the template is passed via API, at least one user has to be defined). For each user:
- target alternatives this user is allowed to see
- target alternatives, which should be used for the MRC-function (Multi Review Compare Function). This is only usable in a MRC-step
- language combination(s) this user is restricted to. If this is defined, it overwrites the language combination defined above for the whole task. This way it is possible to define multiple user/language combinations in one task template and use the same task template for different language combinations.
- if the user has the right to edit or just to view the task in the editor
- user(s) that are assigned to the overall task (not to a specific step), but only have the right to view the task, not to edit it
- segment wide QM-flags to be used (use of MQM-xml-format)
- segment wide status-flags to be used (use of MQM-xml-format)
- document related QM-criteria: issue types to be used (use of MQM-xml-format)
- task related QM-criteria offered: issue types to be used (use of MQM-xml-format)
- finish of last step ends the task automatically: yes/no
Keep in mind, that the results in the GUI of the above yes / no flags should be implemented by front-end rights.
Currently only workflow steps internal to translate5 are supported. This might be extended in the future.
The current implementation of the task to user association has to be changed. Through the GUI we can currently only add a user to a task once. This association holds also the role the user has in the task. This must be changed, so that a user can be added multiple times to a task with different roles (=steps). Since we have a 1 to 1 relation between steps and roles we should also replace the role with the step.
A validation of syntax and semantics of the xml template format is implemented.
Semantics to check:
- if workflowstep is MRC: Are all MRC-relevant definitions made (like MRC-columns)
task templates on filesystem
- on each creation of a new task, translate5 looks up on the filesystem, if
- a new template has been added
- a template has been deleted
- a template has been changed (a template with a newer modification date or different filesize is handled as changed)
- changes, additions or deletions of templates are parsed and stored in the database
Additional TODOs which will be possible after implementing the whole task template stuff
Vorübersetzung gegen MT: Wenn die Checkbox dafür im languageresource-assoc-panel gesetzt wird, wird diese Einstellung nicht gespeichert. Das heißt beim nächsten Öffnen des Panels ist sie wieder weg. Das liegt daran, dass die Einstellungen überhaupt nicht gespeichert werden. Konzeptionell fehlt der save button und eigntlich sollten die Infos in die noch nicht vorhandene Task Config fließen.
Attachments
Issue Links
- blocks
-
TRANSLATE-266 Workflow nach SAE-J2450 and additional corresponding tasks (with hard-coded workflow)
- Done
-
TRANSLATE-416 Perfectionate QA-workflow: Flexibly organize QA-workflow with translate5 and be able to integrate whatever automated Quality Checker or manual steps whenever you want in the workflow
- Done
-
TRANSLATE-211 Workflow nach SAE-J2450 and additional corresponding tasks (with flexible workflow)
- Done
- duplicates
-
TRANSLATE-471 Overwrite system config by client and task
- Done
- relates to
-
TRANSLATE-222 make existing translate5 metadata options configurable by workflow
- Done
-
TRANSLATE-408 usability of translate5 task management: be completly intuitive
- Done
-
TRANSLATE-60 switch off repetition editor at task level
- Backlog