Every label, description and error in this integration's UI renders
untranslated in a live Home Assistant. homeassistant.helpers.translation
loads `<integration>/translations/<lang>.json` and nothing else (there is
no fallback to strings.json -- see translation.py's
`integration.file_path / "translations" / file_name`), and this component
has no translations/ directory at all.
Core integrations get away with shipping only strings.json because core
generates translations/ as a release step, resolving the `[%key:...%]`
references strings.json uses to avoid duplicating text. Vendoring the
source tree copies the input and leaves out the generated output, so the
defect arrived with commit 48195c9 and would hit anyone who installs
this from HACS.
Rather than hand-write the file once and let it rot on the next upstream
re-sync, scripts/generate_translations.py regenerates it:
- `common::...` references resolve against the *installed* homeassistant
package's own strings.json, so the text matches what core would have
produced for that HA version.
- `component::openai_compatible::...` self-references resolve against
strings.json itself, repeatedly, since a reference can point at another
reference.
- Anything it cannot resolve (an unknown namespace, a reference to a
different integration, a path that does not exist, a marker surviving
the final pass) is a hard error rather than a raw `[%key:...%]` marker
shipped into a label.
All 70 references in strings.json resolve; the generated file carries
config, config_subentries, exceptions, issues, selector and services.
tests/test_translations.py locks it down: en.json must exist, must equal
what the generator produces, and must contain no surviving markers.
Verified the check actually catches drift rather than passing vacuously
-- perturbing one label fails it, and deleting the file fails it.
Local: 141 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
