QM and metadata options in translate5

make existing translate5 metadata options configurable by workflow

The following existing metadata options need to be able to be switched on and off by workflow:

• MQM on subsegment level
• QM on segment level
• manual status on segment level

new metadata options needed

document wide QM

This option is new to translate5.

window to show and edit the document wide QM

• a special button can be clicked to pop up a window with document wide QM criteria
• this window shows in a left panel the file tree of the current task
• a click on a file in the file tree shows the document wide QM criteria and the selections which are already made for this document (if any)
• A highlightning in the file tree shows, for which files the QM criteria is missing
• In the segment grid the beginning of each file is shown in a sense making way
• which document wide QM criteria are offered is configurable by workflow
• the stucture of the document wide QM criteria is as follows:
  • a heading for each criteria
  • a customizeable number of radio buttons for each criteria (for example ok, needs enhancements, unacceptable) (if is present is specified by task-config)
  • a number of checkboxes to optionally specifiy details (if is present is specified by task-config)
  • a comment field (if is present is specified by task-config)
• If document wide QM criteria are active, a workflow step can not be finished by the user, if the criteria are not filled in for every document
• The option needs to be able to be switched on/off by workflow
• default values for task wide QM criteria are defined by translate5 installation and are identical to those, which can be defined on task level
• for each target-alternative the user is allowed to edit, there is an own tab with document-wide QM criteria, which has to be filled in

document wide QM and workflow

• the document wide QM is entered by each user of the workflow separately
• if there have been users in the workflow before, the QM criteria entered by these users are also shown in the above mentioned window - but only if they edited the same target alternatives.
• the already entered QM criteria is listed in a grid in a separate tab of the above mentioned window, one line for each previous step in the workflow.
• for each target-alternative the user is allowed to edit, there is an own tab with document-wide QM criteria, which has to be filled in
• on MRC-steps (see below) and all steps following a MRC-step, the QM criteria of all previous users from all branches which connect to each other in the MRC-step are shown in the Grid

task wide QM

This option is new to translate5.

window to show and edit the task wide QM

• a special button can be clicked to pop up a window with task wide QM criteria
• which task wide QM criteria are offered is configurable by workflow
• If task wide QM criteria are active, a workflow step can not be finished by the user, if the criteria is not filled in
• The option needs to be able to be switched on/off by workflow
• default values for document wide QM criteria are defined by translate5 installation and are identical to those, which can be defined on task level
• for each target-alternative the user is allowed to edit, there is an own tab with task-wide QM criteria, which has to be filled in

task wide QM and workflow

This is implemented in the same way as "document wide QM and workflow".

Workflow

3 different workflows (different review types) are necessary for this story. They will be called "workflow SAE-J2450 5 steps", "workflow SAE-J2450 3 steps" and "alternative workflow".

The following are the workflows, which should be able to build:

workflow SAE-J2450 with 5 steps

For this workflow the following QM-options are needed:

• MQM on subsegment level
• QM on task level

These translate5 metadata options are deactivated:

• QM on segment level (existing translate5 option, not needed for this workflow)
• manual status on segment level (existing translate5 option, not needed for this workflow)
• document wide QM

The workflow is as follows

1. step: proofreader 1 and proofreader 2 are proofreading simultaneously and indepently from each other
2. step: proofreader 3 is proofreading in MRC-mode (regarding MRC: see below)
3. step: proofreader 4 is proofreading
4. step: proofreader 3 is proofreading once again
5. step: customers pm is doing a final check, but only allowed to view the task, not to edit it

workflow SAE-J2450 with 3 steps

For this workflow the following QM-options are needed:

• MQM on subsegment level
• QM on task level

These translate5 metadata options are deactivated:

• QM on segment level (existing translate5 option, not needed for this workflow)
• manual status on segment level (existing translate5 option, not needed for this workflow)
• document wide QM

The workflow is as follows

This workflow is called "3 steps", but actually has 4 steps

1. step: proofreader 3 is proofreading
2. step: proofreader 4 is proofreading
3. step: proofreader 3 is proofreading once again
4. step: customers pm is doing a final check, but only allowed to view the task, not to edit it

alternative workflow

For this workflow the following QM-options are needed:

• document wide QM

These translate5 metadata options are deactivated:

• MQM on subsegment level
• QM on segment level (existing translate5 option, not needed for this workflow)
• manual status on segment level (existing translate5 option, not needed for this workflow)
• QM on task level

The workflow is as follows

This workflow is called "3 steps", but actually has 4 steps

1. step: proofreader 3 is proofreading
2. step: proofreader 4 is proofreading
3. step: proofreader 3 is proofreading once again
4. step: customers pm is doing a final check, but only allowed to view the task, not to edit it

way of implementation of these workflows

The most future proof way to implement these workflows in translate5 would be to implement a light-weight, thus future proof engine for flexible workflows in translate5. A faster alternative is to implement the 3 workflows as three hardcoded workflow classes, which extendthe existing workflow abstract-class.

It will implement

• their workflow steps
• the actions which are done, when a user finishes a step
  • check if document wide or task wide QM have been filled in (depending on what is defined for this workflow step)
  • send mail to next users in the workflow
  • triggering changes.xliff
  • set correct autostatus
  • interact with MRC-feature, as described for this feature

The workflow will be selectable via API and GUI.
After workflow is selected, users can be assigned to the different workflow steps. If the workflow is changed, all assignments of users to workflow steps of the previously selected workflow are deleted.

The following properties are needed from customers point of view for this:

• workflow name
• different workflow steps
• set by each workflow step, the step order in the XML is also the order of step processing
  • name of step
  • type of step: normal / MRC / ranking
  • if MQM-criteria is available (MQM stands for Multidimensional Quality Metrics. This is the Metrics developed by DFKI to judge the translation quality. In translate5 MQM-tags can be inserted inside the segment as orange tags to mark errors on subsegment level.)
  • which MQM-criteria are available
  • if standard QM-criteria on segment level is available (so far this can not be deactivated in translate5)
  • if standard status-flags are available (so far this can only be deactivated by translate5 instance)
  • if document-wide QM-criteria are available
  • which document-wide QM-criteria are available
  • if task-wide QM-criteria are available
  • which task-wide QM-criteria are available
  • if the workflow step is a "Multi Review Compare" Step (MRC-Step) (regarding MRC see below).
  • selection of samples: ranges of segments, which are editable. If not specified, all segments are editable (except 100%-matches, if locked by other option)
  • 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
  • which user(s) are assigned to a step
• after each step the users of the next workflow step will get an email which lists the changes made by the user of the previous steps.
• each user, regardless in which step, should always see all segments of the task in the initial filtering

Multi Review Compare Workflow Steps

This option is new to translate5.

In Multi Review Compare Steps (MRC-Steps) of a workflow, the previous workflow step is done not only by 1 proofreader, but by 2 proofreader simultaneously and indepently from each other.

• The proofreader who does the MRC-step gets presented a special interface for each segment, which had been changed by one or 2 of the previous proofreaders.
• This interface will be placed inside the segment grid at the normal editing position of a segment.
• The segment is editable in the standard way, but it does not contain the changes of any of the previous proofreaders. That means, that the user can edit the segment directly, or choose one of the MRC-variants. This applies to all columns, also to the source column if editable.
• Instead below the editable segment the changed segment-variants of one or both previous proofreaders are shown.
• In these segment-variants the changes are shown with change marks (see corresponding section of this Jira-story). The segment-variants are not editable, but clickable. This is shown by a nice mouse over effect. A click on the segment accepts the corresponding segment-variant and adopts its content to the editable segment field.
• For MRC-segments, who have variants changed by the previous proofreaders, a new translate5 autostatus is introduced: "MRC-variants". For these segments this is the initial autostatus at the beginning of a MRC-step. Same is true for the workflow-step filterable column
• a user who is assigned to a MRC-step will get 2 independent notification emails of the 2 previous parallel working users of the workflow at the time each of them finishes its workflow with 2 independent lists of changed segments. The second email explicit shows the MRC-user, that all previous users have finished their work.

• regarding document-wide and task-wide QM: on MRC-steps (see below) and all steps following a MRC-step, the QM criteria of all previous users from all branches which connect to each other in the MRC-step are shown in the table which shows the previously entered QM data.

• regarding history entries (see below), which originate from MRC-workflow-steps: the previous revisions (which technically originate from different target alternatives) will be shown in the current target alternative in the segment history.
  • They will be marked as originating from different branches in the workflow to show.
  • This shows, that they are not revisions from each other.
  • Their change markers will not point to the previous revision in the change history (as normally) but to the previous revision which originated from the same branch.

Live-Tagging of terminology based on Multiterm

Standard tagging of terminology is currently done by providing a TBX-file and the use of xliffTermTagger.

Live-Tagging of terminology based on Multiterm will be implemented as an alternative.

The best way to do live-tagging of terms against SDL technology would be to pass an entire segment to a Trados API call and get it back with terminology tagged. So far this does not seem to be possible according to Trados Studio or Multiterm SDKs. Not direct nor indirect.

Therefore the best way to implement live-tagging of terminology is to use Multiterm-API to create a Termbase export and use xliffTermTagger to tag the terms inside translate5.

To achieve best performance and as well as real live tagging it is best to implement the feature in the following way:

• after importing a task in translate5, the necessary Multiterm export is done for the first time
• based on this export all segments of the task are tagged with xliffTermTagger
• when opening a task for editing,
  • all terminology is tagged already - due to the tagging right after the import (which might be a few days or weeks old)
  • another Multiterm export of the relevant terminology is triggered
  • based on this second export,
    • all segments are tagged a second time.
    • At first this new tagging will be done for the segments currently loaded by the browser, at first for the top few segments of the current range. This way it is made sure, that at least after the first few segments all segments opened for editing already are newly tagged against the second Multiterm export.
    • If the current selection is changed in translate5 through setting of a filter or through scrolling done more than 200 segments, it is taken care of, that this new selection is newly tagged at first (if not done already)
    • If a change to the initial tagging result is detected, the browser is notified and loads the newly tagged segment.
    • The user is notified, in which of the currently loaded segments the termTagging did change. If this change does affect a segment currently opened for editing, the user is notified about this. He has to close (and if he wants to reopen) the segment in order to see the new termTagging.
  • on saving of each segment, the segment always is newly tagged against the Multiterm export which had been fetched at task opening.

Tag verification on segment save

This is new to translate5.

• On saving a segment translate5 will check, if a tag misses or is placed in a wrong order.
• If yes, the segment can not be saved.
• The error message shows, what exactly is wrong.
• The tags in the segment can be restored by using STRG-Z or the undo button or the revision history.

Segment history - rollback of changes in the GUI

This option is new to translate5.

A segment history will be implemented in translate5:

• The history shows all previous revisions of a segment of the same translate5-task including all segment metadata and including the initially imported version
• Change markers (see below) show the changes to the previous revision
• By choosing a revision the revision is taken over as current segment content
• For revisions, that are taken over, the translate5 metadata "last editor" will be the person, who did take over the revision.
• For revisions, that are taken over, a new translate5 autostatus "restored from history" will be introduced.

undo and redo buttons

This option is new to translate5.

• there will be undo and redo buttons in the toolbar, which so far holds the save-, cancel-, next-segment-, etc. buttons.
• Their functionality will be completly identical with pressing STRG-Z / STRG-Y in the editable segment field.
• A tooltip on the buttons will show the shortcut

change marks

This option is new to translate5.

translate5 already supports change marks for the export for Trados Studio and the CSV-export. The existing algorithm should be used, to show change marks inside translate5.

These change marks should show:

• which text is added by highlighting this text
• which text is deleted by score out this text

The change marks will appear

• in each segment, regardless if it is opened or not. These change marks show the diff to the imported version of the segment
• in the revision history. These change marks show the diff to the previous version of the segment

While editing a segment, deleting or adding text leads to change marks, too. Existing change marks are handled in a sense-making way (see sub-task).

Improvement of MQM-tagging in translate5

MQM-tagging in translate5 exists. With MQM-tagging several errors can be marked on subsegment level inside a segment. The marks can overlap each other.

The editing and deleting of existing MQM-tags needs to be improved for better usability.

• if the cursor in a segment is inside a MQM-tag, this tag can be edited in the segment metadata. Its tags are highlighted with an additional left and right border. Its comment and severity is selected and in the list of the latest added MQM-tags and in the MQM-tree the corresponding tag is marked in a sense-making way.
• if the cursor is inside several overlaping MQM-tags, the tag which is opend last is selected for editing
• if a MQM-tag is selected for editing,
  • a new button "Delete" appears in the MQM-area of the segment metadata panel. It deletes the currently selected MQM-Tag
  • the button "add MQM-tag" is renamed in "edit MQM-Tag"
  • below this button the MQM-tag which can currently be edited is shown
• if text is selected, no existing MQM-tag is selected for editing, regardless if the cursor is inside a MQM-tag or not. Instead a new tag can be inserted as usual.

The user, who added a MQM tag needs to be recorded

• according to MQM-syntax as specified by Arle Lommel, the user who adds the tag is added to the MQM-tag as saved with the segment in the database
• this user will be the user used for this tag when exporting MQM-tags with a CSV-export
• this user will be shown as a property of this tag
  • in the segment metadata-panel, when the tag is selected for editing
  • in the tooltip, when the user hovers over the tag

selection of samples

This option is new to translate5.

• In the task template and in the "add task" window of translate5 a new option "select samples" is added.
• With this option one or several ranges of segments can be specified as editable. All other segments are imported too, but are locked and not editable in translate5.
• The specified segment numbers correspond with the segment numbers in Trados (caution: sdlxliff-parsing is reverse engineering due to lack of documention for the format. Therefore it may be necessary in certain unkown cases in the future, to adjust the parser to some specialties of the format, which are currently unknown to the translate5 development team.)

xlsx-Export

• all columns of the translate5 editor interface (and not additional content) will be exported to Excel-columns
• For source- and target-text columns this includes terminology markup, tags and MQM-tags.
• Due to limitations of Excel it is propably not possible, to have a non-editable complete object to represent a tag. In addition a tooltip is propably not possible. Therefore:
  • MQM-tags will be exported as editable chars with orange background and without the tooltip they have in translate5. They will look the same they look in translate5, though.
  • MQM-tooltip data from translate5 (MQM-type, MQM-severity, MQM-comments, MQM-user) will be added in 2 extra columns: "MQM tags in source" and "MQM tags in target"
  • normal tags will be exported as editable chars with green background and without the tooltip they have in translate5. They will look the same they look in translate5 short tag mode, though.
  • marked terminology will not have a tooltip with the term definition.
  • the autostatus will not be represented by the image you see in translate5, but as the text, which the image in translate5 shows as tooltip.
• one task is represented by one spreadsheet. The content of each file of the task will be represented through a separate sheet in this spreadsheet

watch list

This option is new to translate5.

A watch list for segments is implemented in the editor:

• in the toolbar with the save-, cancel- buttons for the opened segment a button "watch" is integrated
• a button "watch list" is implemented next to the existing button "reset sorting/filtering"
• on click off this button, a filter is set to show only the segments with "yes" in the watch-column

change editable source: Only MQM-tags should be able to be inserted

• It should not be possible to edit the entire source any more.

integrate external php-modules in beosphere

• via opening of new browser window
• via direct integration in beosphere HTML-code