Dear members, due to maintenance work, the RWS Community might be down tomorrow, Wednesday, 06.07.2022, from 05:30 AM CET to 06:30 AM CET. We thank you for your time and understanding throughout the process.

Qualitivity

This wiki is based on the original links from the application to the developers home pages.  It's not a comprehensive guide to the use of Qualitivity but we can enhance it over time and will be happy to add any guides that may have been written by people using this application.

=====================================

Qualitivity is a plugin for SDL Studio that fully integrates with the API, geared to manage the data related to productivity & quality as the users are working on documents from the Studio Editor.   In short, it provides functionality to track the time spent on translating, reviewing & post-editing the segments from documents, but additionally includes functionality to track every single change made to the segments at a granular level and a means to generate reports based on that data in structured and readable format.

The name Qualitivity suggests that it is a cross between productivity and quality, simply because that is the type of functionality that it is equipped to provide.  It works in the background without any interaction from the linguist while they are working, gathering the data required for their activity.

One of the main advantages of working with a tool like this is that it keeps a complete comparable copy of every single action applied that qualifies as an addition, deletion or adaption of any of the properties in the segments of the document that the linguist is working on.

By comparable, we mean that a record is created that encapsulates not only the latest version of the segment (after the changes have been applied), but also a cloned copy of the segment prior to those changes;  so that it provides a complete cascading type of report representing each adaption to the segments.  This has enormous potential in the type of useful information that can be generated from the data that could benefit all parties in the process, that being the linguist, LSP and/or the client.

All of these are important characteristic as they provide the basis for calculating the production costs understanding not only what changed but also the time taken to make those changes. Because the data that is maintained with the plugin is so robust, some very interesting type of reports can be generated, which might make it seem like the reports are always a work in progress…
 
The built in document overview is a very comprehensive overview of all the work entertained on the document from the linguist for single or multiple edit sessions. It compiles all interactions applied by the linguist while working on the document and represents those changes in a structured/ readable format.

The cost of production is also integrated with this report taking into consideration the association between the weight of the changes applied to the segments by the linguist and the language rates associated with the activity for that document or documents.

A very important aspect in production is the time taken to do the work, including how and what changes are applied; for this purpose the tool manages the production time and keystroke data.   The decision to track the keystroke data is ultimately the decision of the user and ONLY tracks keystrokes from the Studio Editor window.

The type of production time data that is managed with the plugin:

  • Opened and closed a document
  • Document active on the screen and being worked on by the linguist; useful when the linguist is working on multiple documents contemporarily or in the case that they are working on a merged file and/or a virtually merged file.  In this case the time spent on each document depends on what segment the user is working on.
  • Entered and exited a segment
  • The date/time spent typing or adapting the content in the segment; in this case the date/time is associated with the individual keystrokes
  • The movement across the file

 
Integrated with the keystroke data, is the feature to understand what TM or MT engine was used for providing the translation, if the linguist selected more than one or adapted the translation before finalizing the translation.  It also identifies correctly when the translation was copied from source etc…

The plugin also includes a feature that can be activated from within the Studio Editor that manages the Quality Metrics; this allows the user to import some of the more known standards such as TAUS DQF, SAE J2450 & MQM Core... for measuring quality.  This has enormous benefit to how the quality of the translations from a document are measured in a revision cycle.   The Quality Assessment report generated from this data is useful in providing an overview on the commonality of the linguistic errors, where they occurred,  in what context and who (or what TM, MT etc…) applied them; keeping in mind that the type of reports generated from these assessments are relative to what the user is evaluating; meaning, it might also be applicable in assessing the translations from an MT engine in a certain domain.

Besides the reports built into the plugin that are generated to provide a visual representation on the data gathered, you can also export that data to Excel and/or XML format.  This allows for interoperability at a basic level, in that it provides all parties with a means to integrate the data gathered from the plugin into their own platforms or systems… from there, they can then generate their own statistical reports, charts etc…

There is also a feature built into the plugin that permits the user to create a hand-off package of all the reports for a specific project, activity in the case that these reports from the plugin are used in the workflow between the linguist and client.

Something that I have noticed quite a lot recently as we are constantly evolving in more competitive environments, is when things go drastically wrong in a project.  It happens to the most prepared professionals (PM, Linguists alike).

Let’s examine a case where a linguist is required to use a specific MT engine, or TM or Terminology term base as part of a contract with the LSP and because of this, the linguist spends twice as much time working on translating the content due to specific issues (i.e. incorrect TM, Termbase, bad MT et.c..) that push the initial deadline out and also has a direct impact on the quality (simply because the linguist was forced to work in a certain way…)  The unforeseen aspects that turn your projects into a living nightmare for everyone involved is something we try to avoid, but when deadlines are pushed and the quality of your work degrades to a certain degree, the involvement with your client is inevitable and understanding what went wrong in the process becomes paramount.   Because this plugin provides you with unique insight in to all interactions during the translation/revision life cycle, it can improve drastically your approach in explaining these scenarios.

  • From the Linguist point of view: they have proof of the work that they entertained and the time it took to achieve it; this might also help in renegotiating their contract in some cases where the issues are part of the initial planning from the LSP.
  • From the LSP (or Language Provider) point of view: they can explain clearly the issues along with detailed reports as to reasons why deadlines are not met; these reports should also form the basis for a structured review of what could improve in the next cycle/planning
  • From the Client point of view: they have a clear overview of the issues with view to the details gathered at the translation level; this also builds on the trust aspect with the LSP as they are working on a much more transparent level

Technical Requirements

The following is a list of the minimum technical requirements

 

Related Articles

 

 

Random Screen Views

Related
Recommended