The purpose of this article is to answer common questions about the LQA module (LSPs) in XTM Cloud and to help resolve issues you might experience with it.

When a Correct step has been implemented in the workflow (updating the original translation), is it still possible to perform LQA, on the original translation step (i.e. pre-Correct step), in the LQA step?

LQA can be only performed on the preceding step. For example, if your workflow is Translate → Correct → LQA, the LQA process will be always performed on the Correct step.

Can we the make evaluator and evaluee anonymous in the LQA report? Do we have such a setting in the security settings?

Security settings are strictly related to XTM Workbench and TM manager or metadata. These settings have no effect on the LQA report.

Is there a setting that will enable us to download LQA reports as the LSP?

Yes, there is such a setting. In the LSP’s settings, the contractor must enable the appropriate LQA-related access rights to permit the LSP to download LQA reports. To do so, select Users → LSPs → (select an LSP) → LSP Editor → Access rights → LQA. All of the boxes must be selected.

Open

How can we download project-specific LQA extended reports? Currently, we can only download the LQA extended report on a language-specific basis. This means downloading extended reports one by one, for each language, which is time-consuming.

LQA extended reports can be downloaded via the API. You will receive the results in a JSON file. This feature is available from XTM Cloud v.13.3.

Our multi-project LQA report is missing some projects. Can you explain why?

If there is no LQA report for the relevant project in its LQA tab (Project editor → LQA), the project will not be included in the multi-project LQA report.

Open

We performed LQA on a project but the LQA report is empty/not generated at all, in the LQA tab. Why is that?

The LQA process is quite complex. Certain prerequisites have to be met, for the report to be generated correctly.

1. There must be 2 steps in the workflow, for example “Translate” and “Correct” or “Translate” and “LQA”.

2. In the project’s workflow, the second step must have the following setting enables, in the Workflow editor: LQA → Yes, save result in user record.

3. The users/LSPs must have all the LQA settings available in their access rights so that the records can be saved [Select Users → LSPs → (select a user/LSP) → Edit user/LSP Editor → Access rights → LQA].

4. Only the users assigned to the “Translate” step and “LQA” step need to perform the action. If someone else, who is not assigned, performs the action in those steps (for example, the Project manager), the report will not be generated. The LQA is based on the statistics for the assigned user: if there are no statistics for that user, there will be no LQA report.

5. The “Translate” step (the step preceding the “LQA” step) must be finished and all segments must be set to “Done”, otherwise, the LQA errors will not be included in the LQA report.

6. Once the project’s workflow is finished, the LQA report should be generated correctly.

7. Note that reverting the workflow will result in the LQA errors being removed, so the entire LQA process would need to be performed again.

8. The LQA process evaluates the previous user who worked on the previous step. This mechanism is hard-coded and a necessity for LQA to work and for reports to be generated.

9. The next critical issue is that the user must perform a major action on a segment (change the translation or confirm the segment), for the segment to be included in the LQA report. If the Linguist does not confirm the segment because it was already done, and an error is then added in the “LQA” step, the segment will not be included in the LQA report. Consequently, when the approved ICE match is automatically set as “Done”, the LQA error will not be included. However, the situation is different if a particular segment contains a not approved ICE match and that segment has been automatically set to "Done" in XTM Workbench. If the Linguist additionally "confirms" that segment (by simply entering the segment, clicking "Enter", and leaving the segment), any LQA error that is applied to that segment later on, in a subsequent workflow step, will be included in the LQA report (which is of course in contrast to an approved ICE match, for which an LQA error will not be included in the report, as already mentioned above).

How can we configure LQA in a continuous project? Will LQA entries be stored in a segment permanently, in future iterations? Will LQA entries affect the score in future iterations? Will a new LQA report be generated each time we run the workflow and complete the LQA step?

A continuous project update action without project reanalysis causes LQA errors to be removed from segments. This changes their segment status from Completed to Incomplete (either because their content has been changed or their state qualifier changes). This applies for all workflow steps in which the LQA option is enabled. If no change has been made to a particular segment, its LQA errors, applied in the first iteration of the project, will remain intact.

A continuous project update action with project reanalysis removes all the LQA errors from the workflow steps for which the LQA option has been enabled, regardless of each segment's actual status.

If you perform the entire workflow from the beginning with each file update, the LQA report will be generated each time.