fix(trmnl): render the panel in German via the schedule's lang field #488

Merged
k.renner merged 1 commits from fix-trmnl-render-lang into master 2026-08-12 20:18:59 +00:00
Member

lang was null, so the screenshot session rendered in English — and the dashboard grew a German weekday array, a German month array and a fifteen-entry weather-condition dict to translate around it by hand.

The field is documented as "UI language code (HA mode only)" and calls Home Assistant's own _selectLanguage() on the page before capture. Upstream's own tests use lang: 'de'.

So localisation is HA's job, and the field was sitting in the schedule template I wrote — already spelled out, set to null because I copied the shape without asking what it did.

Pairs with homeassistant#220, which deletes both hand-written mappings:

  • the weather badge points at weather.garten directly; the frontend localises the state, so sensor.trmnl_wetter and its dict are gone
  • the date is a device_class: timestamp the frontend formats, so the weekday and month arrays are gone

The instance stays language: en. This affects only the render session, so the panel is German without changing anyone's UI.

The pattern

Same failure as the rest of this build, and the most avoidable instance of it: I had already read this field list — it's how I learned theme, dithering and viewport — and reimplemented in config what one adjacent field does natively.

🤖 Generated with Claude Code

`lang` was `null`, so the screenshot session rendered in English — and the dashboard grew a **German weekday array, a German month array and a fifteen-entry weather-condition dict** to translate around it by hand. The field is documented as *"UI language code (HA mode only)"* and calls Home Assistant's own `_selectLanguage()` on the page before capture. Upstream's own tests use `lang: 'de'`. So localisation is HA's job, and the field was sitting in the schedule template I wrote — already spelled out, set to `null` because I copied the shape without asking what it did. Pairs with **homeassistant#220**, which deletes both hand-written mappings: - the weather badge points at `weather.garten` directly; the frontend localises the state, so `sensor.trmnl_wetter` and its dict are gone - the date is a `device_class: timestamp` the frontend formats, so the weekday and month arrays are gone **The instance stays `language: en`.** This affects only the render session, so the panel is German without changing anyone's UI. ## The pattern Same failure as the rest of this build, and the most avoidable instance of it: I had already read this field list — it's how I learned `theme`, `dithering` and `viewport` — and reimplemented in config what one adjacent field does natively. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-08-12 20:16:57 +00:00
fix(trmnl): render the panel in German via the schedule's lang field
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
f8c968c5a7
lang was null, so the screenshot session rendered in English — and the
dashboard grew a German weekday array, a German month array and a
fifteen-entry weather-condition dict to translate around it by hand.

The field is documented as "UI language code (HA mode only)" and calls
Home Assistant's own _selectLanguage() on the page before capture;
upstream's tests use lang: 'de'. So localisation is HA's job and the
field was sitting in the schedule template, already written out, set to
null because I copied the shape without asking what it did.

Pairs with homeassistant#220, which deletes both hand-written mappings:
the weather badge points at weather.garten directly and the date is a
device_class: timestamp the frontend formats.

The instance stays language "en". This affects only the render session,
so the panel is German without changing anyone's UI.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
k.renner merged commit b2ed2beae4 into master 2026-08-12 20:18:59 +00:00
review-bot left a comment
Member

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit f8c968c5a7cd122e69500be5da7e4e35fec2d4e3.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.


Summary

This PR sets the lang field to "de" in the TRMNL renderer's schedule configuration, delegating page localization to Home Assistant's built-in _selectLanguage() method instead of maintaining hand-written German translations. The change is correct, well-documented, and aligns with upstream patterns.

🟢 Nits

The explanatory comments (lines 32–38) are thorough and helpful — they clearly document why this field matters and what problem leaving it null caused. No changes needed; this is good documentation.

Tests

This is a configuration change rather than code, so formal tests don't apply. The PR is paired with homeassistant#220 (which removes the now-redundant hand-written translation dictionaries), suggesting this has been validated in the author's environment.

Recommendation

Looks reasonable — no blocking issues. This is a straightforward fix that correctly delegates localization to Home Assistant's native facilities.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `f8c968c5a7cd122e69500be5da7e4e35fec2d4e3`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR sets the `lang` field to `"de"` in the TRMNL renderer's schedule configuration, delegating page localization to Home Assistant's built-in `_selectLanguage()` method instead of maintaining hand-written German translations. The change is correct, well-documented, and aligns with upstream patterns. ## 🟢 Nits The explanatory comments (lines 32–38) are thorough and helpful — they clearly document why this field matters and what problem leaving it null caused. No changes needed; this is good documentation. ## Tests This is a configuration change rather than code, so formal tests don't apply. The PR is paired with homeassistant#220 (which removes the now-redundant hand-written translation dictionaries), suggesting this has been validated in the author's environment. ## Recommendation Looks reasonable — no blocking issues. This is a straightforward fix that correctly delegates localization to Home Assistant's native facilities. <!-- pr-review:sha=f8c968c5a7cd122e69500be5da7e4e35fec2d4e3 -->
Sign in to join this conversation.