A classical "Sounds like a You-Problem to me." answer 😂

A substantial part of the world uses the comma (light green) as decimal separator instead of the period (blue).

Source: NuclearVacuum, CC BY-SA 3.0, via Wikimedia Commons

When you save a CSV, say, from Excel, it uses semicolons as delimiters. Even worse, when you open a CSV file that actually uses commas, Excel will not split the content into columns. You need to use the "Split into Columns" tool to get a proper table out - which has its own Excel-typical downsides like Excel messing with the source data while trying to format the columns etc.

You can't tell Excel to use the other one, because it uses the Windows locale, so you'd have to set Windows to English to get this fixed.

That's why it's impractical to use "," as delimiter in about half of the World. And since whoever at Microsoft thought it might be a good idea to localize the content but didn't think as far as assigning "ssv" as extension, all those people are stuck with a file name extension that says "comma" and contents that use semicolon, unless you manually format it back and forth every time after you save/before you open.

I would like to second this request, and since the feature is not there, neither is the feature request linked in the post marked answer (clicking the link opens the overview of all requests, so apparently that one was deleted), I'm bumping this thread again.

Note: W3C also lists available "standads" at https://w3c.github.io/csvw/syntax/#standards. Unfortunately, all of them say , is the stanard.

Yes, but it acknowledges that this is a "non-normative" "attempt" made with "Excel for Mac 2011" set to an "English locale". So it should be treated about as binding as an HTML standard derived from analysis of HTML files that Internet Explorer 8 can render correctly.

It also says that the line ending should be CRLF. Following that logic GitHub should also refuse to render CSV with LF line endings.

To say it with the words of section 3 in RFC 4180, which lends itself from section 2.10. Robustness Principle of the RFC 793 (TCP):

be conservative in what you do, be liberal in what you accept from others

Sadly, it appears that GitHub chooses to ignore that sentiment with a "works for me" attitude.

Thinking about it, if the comma heuristic fails, take the first two lines of the CSV file, and count the number of semicolons for both lines. If the count matches and is greater than 0, assume semicolon as separator.

That should be a very defensive approach. It cannot make anything worse for existing cases since it only kicks in when the current heuristic has given up. But it should work for many cases.

It appears that you have not read the thread. TLDR for you: in files that are using semicolon, the comma is used for decimals. Changing the format breaks compatibility with Excel and other Microsoft software.

The file name extension "*.csv" has been assigned to both the English format using commas and the other format using semicolons. There is nothing we can do about that, it is a misnomer, but it's not a mistake a handful of people have made, but the official behavior of the most popular software used to create these files and therefore a de-facto standard.

Sure, if the world was a different one where Microsoft had decided to use "*.ssv", I would agree. But the reality is that for 50% of the world, clicking "File > Save as > CSV" in Excel will create a file using semicolons, and opening a *.csv that uses commas will not work.

Thank you for the explanation, but I'm curious, why convert an Excel file to CSV in the first place? Excel can stay in .xlsx file format and be opened anywhere, phones, computers, tablets, laptops, literally anywhere with a browser. It's a rich file format compared to CSV which is text based.

To import data into other programs. As a "standard: er cough, CSV allows interchange between all programs that follow the standard.

CSV is a so called "defacto standard", it's evolved from usage rather than having a full officially maintained specification. Hence this thread. :)

Or to put it in a different way: CSV is meant to be a simple, low overhead text-only format for tabular (table-shaped) data. And since Excel is Microsoft's editor for tabular data, Excel is the default program to open, view, edit and create CSV files for most people.

Due to its wide spread usage Excel has defined a de-facto standard of what a CSV file should look like.

And there are two unfortunate things here:

a) Most computer stuff including standards being conceived in America being all too quick in conveniently forgetting about the rest of the world, so a lot of standardization working perfectly fine for American culture but not so much for other cultures.

b) Microsoft apparently decided that human readability in a text editor is important. So rather than defining "." as the fixed character for the decimal point and "," as data separator, they went with localized number format (which uses "," as decimal point for 50% of the world) and therefore needed to also go with a localized data separator: ";".

Microsoft's interpretation and implementation of the CSV format is a notable exception to a), whereas apparently all "modern" retrofitted standardization attempts of CSV fail to acknowledge that again.

Much truth. Just look back at ASCII, and then MS having to introduce the code pages hack to MSDOS for localisation/internationalisation (s spelling intentional - snigger).

Of course the tell tale is in the full name that ASCII is short for! Lol

I wonder how many people in the same boat!

I deleted my comment so it should be marked as unanswered now

So, I felt this fish tank is going nowhere. I feel like we're all just sitting in here, talking to ourselves about how ridiculous this situation is, but nobody from the outside (i.e. GitHub product team) notices. So I contacted GitHub support and offered them a free patch to their product code if they could connect me with whoever can work on this stuff.

Guess what, their reply was basically "Thank you for contacting us, but this is the support team, this stuff should be discussed with the product team. Best to add a discussion in the community discussions."

So I guess there's only two things we can do:

1. properly label this thread with "labels: Product Feedback, Enhancement, Accessibility, Bug" or whatever fits
2. tell everyone we know who has the same problem about this topic, and get them all to upvote it, so it will hopefully finally get the attention by someone.

Until then, we can keep making bubbles in our fish tank in here.