Frontend: Broken numeric values formatting in 0.118

[krakers09]

Checklist

• [x] I have updated to the latest available Home Assistant version.
• [x] I have cleared the cache of my browser.
• [x] I have tried a different browser to see if it is related to my browser.

The problem

After upgrading to 0.118 from 0.117.6 I can see that number formatting has changed. Actually it introduced thousand comma separators. For example value 1000 will now be displayed as 1,000 and 2000.45 as 2,000.45. It is still ok on Opera, but broken on Safari, Chrome, and iOS mobile app 2020.7

Expected behavior

Numeric values to be displayed without thousand comma delimiter.

Steps to reproduce

Display any numeric entity having value > 1000 in entities card.

Environment

• Home Assistant release with the issue: 0.118
• Last working Home Assistant release (if known): 0.117.6
• Browser and browser version: Safari Version 14.0.1 (16610.2.11.51.8), Chrome Version 86.0.4240.198 (Official Build) (x86_64), Opera Version:72.0.3815.320
• Operating system: macOS Big Sur 11.0.1

State of relevant entities

Problem-relevant configuration

Javascript errors shown in your browser console/inspector

Additional information

[bramkragten]

This is not a bug but a feature. Why would you not want the formatting?

[krakers09]

Why would I want something that was good, to be changed to something less readable used only sometimes in some parts of the world? It's not even always used in US/UK.

[logicup-dev]

The is no consistency for this feature:

Now that format number is related to the selected language, it's impossible to have a consistency for numbers in the frontend.

Example:

Using a entities type card in lovelace, a displayed value will be (in french) 1 234,56$ (with comma before decimals and space for thounsand)

Using a markdowm type card in lovelace, the same entity value will be now (in french again) 1234.56$ (with dot before decimals same as backend).

Using a sensor type card in lovelace, the same entity value is also (in french again) 1234.56$ (with dot before decimals same as backend).

Using a weather-forecast type card in lovelace, a value is also (in french again) 12.34$ (with dot before decimals same as backend).

Using most or maybe any custom card in lovelace, the same entity value is also (in french again) 1234.56$ (with dot before decimals same as backend).

Also the backend is using the standard old format number, that means actually there's only maybe 2 lovelace cards that are using a different format

[krakers09]

It's not consistent at all. Look at the gauge card. It displays without comma, when you click on it you have comma in the the header and no comma in history chart.

Btw. have you ever seen RAM displayed with thousand comma separator?

[bramkragten]

That is a different story, and yes it has to be implemented in more places still.

[krakers09]

So what's the point of bringing such inconsistency? It should be reverted until it's done properly. Or better should be withdrawn.

And why using HA in English forces me to use this format? Users should be able to change it at least.

[KNXBroker]

I'm neither very happy... There are so many cards (especially custom cards...) which needs this implementation. As German user the point was not 100% correct, but I had never a problem with this. Indeed, it was good that the behaviour was identical in backend and frontend. A choice next to the language setting would be perfect!

[logicup-dev]

Don't know if it's related to this new feature, but a have a template sensor written like this:

{{ '{:.2f}'.format((float(states('sensor.kwh_day_cout_reg')) * 0.0608) + (float(states('sensor.kwh_day_cout_haut')) * 0.0938) + 0.4064) }}

which is supposed to display with :.2f format example 1.30 instead of 1.3

And now the state of this template sensor is displayed like 1.3

I did the test with 0.117, template is working fine,
and in 0.118, when using the template deleloper tools, it is displaying like it's supposed to be, 1.30

[michalk-k]

this feature is incomplete. This is why it might turn into bug seen from user perspective.

Question is why you have closed the issue so fast, before getting even answer on the question you asked at the same time.

[bramkragten]

If there is a bug, it would be the places that this is not implemented yet.

[bramkragten]

Don't know if it's related to this new feature, but a have a template sensor written like this:

{{ '{:.2f}'.format((float(states('sensor.kwh_day_cout_reg')) * 0.0608) + (float(states('sensor.kwh_day_cout_haut')) * 0.0938) + 0.4064) }}

which is supposed to display with :.2f format example 1.30 instead of 1.3

And now the state of this template sensor is displayed like 1.3

I did the test with 0.117, template is working fine,
and in 0.118, when using the template deleloper tools, it is displaying like it's supposed to be, 1.30

No, this is probably because of the native type template support https://www.home-assistant.io/blog/2020/11/18/release-118/#native-types-support-for-templates

[krakers09]

The way this "feature" was implemented makes it also a bug. Inconsistent, unthought, and seems that result was not even looked at in the frontend.

[krakers09]

I find implementation of this feature better every day.

Screen from entities card

[logicup-dev]

Even though it's not considered a bug, don't you think there is a risk of a never ending story, a more complicated logic, a series of updates, corrections and discussions?
And all of this for something that was working fine. There is not a significant proportion of the usage for a big number like 123,456.91 in dashboards and changing a dot for a comma is changing a character for an another. If you want to call it a feature, the feature of number formating, please, think of MS-Excel for example, where you format number in a cell, not all around the table, and for sure, not based on the language of the OS. In some other systems the user define the "formats" and the "language" as two differents settings. You don't need to be an advanced user in Home Assistant to manipulate numbers and displaying it as you wish, so I think most of users was able to create it's own feature the way it was before. Actualy, there is a partially implemented feature, based on a setting that is not related to numbers, that will affect every numbers, whether it is a financial number$, or a RAM numberGB... my opinion is that it can be a great feature to customize the format of the numbers, in a way that the user can decide of it... Thanks for your time

[logicup-dev]

I find implementation of this feature better every day.

Screen from entities card

It's because you Counter entity does not have a unit_of_measurement, actualy the design of this feature is supposed to consider only entity with unit_of_measurement...

[michalk-k]

...which is highly inconsistent across ha since unit_of_measurement is not mandatory.
Btw there is no unit for simple counter

IMO it's another fact confirming that this feature is not implemented properly, therefore it deserves issuing bugs like this one

[logicup-dev]

ich is highly inconsistent across ha since unit_of_measurement is not mandatory.
Btw there is no unit gor simple counter

I agree

[scaarup]

Inconsistency or not - this is indeed a bug.
Example: Everyone who wishes to go with English language in the UI, will have numbers formatted "in English". I don't live in England - it looks wrong to me. At least allow me to turn this off then.

[michalk-k]

You are completely right.
Just out of curiosity: is there only one English language since 0.118? or there are more (en, us, au etc). Because not every English speaking country follows the same formatting rules (especially in date time format, but there are differences in number formatting too). Also there are English speaking countries which use more than one formatting - this is why formatting shouldn't not be strictly connected to chosen language.

[bramkragten]

There is English and English UK

[krakers09]

The point is English UK (English (GB) you meant?) is exactly the same. I've tested it. Set to English (GB), cleared all cache, cookies, etc. restarted browser (Chrome Version 87.0.4280.67 (Official Build) (x86_64)) and no change at all.

Also, if you look for example on Oracle docs, you'll that both UK and US use the same notation https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html

[Mariusthvdb]

This is not a bug but a feature. Why would you not want the formatting?

Id simply like the frontend to show an unformatted representation of the backend value. show 6125 lumen instead of 6,125 (talking Hue light level sensors)

and what the template editor returns:

don't feel this makes for a friendly experience on the eye:

where this is what is used to be, and much better to immediately grasp (and in this case creates a far better understanding of the difference between light level and lx, which uses the separator)

compared to the lux:

Was pointed here from the community, but now see this is already closed.... Please reopen?
I'll FR a separator option