semantic-mistranslation: translation says something different from the source

warning — advisory, exit 0

The LLM judge (three passes, majority vote) found the translation stating something materially different from the source — up to and including the exact opposite. This is the class of bug no structural check can see: every key present, every placeholder intact, meaning inverted.

What triggers it

// en.json
{ "saved": "Your changes were saved successfully." }

// es.json
{ "saved": "No se pudieron guardar tus cambios." }   // "could not be saved"

Fixed

{ "saved": "Tus cambios se guardaron correctamente." }

Why it matters

A fluent wrong translation reads perfectly and tells your users something false. Findings are advisory by default — they warn without failing the build — because a noisy gate is a gate teams turn off.

How to fix it

Fix the translation (or retranslate the key). If you believe the judge is wrong, re-run: verdicts are majority-voted and cached per pair.

How to silence it

Advisory by default (exit 0). Escalate to build-failing with --semantic-fail; silence a key with --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

• semantic-omission — translation drops part of the source meaning
• semantic-addition — translation adds claims the source doesn't make
• glossary-violation — glossary term translated or altered