Currenly template sensors render values based on a std python environment, i.e. for datetime objects
{{now().strftime("%h")}} renders as June, {{ now().strftime("%a")}}, renders as Tue etc.
Wouldn’t it be better to use the locale settings from the user interface?
It is because it is running in the jinja2 engine, not the HA, so that is why. I don’t know what you ask is possible without rewriting Jinja.
So I would guess highly unlikely, but not impossible. You would be better off creating and sharing a custom_template macro that could do this or something, don’t know.
Yes, custom templates do the job fine, however using them makes providing multiligual contexts hard - you’re basically hardcoding your locale, with no elegant way for a user to change it. There are HACS components that implement translation with an optional language/locale argument, but I think this should be native in HA. It is very likely if a user has set his preferred language for the UI that he expects entity states and attributes to be in the same language.
It’s because the datetime objects that are available in jinja come from the python datetime library. Which is set to english.
Here’s the main reasons why this is unlikely to happen with the dt.strftime() function.
If this FR ever comes to fruition, it will be a new function that utilizes HA’s translations. Something like the new states_translated function. e.g. stftime_translated.
It will still be hardcoded. The current system is like that. The problem you aren’t thinking about is that each user can have their own language. So what language would you use when translating in a template, which has no concept of a current user.
in python, if you import locale and call locale.setlocale you get ‘translated’ output from dt.strftime().
Yes, but then all the integrations in python that use strptime will break as well. That’s why it’s not an option to go this route.
The change 100% cannot occur in the datetime library. There’s is no discussion around this. It will be a separate function if it’s ever implemented with translations.
this is exactly the problem I’m raising - a multi-lingual HA setup where each user has their own language of choice. UI gets translated, but using output form i.e. now().strfrime() is stuck with English. A custom_template will hardcode to one other language, which is not an elegant solution.
Right, now().strptime or strftime will forever be stuck in English. Any additional functions added to the template engine only may have translations applied, however it will only be the language set in general settings. It will not be tied to the language of the logged in user.
I thank you for your patience and effort to explain it, but unfortunately I don’t see why:
from datetime import datetime
import locale
# Set French locale
locale.setlocale(locale.LC_TIME, 'fr_FR')
# Locale-specific date format
datetime_string = "15 Janvier 2024"
datetime_object = datetime.strptime(datetime_string, "%d %B %Y")
print(datetime_object)
# Output: 2024-01-15 00:00:00
example taken from learnbyexample.org
my man, you aren’t reading what I’m writing.
If you change the locale for the datetime library, it will break ANY integration that uses the datetime library to create datetime objects from strings. 99% of APIs are in english. This would break the entire system for just about every integration that uses strptime.
I have no idea why you’re dying on this hill. You don’t need to use strptime or stftime if a separate function exists that does the same thing. Yet you keep focusing on it being applied to the object.
The syntax would likely be very similiar.
e.g.
{{ now() | strftime_translated(...) }}
Does it really matter that it’s not {{ now().stftime(...) }}?
Right, I guess I understand why strftime/strptime are not an option. I was not aware of the existance of strftime_translated, reading your previous post I assumed it was still a work in progress…
it does not exist, I’m giving you an example of what it could be. I really don’t think you’re reading my responses.
I’m reading, maybe I’m not understanding them, but again - thank you for helping with that.
Probably a better way to position the feature request would be ‘provide a way for templates to render translated values based on the user-selected locale setting’. I was never implying to how to implement it, the examples with strftime were just to illustrate the issue. Any suggestion how to overcome this issue would be more than welcome.
In the end here you have had over 60 people read this and have 0 votes.
You won’t even vote for it.
It has little chance technically or by popular demand…