Comment by zdragnar
3 days ago
I would be on board with most of these, but...Why on earth would the server send a currency value without knowing the users locale? Are you expecting the browser to be constantly pinging services to see exchange rates?
3 days ago
I would be on board with most of these, but...Why on earth would the server send a currency value without knowing the users locale? Are you expecting the browser to be constantly pinging services to see exchange rates?
Not sure I understand why do you need exchange rates with it.
<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
You're talking about currency formatting while they are talking about currency value. In essence, you're both correct.
They are correct in that if you're displaying a currency value, you have to know which currency it is in, right? It wouldn't make sense for the server to be "unaware" of the locale of the value.
That said, your comment sidesteps that issue and addresses how the number itself is displayed, since ultimately the value itself is a number, but different locales display numbers differently.
So the person you're responding to is asking: since the server ostensibly already knows which currency it's in, shouldn't it already be formatting the value appropriately, and that's more a question of where one thinks localization formatting should ultimately live in web app context.
Bingo. Take the swapping of periods and commas between US and maybe Germany.
If you see a price in Euros and there's a chance the browser converts the number to my locale, then the price becomes completely ambiguous. Information is lost unless I change my locale just to see if the number changed.
If, on the other hand, the browser doesn't apply such formatting, then the number is probably the number.
What's more, wouldn't you need to specify an origin locale so the browser knows how to correctly interpret the value?
3 replies →
But if it’s just formatting, how is that different from the “number” type?
1 reply →
!!!
A payment, bill, price, etc has a particular currency.
For example, 59.95 Australian dollars:
In en-AU locale, that is $59,95.
In en-US locale, that is 59.95 AUD or AU$59.95.
Either way, the quantity and units are the same, but they are presented differently.
In some cases, there may be currency exchange services. That will depend on the current exchange rate, and possibly exchange fees. And yes, that will take some more work. But that’s a fundamentally distinct concept than pure presentation of a monetary amount.
In en-AU locale, I’d prefer AU$ or AUD too - because you can just never be sure what you are dealing with - my work pays for me to use a coworking space not far from my house, and the app we use shows the price in US dollars, and doesn’t even mark it as US$ or USD, just plain $, I’m expected to know what it means. I’ve seen hotel sites quote amazingly cheap deals for hotel rates in Australia, only to realise they were quoting me USD (without clearly marking it as such), despite the fact that I was searching for a hotel in Australia from within Australia. In today’s global economy, you can’t go wrong by always being explicit about which currency you are using.
Maybe if we had <output type=“currency”> there would be fewer such snafus
You shouldn’t ever need to poll from the browser. If you were using WebSockets you could send 5 stock updates to the browser per second with almost no resource costs.