> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textsetu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Quality Checks (QA)

> Automatic checks that flag likely translation mistakes before they ship.

TextSetu runs automatic **quality checks** as you translate, flagging likely
mistakes before they ship. QA warnings appear right in the editor on the
[Translations](/docs/guides/translating) 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](/docs/guides/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](/docs/guides/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](/docs/guides/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](/docs/guides/approval-workflow) as a second line of defense
  for anything QA can't detect (tone, meaning, nuance).

***

Related: [Glossary](/docs/guides/glossary) · [Translating](/docs/guides/translating) · [Approval Workflow](/docs/guides/approval-workflow)