Quality Features and Best Practices
Smartling has multiple features to support translation quality. Each has a different purpose and best practices.
Purpose: Automatically check for certain kinds of translation quality issues that can be defined programmatically.
Quality Checks are a set of translation rules assigned to a specific Project under a Quality Check Profile. The profile is integrated with the Smartling CAT Tool for linguists to follow in their translations. When a Quality Check fails to pass its evaluation e.g. if a translation contains a misspelling, a warning is shown in the CAT Tool.
Quality Checks configured with a “High” severity levels will prevent translations from being submitted to the next workflow step. For this reason, it’s recommended to use this setting carefully and judiciously.
Quality Checks will not be applied when importing translations, updating translations from the Translation Memory (including propagating to the project strings) or when using Quick Edits in the Strings View, or when changing workflows steps from the Strings or List Views.
Purpose: A channel between content owners and linguists to communicate a required change should be made to the source content, context, instructions or the translation.
Smartling's Issues feature is a lightweight “action-required"communication system that can track problems in the source and/or the translations. It has a simple Open/Close lifecycle to support translation project management.
Source Strings Issues require attention from the content owners. They are opened by linguists typically seeking further information about the content.
Translation Issues require the attention of the person who translated the string. They can be opened or closed by any user who has access to translations that have been authorized, and their state is not automatically modified by workflow step changes.
Historically, Issues have been used to track “quality” by some users. However, with the introduction of Linguistic Quality Assurance Smartling recommends that Issues be used exclusively to communicate required actions that are not related to translation quality.
Historically, Issues have been used to track “quality”. However, with the introduction of Linguistic Quality Assurance Smartling recommends that Issues be used exclusively to communicate required actions that are not related to translation quality.
Continue reading to Issues Vs. LQA for more on this.
Linguistic Quality Assurance
Purpose: Objectively evaluate the quality of translations for the purpose of improving the quality by providing feedback to the linguists.
LQA is a human-driven process that is based on creating a quality assurance schema that describes objective issues that are seen when evaluating the translations for linguistic accuracy and proficiency.
The goal is to evaluate translations and then report on the overall quality to help your linguists understand how well they are performing. It can be used to make strategic decisions on your localization process and to satisfy service-level agreements with your translation vendors. The users performing LQA should be native speakers of the translation language.
If you are currently using Smartling's DQF feature, talk to your Customer Success Manager about switching to Smartling's superior LQA.
Issues vs LQA
Smartling strongly recommends reserving the Issues feature for tracking “bugs” in your implementation and integration that prevent you from using the translations. For example, if a translation doesn’t display correctly due to a limitation in an application user interface where the translation is used, you might open a translation Issue to request that the translators reduce the length of a translation to fit in the space.
Another example could be to alert the linguists that a formatting change or addition in the translation does not work or creates a visual aesthetic issue in the end application. When responding to these kinds of issues the linguists may need to choose a less desirable translation or formatting to satisfy the technical issue.
Linguists can use the Source Issues to communicate questions that they have about the source content to help them understand it before they produce translations. The best way to avoid or resolve Source Issues is to provide high quality Visual Context and instructions, and keep your Glossary up to date.
LQA should be used to provide feedback about the quality of translations using criteria that are as objective as possible. LQA errors are not subjective, functional or technical problems. Rather they indicate that an objective problem with the translation: translators failed to follow the style guide or glossary, or are the translations being inconsistent.
Content owners should design their LQA Schemas to avoid subjective feedback about translation quality. This kind of feedback is difficult to respond to because often it’s a matter of opinion. When designing your schema we recommend you use the Smartling's Standard LQA Schema or consider one of several well known and popular “error typologies” that linguists may be familiar with.