Hacker News Reader

Comment by withinboredom | Hacker News Reader

I assume most Americans don't run into the CSV hell that other countries do. In my current country, whether CSVs open as a comma-separated or semi-colon seperated document depends on whether the OS is set to use a , or a . for decimal numbers. It's absolutely annoying.

View on HN

Right but the import wizard can fix things. They just don't make the double-click go through the import wizard - and people use 'open' or double-click their files. LibreOffice Calc opens the import wizard when you open a csv and it's fine.

For the life of me I cannot comprehend why they cannot let us choose the decimal separator independently from the locale. Or for fuck’s sake, just be smart about it. My desktop is for boring administrative tasks, of course I want it in my language. No, I don’t want to manually change settings in Word for every fucking document I create because ~none of them will be in English. But then why do I have to search-and-replace . with , or click 12 times through an inane bullshit wizard just to paste some data in Excel?

Respecting regional settings is so inconsistent among Office applications. The desktop ones usually get it, but online is a crapshoot. Whenever there's a date like 3/4/25 I get the play the fun guessing game of whether that's March or April.

For Project Online, the most reliable way I found to fix it was to manually edit the URL to replace en-US with en-AU, then bookmark that.

Americans don't use CSV?

Depending on whether your OS uses a , or a . for decimal numbers changes how excel will parse a CSV file. Americans use a . for decimal numbers, so it will parse it as a CSV. Other countries use a , for decimal numbers, so it will parse it as a SSV (semi-colon separated) and everything will be in a single column.

To make matters worse, randomly, employees will have their OS using US or GB locales so that if you distribute a CSV, it will work for some employees, but not for others.

Excel's behaviour is almost as annoying. It's basically impossible to produce a correctly-formatted German document on an English OS and vice-versa.

this seems like less of an excel problem and more of an issue with an improperly escaped data set though?

No. Excel changes the SEPERATOR when parsing depending on the locale settings. This means a CSV generated or saved with a decimal of . will not be able to be opened by one with a , and vice-versa. This is an Excel issue, as it doesn’t even try to determine or ask which separator to use. Hence why the comment above said you need to use the import wizard and not double click.

I don't know any of these problems. I use a modern operating system and office suite that supports CSV not a specific subset and syntax of it.

The syntax that MS Office uses to read/write a CSV is defined by the Regional Settings of your PC.

Open control-panel for regional settings, select "Advanced settings" button on the bottom control.exe intl.cpl

If you don't know any of these problems, then all the people and systems you work with have a "." as decimal and "," as separator, and you are spared from the hell of MS Office being unable to overrule these OS-settings when treating a CSV

Honestly as this always was an obvious issue I usually just used ; and never got a complain. Obviously both . And , are used way to often not only for numbers. I am surprised this is problem enough (in 2025) that people emotionally discuss it.

> Honestly as this always was an obvious issue I usually just used ; and never got a complain.

Thing is, it is not about what you used, you are not able to control this from happening when your CSV should work for people in other countries. Whatever configuration you used which never got a complain, if your recipients also used Excel to work with those documents, they probably have the same regional setting on Windows for list/thousands/decimal separator.

If you use ";" as separator, i.e. Excel in UK, US, Japan, China, Korea will not be able to correctly open your CSV.

But even better: If you created this CSV on a France or Sweden regional setting, the thousands separator will be a whitespace ("1 000" instead "1,000" or "1.000"), so Excel in e.g. Italy will not detect those properly.

> I am surprised this is problem enough (in 2025) that people emotionally discuss it.

It is a (intentional) weakness of MS Office for those who work in an international environment, because Excel links itself to .csv files to hinder the experience, as it is neither able to properly detect them nor guide their users through a process to properly handle them.

1.01 in US === 1,01 in EU

   1.01, "hi", CSV has problems, "1.01"
   1,01, "hi", Yes it really does, "1,01"

See the problem now?

Your operating system cannot solve this problem.

CSV already solved this problem with quotes. Maybe not the most convenient solution for some users but that's no excuse for the Excel behavior of making up a different format depending on the locale.

Excel really doesn't care what users think. I mean, in biology, we've already had to change the names of genes to accommodate Excel's auto-date conversion routines. So, why would it care to have globally consistent CSV formats?

Is this 2025? Why would any software safe it invalid like that to begin with?

Not all of EU though. I am European and I never used "," anywhere yet people understood.

I don't understand the down-votes, but okay, have it your way, lmao. Someone really hates dots.

I guess the downvotes are because you also didn't understand the context.

It's not about people, it's about the Windows locale setting and how MS Excel interprets a CSV-file when you doubleclick it

Yeah, I agree with that and I find it frustrating.

Reply on news.ycombinator.com