Allow overriding the translated home state globally #4559
Unanswered
nicknol
asked this question in
Core functionality
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Describe your core improvement
Provide a supported, centralized way to override the display text of common entity states, at least for the home state.
For example, a configuration such as:
homeassistant:
state_labels:
home: "Sweet Home"
or an equivalent UI/configuration mechanism would allow:
internal state: home
displayed state: Sweet Home
The internal state must remain home, so existing automations and integrations continue to work unchanged.
Requirements
The solution should:
keep the actual state as home;
affect the displayed state only;
be centrally configurable;
apply to all relevant entities using the common home state;
not require template sensors;
not require changing every entity individually;
not require modifying Core or frontend translation files;
survive Home Assistant updates.
Current limitations
For device_tracker entities, the internal state is home when the tracked device is connected to the home network.
In the German UI, this state is displayed as „Zuhause“.
The current implementation uses the common translated state:
device_tracker
→ common::state::home
→ localized translation
This means that the displayed text is globally determined by Home Assistant's translation and cannot currently be customized by the user.
The Home name setting does not change this displayed state. It is therefore not possible to use a custom name such as „Sweet Home“ for the displayed home state of device trackers.
Technical benefits
No frontend tricks and templates needed to display the wanted Home name.
Additional context
Example use case
A user may want the German UI to display:
Wohnzimmer-Telefon
Sweet Home
instead of:
Wohnzimmer-Telefon
Zuhause
while the actual entity state remains:
home
This would also be useful for users who want terminology different from the built-in translations without having to maintain custom frontend modifications.
All reactions