When using templates to build strings, we now have the function state_translated() to translate sensor values like “on”, “off”, or “above horizon”, etc. into the language that the system is setup for.
But such a function is missing for localization of sensor values that are floats with decimals.
I.e. 10.23 should be 10,23 in German.
It is also missing for date-time values.
I.e. 10/23/2024 should be 23.10.2024 in German.
While for simple template sensors this conversion is perfectly done in the frontend, a translation/localization functions is needed when we concatenate more complex texts in templates. See the following example that uses a template with a concatenated string:
Side note:
I am actually not sure whether this feature request would really need a dedicated function, or whether it could be integrated into state_translated(). Maybe an extended state_translated could act on the type of value (text, float, date-time) and could use the right translation/localization algorithm automatically.
Yeah, this topic in general is a bit lacking support from HA. It’s like everything is using English/US localization. For example, state_translated only works on, well, states. This means it doesn’t work with the get forecasts service, which now has to be used instead of states/attributes of weather entities.
For the decimals I’m using template filter | replace('.',','). But yeah, it’s a bit of a hack.
You mean 10:23?
Generally when you have a decimal in timevalues like that it’s because you have made the clock base 100. So you make 5 minutes 0.08.
But to me that looks like you could do that with a simple replace.
Not sure what the benefit is of making a new localization vs just a replace.
Edit.
You mean 10.23 as in a value, not time?
Sorry misread it.
The benefit is that a proper localization function would
a) make some checks to make sure the original value is using the specific formatting. Simple replace filter would fail if the original value was something not expected.
b) would be able to handle various cases, with various languages, automatically. For example, american date format is not just different characters, but switching date and month around.
c) it would be easier to use for end users.
It’s necessary for TTS, because otherwise my TTS tells me today’s max temperature will be January 22nd (that’s how it understands 22.1).
Could it be that values in the images in the first post as text and not values?
In that case it can’t replace the dots.
In that case it’s an integration “issue”
While for simple template sensors this conversion is done in the frontend, a translation/localization functions is needed when we compile more complex texts in templates, like in this example:
In other words, this is not about displaying sensor in frontend - that’s already covered by HA. It’s about doing anything with the value in templates.
