Repository navigation
Feature request: translatable event-log / webhook messages (backend i18n) #49
Description
Following up on PR #48 (Italian UI + manual): the frontend i18n covers UI labels and the manual, but event-log messages, webhook messages and API messages stay English — and that is currently by design ("uniformly English … keeps analysis and monitoring consistent").
We'd like to propose making event messages translatable too, and would be happy to implement it if you'd like to have it. Writing this up first because it's an architectural decision, not something a dictionary file can solve.
Why frontend i18n can't do it
Event strings are produced in the backend and persisted — e.g. db.log_event("Configuration saved", "", db.INFO) writes the final English text into events.db. By the time the UI displays them they are opaque strings; there is no key to look up.
Possible approaches
- Stable event keys + parameters — log
("config_saved", {})instead of"Configuration saved", translate at render time in the UI's language (and for webhooks/API, decide a language policy: English always, or a per-webhook language option).- Pros: one source of truth, all languages handled the same way, historical rows could even be rendered in new languages.
- Cons: every
log_eventcall site changes; payloads (detailstrings often embed dynamic values) need parameterization.
- Keep storing English, translate at display time by matching — fragile, effectively parsing English. Not recommended, mentioned for completeness.
- Structured storage — store
key + params JSONin a new column, keep the English text column for compatibility/rendering where no translation exists.
Historical events would presumably stay English either way (unless rendered from keys for new rows only — which is fine).
Questions for you
- Is localized event text something you'd want at all, or do you prefer the current "always English" consistency for monitoring/parsing?
- If yes: translate only in the UI display, or also let webhooks emit a chosen language per target?
- Any preference on the approaches above (or another design)?
Happy to do the implementation work — including keeping test_i18n-style parity guarantees — once there's an agreed direction.
Activity
ffind-dev commentedon Oct 22, 2026
Thanks a lot for writing this up before coding it. That was exactly the right call, and the analysis of the options is spot on (and thanks again for the Italian UI in #48).
I've thought it through and I'd like to keep the backend English, so I'm going to close this as "not planned" for now.
My reasons:
If you'd like localized notifications today, the Custom webhook format already gets you most of the way. You write the message frame in your own language and pull in {{severity}}, {{facts}}, {{facts_json}} or {{status_json}} for the values. The event subject itself stays English.
If there's ever broader demand, I agree your option 3 (key + params stored next to the English text) would be the right foundation, since it stays backward compatible. I'm not planning it at the moment, though. Thanks again for the offer to implement it!