Currently, it’s based on your timezone. I don’t think you can change the locale currently anyways. I was just pointing out how local works. I’m more or less stating, “we can use the locale and everyone will get what they want”.
You do not want to change the python locale. It will most likely make the python syntax fail across the board.
The main point with some of these responses is that “You shouldn’t be against using locale as a possible solution”.
Thank you, I know everyone is just trying to arrive at the best solution. The discussion is valuable.
I just hope, in the end, we don’t lose sight of the fact that this is a glaring hole in HA. Being able to set up units and formats in the UI should be a no-brainer.
My point is. My locale is Dutch-NL In the Netherlands the decimal separator is comma and thousand separator is point. I DO NOT like this. I prefer it the other way around. So when i would set my locale to NLNL i get the wrong separators. This is valid (or wrong 
) for a multitude of other settings. I would set the interface to dutch but i get a lot of things not the way i want it. I can imagine there are more situations/users who have preferences different from what is “default” for their locale… In your OS (see your own screenshot) you can also override the settings!
And this is exactly what is wrong here. Setting your locale would not give me what i want.
But it can, that’s what you aren’t understanding.
To requote myself:
Can i define my own locale? Because i’m a strange fellow and now i have to search for a matching set…
No, you cannot do that currently but this is what this WTH should strive for. Again, you aren’t understanding what me or this other guy are saying:
Base it off locale, give use the option to change said locale.
Instead, you’re saying “NO, NO LOCALE!!! I WANT TO CHANGE IT.” when this will do what you want.
Ok, maybe we are saying the same thing, but my understanding of English is just a few ticks behind… I read the wikipedia definition referred a couple of posts before:
In computing, a locale is a set of parameters that defines the user's language, region and any special variant preferences that the user wants to see in their user interface..
Then it should be implemented in a way the “any special variant preferences” can be set.
Exactly! We’re now on the same page.
Glad Yihaa!
Right now I have read the whole topic but I did not find an answer how to setup my Pi 4 running HA in docker that way that I will get right german decimals and thousand separators.
All across I see “.” as decimal separator even though I have set the Pi-4 from the beginning to Germany and german language and settings, nothing imperial.
What has to be changed on that Pi-4 cause my clients from Tablet, Phone to Laptop are running as a german version with german configuration but still from weight to kWh everything had gotten the “.” as decimal separator and I can not get that fixed this way right now.
Why does this issue still exist as it would be without interest for anyone ?
I hope you have an answer cause i wanna get rid of all the false formated figures.
thx for your support, Petro.
I was replying while your picture was uploading or so cause it appeared lot later after the text.
Well, I had set that to the preferences from the beginning and I had nothing changed, but I got all the time the wrong figures like 60.5 kg or 60.5 kWh instead of a comma.
That did not workout - even though I had chosen german and for format “Auto” cause all my system use the formats that belong to german language and germany.
Or do I have to set it manually to the desired format ?
That depends on the language file you chose, last time I checked there was multiple versions of german, but i’m not german. If it’s not showing up with ., then you should set it manually.
Petro thanks,
I guess I have found something out, but first things first:
Yes, there are “german” variants cause german is spoken in different countries from belgium, suisse to austria and northern italy and other regions that might have different versions but I had started with DE-DE on raspberry pi and I had checked it right now again that it is right. And it was right from keyboard to Wifi everything on German for germany or DE-DE.
Just to let you know: I changed the settings, I logged off and closed chrome just to start chrome and log in again to check for differences. Nothing else has been changed.
And now the fun parts begins cause here on the same page the same sensor “sensor.ble_temperature_e72e00a350c2” without any additional code shows the same number differently, but I can not really get why: WZ Temperatur BLE is the title / name and it is a Xiaomi BLE temperature and humidity sensor
On the left half you can see 23,5 °C while on the right it is the same except the “.” as decimal separator 23.5 °C
Now let’s check in the developer tool section just a minute later what we can find here:
23.4 °C for sensor.ble_temperature_e72e00a350c2
So let’s check the card code and its preview for the left half which is simply the call for the sensor sensor.ble_temperature_e72e00a350c2 in a basic entity card
Finally the code of the right half where the same sensor is used again sensor.ble_temperature_e72e00a350c2
It looks like that the only difference is simply the card templates I am using.
The Mini-Graph-Card does not seem to treat the numbers right in my opinion or is not supporting them as intended.
And I guess that would also mean that all my decimal and thousands separator errors are caused by additional / custom lovelace card templates cause everything else is the same.
Time to check what these templates tend to ignore cause only that can lead to figures that are not really displayed right in my opinion. But first I have to check out if this sensor page is working the same when I switch back to language settings or system settings on the client site.
If it is true that all the troubles are caused by the cards and lovelace templates it would be time to find a guide how those templates have to look like that they will work right out of the box regarding decimals and separators.
thx a lot - I will post a reply regarding client settings later.
UPDATE: auto settings (language), system settings and manual selection of number template (1.234.567,89) did work out the same way, the entity template did it right, the mini graph card did it not.
The settings will only apply to built in cards, not custom. It’s up to the custom card builders to add numerical and time variants.
But the card makers have access to those settings and it should be for all those the same solution be possible cause the current results are a nightmare to get behind and to fix it if even possible for endusers.
And then all the card makers should mention if they do support the internationally settings or not cause I would stay away from all the stuff that is not working or following international conventions / standards.
Do you know a guide how to implement such internationalization features into such card template cause I am working together with a developer on a card template for scales where kcal (thousand separators) and 2 or 3 decimal digits are required in the right way cause we are from different countries with even different domestic preferences ?
thx a lot
Yes they do, but custom solutions are custom. It’s up to the developer to add the functionality. No one can force them.
I do not, I’ve never worked on the frontend.
depends on “force” cause right now developer who have not used version numbers are forced to add them or their code will be depreciated - at least I got 3 or 4 such message sind early June so I had written to those developers to simply add such requirements cause otherwise their solution would be depreciated which is close to a ban.
And to be honest I would also prefer a standard which would be offered for all the front end developers to get a unification into that topic like in the release number that have now become mandatory. But time will tell when this will become mandatory too just to reduce the risks.
thx
That’s backend work that ties directly to the core. Completely different scenario and nothing to do with the frontend, which is a different code base.
Nothing in the frontend is mandatory and it most likely won’t ever have any mandatory requirements unless it has to do with system security.
