Smartling has multiple features to support translation quality. Each of the following has a different purpose and best practices:
Quality Checks
Purpose: Automatically check for translation quality issues that can be defined programmatically.
Quality Checks are translation rules assigned to a project under a Quality Check Profile. The profile integrates with the CAT Tool. When a check fails (e.g., a misspelling), a warning is shown to the linguist. You can also create Custom Quality Checks using regex if a check isn't already provided in the standard list.
Quality Checks configured with a "High" severity level will prevent translations from being submitted to the next workflow step, so use this setting carefully.
Quality Checks are not applied when importing translations, updating translations from the Translation Memory, using Quick Edits in the Strings View, or when changing workflow steps from the Strings or List Views.
Issues
Purpose: Communicate that 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 with a simple Open/Close lifecycle. There are two types:
- Source Issues: Opened by linguists to request clarification from content owners about the source content.
- Translation Issues: Flag a problem with a translation. Can be opened or closed by any user with access to authorized translations. Their state is not automatically modified by workflow step changes.
Smartling recommends that Issues be used for required actions that are not related to translation quality. For quality evaluation, use LQA instead. See Issues vs. LQA for more on the distinction.
Linguistic Quality Assurance
Purpose: Objectively evaluate translation quality to provide feedback for improving linguist performance.
LQA uses a quality assurance schema to identify objective issues in translations, focusing on linguistic accuracy and proficiency. LQA evaluations can be performed by human reviewers or by LQA Agent, which automates linguistic quality assurance using AI. The goal is to help linguists understand their performance, inform strategic decisions on localization processes, and meet service-level agreements with your translation vendors.
LQA should be performed by native speakers of the target language, ideally a professional linguist, to ensure objectivity. Internal reviewers may offer more subjective feedback; instead of conducting LQA themselves, they can reject translations or use Issues to flag areas that need revision.
LQA reviewers are typically expected to correct errors while recording them. Errors are recorded based on the translation that enters the step, not the version after revisions. If a reviewed translation is rejected rather than edited, the original translator will not see the LQA error unless LQA is also enabled on their workflow step.
LQA error data remains accessible even if a translation moves between steps. The initial error recording persists and can be modified, but only on the LQA-enabled step. Never delete LQA errors, even after the translation is corrected; they serve as a historical snapshot of quality at that point in time.
LQA can be performed in a production translation project (LQA Basic) or in a separate dedicated project (LQA Suite). For more information, see Getting Started with LQA.
Issues vs. LQA
Use Issues for functional or technical problems that prevent proper use of translations, such as a translation that doesn't fit in the UI or a formatting change that causes display issues. Linguists can also open Source Issues to ask questions about source content; the best way to reduce these is by providing high-quality Visual Context, instructions, and an up-to-date Glossary.
Use LQA to provide objective feedback about translation quality, such as failing to follow the style guide or glossary, or inconsistent translations. LQA errors are not subjective, functional, or technical problems. LQA reviewers are expected to be external to your business to ensure objectivity, and to edit the translation before progressing it along the workflow.
Internal reviewers (people in your business who are fluent in the target language) are better suited to use the Issues feature and the reject function to send translations back for revision, rather than conducting LQA themselves.
When designing your LQA schema, focus on objective criteria that linguists can act on. We recommend starting with one of the pre-configured schema templates.
Important Considerations
It is important to note that quality check results are not static and can change over time. Using Quality Check to assess translations can have different results, even if translations are unchanged. Similarly, the warnings flagged to translators when saving and submitting translations in the CAT Tool can be different from the results an Account Owner or Project Manager gets if they run checks at a later point, either in the CAT Tool or Strings View.
The following are some reasons why results can change over time:
- Translations can change.
- The configuration of the Quality Check Profile can change.
- Translation Memory is continuously changing; so checks that compare to TM can have different results over time.
- Glossary can change; terms can be added/removed and configuration of terms can change.
- Spellcheck can change because the system wide dictionaries can change and we also allow users to have personal dictionaries that are used by that user and not shared with anyone else.