is there an easyier way to get dots as thausend seperatos and comma as decimal seperator?
Can i change that for all numbers ins Home Assistant like a global config? At the moment i replace them. But that doesn:t work for the internal weather forecast.
value_template: '{{ states.switch.pv_anlage.attributes["total_consumption"] | float | round(2) | replace(",", "@") | replace(".", ",") | replace("@", ".") }}'
Wondering the same thing. Would be cool if we can configure some localisation, number, ate, etc. formats.
any updates or solutions ?
It is really time consuming that this does not really work for all those custom cards etc.
Number formatting is controlled by the language you specify for your user in HA.
If the actual question is: Can we use English with comma decimal point (amongst other), Iām afraid not.
Picking up this old topic. Any solution in sight? This is a real pain, as it was in the old 8-bit aera, where some developers thought a country or location is enough to be defined.
āroundā and others are still pretty useless if garbling the visual representation if one sticks to english lang for the sake to not get lost at all on the frontend while on the other end one suffers from a complete mixture of number represenations. Some mostly official cards seems to rely upon the region settings others (mostly custom cards) on the language settings.
And yes I di like the snapshot from windows by aceindy, at least 1 point where itās away ahead against home assistant. 
Nevertheless if HA heads for a year of (multilingual) voice Iād really ask to not forget about the ugly visuals since most users likely have a look more often but talking to the device.
I would really like this to get fixed.
To me it is also quite annoying not being able to correctly send notifications in German number format in my automations.
Thatās been implemented like 2 years ago
Yes if one digs deeper one realises that it was poorly implemented.
Itās split into the user setup which would be ok, if only the currency setup would be user bound aswell. Since at the moment one canāt make much use from the fact that some settings are userdriven, since if trying to make use of them you end up with a complete mixed up result.
Currency is not about user preference, really.
Your HA runs in an environment/country/region using (usually) a single currency. Thatās a system setting.
You āmightā have users on your HA having different preferences regarding language and/or number/time formatting. Those are user settings.
It depends about how you look at it. Assume my kid is abroad for about a year. Lets say from an origin Germany ==> ā¬ being the currency, ā,ā being the delimited on numbers.
Mixing up the numberformat since user driven while the currency remains is simply free from sense.
If the user is abroad and wants to change his view to match the local standard heāll get 10.1 ā¬ in the US? Means being able to turn the comma into a dot but he has to keep ā¬ which is a pretty uncommon payment method there? Funny idea.
Thatās why clever systems allow for so called āinternational settingsā which not only cares about the number format but also currency, time/location, sorting and such like.
The visualisation langauge of the system running is some which ought to be bound to the system but thatās a differnt story and the sole things which should belong to the system.
Currency is something which ought to be user driven.
But well one must dig hard to find out the snippets where even MS Windows is ahead of HA but this is a vital one.
Currency is just about the sign. It doesnāt do any conversion so 10.1 EUR is not the same as 10.1 USD, so you definitely donāt want the currency to change.
I know but 10.1 ā¬ isnāt a valid amount of currency either, since here it ought to be 10,1 ā¬
Means numberformat and currency have to match, that simply. It not possible, no problem, canāt name a 100% free from fault software anyway.
In the end itās all about localisation. Doing sort of cherry picking on items which ones belong to the system and which ones to the user simply fails in the end, Believe it or not.
From this perspective I musty admitt there is one thing I love Windows for:
Irish people might object that statement 
sure ā¦ which results in ā¦ it doesnāt fit all as currently implemented. no more no less.And with the currently implementation thereās no solution possible.
Why so? It evades me why you find it unfitting.
Even windows doesnāt mix currency with number / time formats
Unifying is badā¦ Looking at this from different angele; Iām Polish, but Polish language is not well suited for computer operationā¦ We miss short, descriptive words for this and either borrow them from English (which sound bad) or use real Polish alternatives (that sounds unnatural). So for this reason many people prefer to use English interfaceā¦ but yet use Polish for verbal communication like in TTS. So same dilema as you described here is for Voice Assist, which assumes the same language as for interface. Many companies already recognized such need and for example many good navigation systems separate interface language from spoken directives language. Same for measurements units. Forcing consistency is not good for usersā¦ though I understand simpler for developers.
Where.do.you.see.forcing?
You can choose, independently, the language, number format, time format, 1st day of week and currency. How would you want more flexibility.
Show me, please, where I can select space for number grouping and dot for the decimal separation.
Show me, how I can have English as interface language and have Polish for Assistant conversation.
Finally, how we can achieve what original poster is asking for?
