This video explains how to run quality assurance using some of the built-in functions in OmegaT as well as external programs.
Internal functions: Spelling checker
In addition to checking spelling and grammar on-the-fly, OmegaT provides a script called spellcheck.groovy that can check spelling in the entire project or current file. By running this script, you get a window with errors that you can “ignore” (disregard as false positives without adding them to the project’s custom dictionary) or “learn” (add to the project’s custom dictionary) . You can jump to a segment for making corrections by clicking that segment number.
Because OmegaT adds learned words to the custom dictionary limited to the current project (/omegat/learned_words.txt), you need to transfer those words into your general custom dictionary if you want to keep building your dictionary. For more information about this, see my video about a project template.
Internal functions: Tag validation
OmegaT has built-in tag checking. By clicking Tools → Validate Tags or Validate Tags for Current Document, you display a window similar to the spelling checker output, allowing you to check for errors and jump to segments for correction. Checking tags is important, because missing or incorrect tags will cause problems with translated files, including the inability to open them.
Internal functions: QA – Check Rules
Finally, OmegaT provides a general QA script “QA – Check Rules” (check_rules.groovy), which checks for common error types, including:
- untranslated segments,
- inconsistent numbers,
- missing punctuation, and more.
It also lists spelling and tag errors, which can serve as a reminder if you forget to check for these types of errors using the functions described above.
You can also use any other quality assurance tool to check translations made in OmegaT, such as ApSIC Xbench, CheckMate, or Verifika. Whichever program you choose, you start by loading files generated from OmegaT. This could be:
- “/omegat/project_save.tmx” which includes all translations committed to the translation memory in your current project;
- “project name-level2.tmx” created by saving target documents. It is more compatible with external QA tools than “project_save.tmx.” For example, using project name-level2.tmx will allow Verifika to recognize tags correctly.
- a TMX generated using a script;
- bilingual files. If you work on bilingual files such as SDLXLIFF, you are often better off checking these files rather than a TM, because you might notice problems that OmegaT and the TM do not show. However, by checking such files, you lose the ability to make changes directly in Verifika.
After loading your file, process it in the QA tool just like any other bilingual file. You have two options for making corrections:
- Switch between the QA tool and OmegaT to make corrections in OmegaT. This is the most reliable, yet the least efficient method.
- If you check a TMX file: close the project in OmegaT, make corrections directly in the QA tool, and then import the updated TMX back into the project. You can do so by saving it as “project_save.tmx,” thus overwriting the old “project_save.tmx.” Or you can put it into the “/tm/enforce subfolder” to force OmegaT to overwrite translations in the old “project_save.tmx” with the translations in this file (make sure to remove it after opening the project in OmegaT, or else these translations will keep overwriting any changes that you make afterwards). This approach doesn’t work for team projects, though.
You can use various external tools to perform QA on OmegaT projects. Our experience of using OmegaT for English to Russian translations on a day-to-day basis shows that the quality of QA performed within these projects is just as high as that with other translation environment tools that provide built-in capabilities.
Thank you for reading. If this blog post helped you, you can help us in return—take a few seconds to share a link to it on your site or social media profile using the button below.