Hacker News Reader

Comment by jeroenhd | Hacker News Reader

I agree, it's quite annoying to see American style numbering everywhere.

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.

View on HN

JSON (and CSV for that matter) both use commas as list/column separators. So formatting floats using periods as the separator is much more compatible with these formats. Never mind that programming languages format their floats in this manner too.

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.

Most of the CSVs I've encountered used the semicolon as a field separator, probably for exactly this reason, even ones from American sources. JSON has a standard format for writing numbers, which happens to be the American one, and I don't know what other data formats are sensitive to the comma.

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.

Other similar annoyances in US-centric front-end JS code :

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

Reply on news.ycombinator.com