Using german number format

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.

On Windows you canā€¦

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. :slight_smile:

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

image

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.

1 Like

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:


If defaults are not working for you, there is always option to properly custimize settings to your liking. This simple dialog resolves all the issues that are discussed in countless threads regarding HA configuration :frowning:

Irish people might object that statement :wink:

:slight_smile: 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

image

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?