Compare
TMS QA checks and in-context QA solve different problems
Your TMS QA module validates strings against rules. Loqalit validates the rendered product. Here’s which error types each catches, and why you need both layers.
What TMS QA checks are good at
Modern TMS platforms ship solid automated QA. Typically they will catch:
Missing or empty translations
Inconsistent translations of the same source segment
Terminology violations against a connected glossary
Placeholder and variable mismatches
Number, date, and formatting discrepancies against the source
Length limits, where a character limit was declared
Spelling and basic grammar
This is genuinely valuable, it runs automatically, and it costs you nothing extra. If you are not using it, turn it on before you evaluate anything else.
Where the layer ends
Every check in that list operates on the segment, comparing it against the source or a rule. That design has a hard boundary: it cannot evaluate anything that only exists after rendering.
Which means it does not catch:
Text that fits the declared character limit but still overflows the actual button, because the limit was estimated and the font is wider in that script
Truncation and clipping at specific viewports
Layout breaking, overlap, misalignment, horizontal scroll introduced by longer text
RTL mirroring errors
A translation that is correct for the segment but wrong for the UI element it labels
Terminology that matches the glossary but contradicts the label on the adjacent screen
Source-language strings hardcoded in the build and never sent to the TMS at all
That last one is worth pausing on. Anything that never entered your TMS cannot be checked by your TMS. Hardcoded strings, third-party widget text, error states, image text, these are among the most commonly shipped localization defects, and they are invisible to string-level QA by definition.
The two layers side by side
Error type | TMS QA | Loqalit |
|---|---|---|
Missing translations | Yes | Yes |
Terminology vs glossary | Yes | Yes |
Placeholder mismatches | Yes | Yes |
Text overflow in the rendered UI | No | Yes |
Truncation and clipping | No | Yes |
Layout breaks and overlap | No | Yes |
RTL mirroring errors | No | Yes |
Context-wrong but segment-correct translations | No | Yes |
Cross-screen terminology conflicts | No | Yes |
Hardcoded / untranslated strings in the build | No | Yes |
MQM-scored severity across the product | No | Yes |
How they work together
Loqalit integrates with Crowdin and Phrase, so findings can flow back into the workflow where the fix happens. Your TMS remains the system of record for translation. Loqalit becomes the verification layer between translated and shipped.
The mental model that works: your TMS checks the text you sent it. Loqalit checks the product your users get.
Frequently asked questions
Isn’t my TMS’s built-in QA module enough?
TMS QA checks are valuable and you should have them switched on. They catch missing translations, terminology violations against a glossary, placeholder mismatches, and formatting discrepancies. But every one of those checks operates on the segment, comparing it against the source or a rule, so none of them can evaluate anything that only exists after the page is rendered.
What can a TMS QA check not catch?
Text that overflows the actual button despite fitting a declared character limit, truncation and clipping at specific viewports, layout breaks and overlap, RTL mirroring errors, translations that are correct for the segment but wrong for the UI element they label, and terminology that matches the glossary but contradicts an adjacent screen. It also cannot check any string that never entered the TMS at all, hardcoded text, third-party widget copy, and image text.
Does Loqalit replace my TMS?
No. Your TMS remains the system of record for translation. Loqalit is the verification layer between translated and shipped. The two check different things: your TMS checks the text you sent it, Loqalit checks the product your users get.