glossary-violation: glossary term translated or altered

error — fails the build

A term your glossary declares do-not-translate (a product name, "OAuth", "webhook") was translated anyway — or a term with one locked translation per language came back as something else. This is a deterministic string check: no model involved.

What triggers it

// glossary.json: { "Shipi18n": { "dnt": true } }
// es.json
{ "tagline": "EnvíoI18n comprueba tus traducciones" }

Fixed

{ "tagline": "Shipi18n comprueba tus traducciones" }

Why it matters

A translated product name is a brand bug every native speaker notices instantly, and locked terminology is often a legal or contractual requirement.

How to fix it

Restore the exact term. Keep the glossary file in the repo (--glossary glossary.json) so every future check and translation enforces it.

How to silence it

Remove or adjust the term's entry in the glossary file — the glossary is the source of intent here, not --ignore-keys.

Check for this in CI

npx @shipi18n/cli check ./locales -s en
# SARIF for inline PR annotations:
npx @shipi18n/cli check ./locales -s en -r sarif -o shipi18n.sarif

The structural checks need no API key. Findings of this rule link back to this page from the SARIF helpUri.

Related rules

• untranslated — untranslated strings identical to the source
• semantic-mistranslation — translation says something different from the source