fix(i18n): translate empty-value labels in reports (v1.39.1)

[iscarelli]

The bug

Three empty-value labels in the reports were shown in Portuguese to every user, including those browsing in English or Spanish:

Where	Label leaked
Consumption History → by material	(sem material)
Consumption History → by brand	(sem marca)
Stock by Location	(sem local)

(sem marca) / (sem material) shipped in v1.39.0; (sem local) had been leaking for much longer.

Why they escaped _()

Not an oversight at the call site — they were born in the wrong layer. database.py stamped the finished label straight into the data:

COALESCE(NULLIF(s.location,''), '(sem local)')   # report_by_location()
_breakdown("brand", "(sem marca)")               # consumption_report()

Translation in this project is a string lookup performed in the template. A label that arrives already rendered has nothing left to look up, so it passes through untouched no matter what language is selected.

The fix moves the decision to the layer that owns presentation. The data layer returns an empty string; the template picks the label.

Why _() wraps the literal and never the data

The tempting one-liner, {{ _(row.name) }}, is itself a bug — and avoiding it is the whole point of this PR.

Brand, material and location are free text typed by the user. translations.py is a plain dict keyed by Portuguese source strings, so any user value that happens to collide with a key gets silently rewritten. A real brand named Preço would render as "Price" in English. There is no guard against this, because a lookup table cannot tell a label from a coincidence.

So _() may only wrap the literal, and only on the branch where the value is empty:

{{ r.name if r.name else _('(sem marca)') }}

This is also why the _()-over-a-variable calls in templates/reports/stats.html:12 and templates/spools/list.html:10 are left alone: those translate the colour family, a closed vocabulary produced by database.classify_color (Preto/Branco/Cinza/…), not user input. The rule is not "never _() a variable" — it is "never _() free user data".

Tests

Both halves are pinned, so neither bug can come back quietly:

• the label is translated in EN and ES on both reports;
• test_real_location_matching_a_translation_key_is_never_translated and its brand twin create a real value that collides with a translation key (Tudo → "All time", Preço → "Price") and assert it renders unchanged.

I verified these tests are not blind by reintroducing both bugs in the template — 3 tests fail, then pass again once reverted.

The HTTP assertions anchor on text unique to the target page body (Consumed (kg), Stock by Location). This matters here: the bootstrap admin carries must_change_password=1, so every route silently 302s to /account/password, which renders the nav and returns 200 — a naive "is the text there?" check would pass against the wrong page.

249 passed (was 239).

Side effect, an improvement

GET /api/stock stopped emitting a Portuguese UI label into machine-read JSON (Home Assistant consumes this). An unset location is now "" instead of "(sem local)". Noted in the changelog since it is visible to integrations. No documented contract pinned the old literal.

Also

• docs/ARMADILHAS.md gets the trap in the same commit, per project rule, including the sister sweep and the note about which _()-on-variable calls are legitimate.
• VERSION → 1.39.1 (translation fix = PATCH), with the changelog entry in the same commit.

---

🤖 Generated with Claude Code