Default locale (formatting data - Times, dates etc.) is US.

[aknight1-uva]

Currently, JASP starts with locale set to U.S. My guess this was done as a "fix" for issue #549. This "breaks" all the locale-sensitive string manipulation done by QT. The fix is to use QString instead of std::string for manipulating user input and user presentation (and while that is being done, replace std::string for QString everywhere where there is no real need for std::string). That done we can allow the JASP to use the system locale - giving dd-mm-yyyy format dates and comma as decimal separator, for NL users, dd/mm/yyyy and dot as dec. sep. for UK and mm/dd/yyyy and dot for US. Putting application locale as an option in the config files (default: 'system') would allow users to choose what is appropriate for them. Note: For those not familiar with QT locales see: https://wiki.qt.io/Locales

[spacek123]

I would like to emphasize this issue because it makes JASP difficult to use on non-english OS. On computer with Czech locale its hard to copy tables from output to Excel, because e.g. value 23.3 is automatically interpreted and changed to date value (23/03/2018). Thanks

[boutinb]

@spacek123 Can you send me a file where you have this problem?

[spacek123]

I could send file, but it's hard to reproduce on other computer, because it's dependent on system locale. So if you are using english OS, you would see no issue at all.

I know this issue, e.g. when I export tables from R thru clipboard in Czech OS, I had to use write.table with dec=",", sep="\t". Otherwise pasting in Excel would result in non-tabular data without recognized decimal point.

[boutinb]

I still would like to try. The locale is used differently if it is a csv, spss or ods file, so I would like to know first which type of file you load. For csv file, the locale is not directly used to read real numbers. So I am quite curious where it goes wrong.

[spacek123]

Sorry, maybe I connected it to wrong issue thread. My problem is with copying table output from JASP results to spreadsheet (via Copy). Reading data and analysis ouput in JASP are all correct, but copying out table to spreadsheet (Excel) in Czech locale results in problem because system default for decimal point is comma not period.

It wouldn't be so hard to find&replace periods with commas, but problem is that when number looks a little like date (e.g. 23.3), Excel eagerly convert it to date value in the moment of pasting, which really screw whole output.

[boutinb]

So if I understand well, you copy a table from the results of a JASP analysis, and paste it to Excel. And Excel does not recognise numbers like 23.3 and convert them automatically into a date. If JASP would display numbers with a comma "23,3", then Excel would recognise it as a real number. After some research, I can see that JASP uses the "toFixed" and "toPrecision" javascript functions to display the number in a table. These functions are not locale aware, unfortunately. If this is really the problem you have, I can try to fix this.

[spacek123]

Exactly, this is the problem. Fix would be wonderful. Thanks, I really appreciate all your effort!

[JorisGoosen]

@boutinb do we do this now?

[JorisGoosen]

I've moved this into 0.15 because I think it is hightime we start working properly with locales. Especially now we are starting to support more languages.

[tomtomme]

would still be a cool feature ;)

[JorisGoosen]

Sure is! Its definitely something we will do, also together with #30 or perhaps https://github.com/jasp-stats/INTERNAL-jasp/issues/1744 and the rest

[tomtomme]

Cool :) I cannot see those internal issues however :(

[JorisGoosen]

well its for monetary output column, and I would extend that with a monetary datacolumn too. But that would be locale independent in any case.