I must admit, I find it baffling how the EU uses metric, but yet, they use the comma as the decimal point. And the dot to separate thousandth units.
Like this:
1.000.000,52
Why is that better than this:
1,000,000.52
Like this:
1.000.000,52
Why is that better than this:
1,000,000.52
There's no real reason why one is better than the other. They're both somewhat arbiratry and as far as separation goes, there's not even worldwide consensus about the amount of zeroes that are in front of a separator. As a European, I don't think I've ever been confused reading an English-style number because of the different separator. The only problem i can imagine is a number with three decimals (123.456) but with such many orders of magnitude in difference it should not be a problem to understand the right number based on context.
The character was chosen based on either practical reasons (the French already used a period for something else in maths) or because it made sense to use the system of countries around you or countries you were trading with a lot.
You can ask the same question about why some countries drive on the left and some on the right but in the end it's because you have to pick something and at that point you just pick what's practical. Or, you can ask why the American number system uses billion to mean 1e9 while in Europe it often means 1e12. It all comes down to what people are used to. Or why America has its date format unsorted (m/d/y vs d/m/y or y/m/d).
Furthermore, the whole world uses metric aside from three specific countries versus the much larger split of comma versus period. It's not really something that can go wrong much as long as you can understand some context (if you read a theoretical numbering system like 10-000-000'00 you'd still understand what the decimal point would be). Using two or four decimals clears up any confusion regardless of system.
I'm gonna stick up for the American system here, because if "billion" doesn't mean 1e9 then the only way you can say that number is "thousand million", which is terrible. The long scale just sucks.
The short scale is just another reason why European and American data sources get confused every now and then. I find it kind of strange that the UK switched to the American system despite having used the long scale themselves for quite some time. I suppose it was just a consequence of the US media getting influence in Europe after World War 2, but it couldn't have been an easy switch.
Miliarda - 1 000 000 000
Bilion - 1 000 000 000 000
Biliarda...
Trilion...
(Czech, it's very painful to read translated articles BTW)
The original arabic character now has a Unicode code point, so we could fix the mess by switching back to that ;-) https://www.fileformat.info/info/unicode/char/066b/index.htm
You make it sound that the EU is the odd one out here by not using the "normal" decimal point, but internationally both version are used just about as often: https://en.wikipedia.org/wiki/Decimal_separator#Arabic_numer...
Neither is better or worse, it's just convention.
When it comes to imperial vs. metric, the systems are very much not equivalent, and you could argue that either of them is better. Of course, they're better at different things, so in the end it comes down to weighing their respecting strengths against each other - but at least there the discussion is somewhat meaningful. When it comes to dot vs comma, it's just an arbitrary choice, and too bad we didn't all choose the same.
An Intel driver program crashed at me because it stored its Window size American style while the system was set to a different locale.
This can easily be fixed by specifying the input and output locale in your code, which I'd something you should always do anyway if you're selling software to more than one country. There's more differences in internationalisation than just decimal separators and date formats. Using proper locale code will fix all of those for you so you don't have to deal with calls from customers.
Let's not kid ourselves, the comma representation does not play well with programming languages or common data formats, and for that reason shouldn't be used except at the very top level of the UI for formatting purposes when displaying for certain locales. You're needlessly making things a lot harder for yourself if you attempt otherwise.
I don't store floats in the users locale and I don't think anyone should, just like dates should be stored in UTC (timestamps, preferably) instead of in any local date format. However, many programmers seem to forget that if you don't specify a locale, the system will choose one for you and its probably the one the user set up while installing their system, just like what would happen with any date or time.
I'm not going to change the way I write numbers because some American programmer thinks it's too annoying to bother and neither are my customers. Localisation is important to remember because if you don't, you're going to be burned by it at some point. This is just another gentle reminder about that.
- Numeric text fields filtering out all characters except figures + ".", even when the locale is set to something that should allow commas.
- Numeric text fields that expect a specific keyboard layout, for example numbers as the lower characters of the top keyboard row, filtering out anything else. In some layouts (like French), that's not the case : numbers on the top row are accessed with Shift, direct access is for symbols / punctuation. If the text field also disallows pasting, that makes it impossible to fill unless you switch layouts in the OS.