secret-detected: a secret or PII sitting in a locale string

error — fails the build

A locale string contains what looks like an API key, private key, JWT, credit-card number (Luhn-checked), email or phone. Surfaced by `check --detect-secrets`. Detection is precision-biased — known key prefixes, example/test emails ignored, phones require a country code — and the matched value is always masked in the report, never echoed.

What triggers it

// es.json
{ "help": "Usa la clave sk-ant-api03-XXXXXXXXXXXXXXXX para conectar" }

Fixed

// es.json — no secret in the string
{ "help": "Introduce tu clave de API en los ajustes" }

Why it matters

Secrets do not belong in locale files: they get committed, shipped to the client, and translated by whatever produced the file. A card number or email is a privacy leak the same way.

How to fix it

Remove the secret from the string and load it from the environment or config instead. Rotate anything that was already committed.

How to silence it

Off unless you pass --detect-secrets. Tune with --severity secret-detected=warning, or --ignore-keys for a false positive.

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

• secret-preflight — string withheld from the LLM because it held a secret