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
The LAN-address scrub replaced 10.10.70.133 with litellm.local in
strings.json, which broke the hassfest job that had been green:
[ERROR] [TRANSLATIONS] Invalid strings.json: the string should not
contain URLs, please use description placeholders instead at
'config.step.user.data_description.base_url'
The rule is not new -- the previous text was equally a URL. It slipped
through because script/hassfest/translations.py's RE_URL requires an
alphabetic TLD ([a-z]{2,5}), so "http://10.10.70.133:4000/v1" never
matched (".133" is not alphabetic) while "http://litellm.local:4000/v1"
does. Verified by running core's actual regex against both strings, so
the scrub did not introduce a violation so much as stop hiding one.
Rather than wire up a description placeholder for what is only an
example, the description now describes the field without any URL:
concrete endpoint examples live in the README, which has no such
constraint. The reauth_confirm step picks this up automatically -- it
references the user step's strings via [%key:...%] rather than copying
them.
Also re-ran core's RE_URL over every string in strings.json, not just
the one hassfest named: 0 remaining violations, so this should not
bounce again on a second string.
Local: 138 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NxJYWgGJtCw13qUHZtG8ki
