This post continues a series of articles that I started to compare QA Distiller and Verifika. Previously, I covered the QA Distiller’s advantages and areas for improvement. Now it’s time to look at Verifika more closely and proceed with the actual comparison. In this article, I’ll focus on Verifika’s advantages. The versions I’ll review are QAD 8.5.0 and Verifika 1.6.
Just as QAD, Verifika is a tool that detects potential errors in a bilingual file or translation memory. It’s capable of finding formatting, consistency, terminology, and spelling errors, presenting all findings in an intuitive, easy-to-use interface and making it possible to correct the translations directly from within that interface.
- I like the look and feel of Verifika more than that of QA Distiller 8.5. I think it looks more modern. When you use a QA tool a lot in the course of a day, even smaller things like this make a difference.
- Verifika supports more file formats than QAD. For instance, it also processes Wordfast Pro TXML files or bilingual MS Word files.
- Since the version 1.6, Verifika offers a floating license just as QAD does. The initial price of Verifika is cheaper, though. A Freelance floating license is €135 vs €249 for QAD. However, QAD’s upgrades are free while an upgrade for Verifika Freelance will cost €35 for one year.
More specific advantages
Verifika has an integrated spell checker. This is a huge advantage, to put it mildly. Since QA Distiller doesn’t have a built-in spell checker, we have to check spelling in a separate program, which is far from effective. This advantage alone can save us a few hours per week. Bottom line: time savings.
Spaces around tags
Verifika is able to detect potentially incorrect spaces around tags. This helps find words glued together and multiple spaces. QAD doesn’t offer this feature. Bottom line: higher quality of translation.
With some of the error types, Verifika makes suggestion for editing. You can apply the suggested auto-correction by simply pressing Alt+A. QAD doesn’t offer this feature.
The value of auto-correction is limited, though, since making the changes in the QA program rather than in the actual translation memory program isn’t always practical. You can’t see the context, which is, for instance, the case with the OmegaT translation memory files. This feature is also useless when you’re editing a translation, adding your suggestions as notes rather than implementing them right away.
Anyway, to make the most out of this promising feature, I think that we should try using it whenever it’s practical to do so. Of course, it’s important to close the project in the original translation program before making any changes in Verifika. Bottom line: time savings.
With QAD, we have to load a glossary with general words that represent a high risk of translation errors manually for each QA session. But in Verifika, we can add this glossary to a set of options, or profile, and it will load automatically whenever we choose that profile. Bottom line: time savings.
Since QAD doesn’t support the tab-delimited text glossaries, we have to convert our TXT glossaries to its internal format, DICT, each time we run QA. Verifika does support the tab-delimited text glossaries, thereby eliminating the additional conversion step for us. Bottom line: time savings.
So far Verifika looks extremely attractive. The time savings are very promising. Next time, I will look at a few other advantages Verifika has in terms of checking terminology.
Thank you for reading this article. In fact, I’m new to Verifika and might be wrong in my assumptions. If you have anything to add or want to correct me, your comments are more than welcome.