Skip to main content
TextSetu runs automatic quality checks as you translate, flagging likely mistakes before they ship. QA warnings appear right in the editor on the Translations grid, so issues are caught at the moment of editing rather than in a separate pass.

​
What QA checks for

QA covers two broad categories:

​
Structural / technical checks

These catch issues that would break the app or read as obviously wrong:
  • Placeholder mismatches — variables/placeholders present in the source but missing, altered, or extra in the translation (e.g. {count}, %s, {{name}}).
  • Markup / tag mismatches — HTML or formatting tags that don’t line up with the source.
  • Empty or whitespace-only values where text is expected.
  • Leading/trailing whitespace and similar formatting slips.

​
Terminology checks (glossary-driven)

When a glossary applies to the project:
  • Forbidden terms — using a term marked forbidden (e.g. “Cart” when “Bag” is required) is flagged, with the preferred term suggested.
  • Do-not-translate terms — terms that must stay in the source language are flagged if they were translated or altered.

​
How warnings appear

  • The cell you’re editing surfaces a warning when a check fails.
  • The warning explains the problem and, where possible, the fix (e.g. the correct term to use).
  • QA is advisory by default — it guides translators without blocking — and pairs with the approval workflow so reviewers can act on anything that slips through.
Configurable severity. Glossary-driven checks (term consistency, forbidden terms) have a severity you set per glossary in Settings → QA Checks: Off, Warning (highlights the cell), or Error (blocks saving). Those toggles save automatically. Project-level structural checks are enabled with the QA checks switch in the project’s Settings → Translation Workflow.

​
Why it matters

  • Placeholder bugs are among the most common localization defects — a dropped {count} can crash a screen. QA catches them automatically.
  • Terminology consistency is enforced continuously instead of relying on every translator remembering every rule.

​
Working with QA

  • Keep your glossary up to date — most terminology QA value comes from well-maintained do-not-translate and forbidden lists.
  • Fix structural warnings before submitting; they almost always indicate a real problem.
  • Use the approval workflow as a second line of defense for anything QA can’t detect (tone, meaning, nuance).
Related: Glossary · Translating · Approval Workflow