Glossary Exact Match Check

When a glossary is supplied, LocaleQA checks whether each configured source term appears in source text and whether the required target term appears in the matching target text.

Use this when product vocabulary, client terminology, or support documentation depends on exact terms rather than near synonyms.

The report shows the JSON path, the source glossary term that triggered the rule, and the required target term that was not found.

The report gives PMs and vendors a specific terminology item to fix before client review. Developers benefit when UI terms stay aligned with docs, support, and product naming.

Exact glossary matching can be too strict when a language requires inflection, spacing changes, honorific treatment, or context-specific wording. It can also flag acceptable variants if the glossary itself is incomplete.

Disable this rule when the project uses flexible terminology review outside LocaleQA. Keep it enabled for client-mandated terms, UI labels that must match documentation, and Japanese style guides where exact katakana or product term handling is required.

LocaleQA reports the affected JSON path, the source and target values involved, and the rule that triggered the finding. Developers, localization PMs, vendors, and QA reviewers can use that as a specific file-level item to fix, approve, or discuss before release.

Some findings are valid exceptions. A migration file, documented style choice, or locale-specific convention may explain the difference. In those cases, teams can leave the string as-is or disable the check for that scan.

LocaleQA is JSON file QA. It does not judge wording or rewrite translations; it surfaces the file issue so the responsible owner can decide the right fix.