I’m using Version: (5.1.5)-3, release build. Decimal separator appears to be hardwired to be a decimal point instead of a decimal coma. F. i. in ‘properties’ of a symbol. Size of text etc.
Besides the fact that the decimal point is a strictly a US phenomenon (the row uses a coma) its also implemented inconsistently throughout Kicad. Sometimes a decimal point is required, sometimes a coma is converted automatically into a point and sometimes a coma is required.
It does not break anything but it is a serious nuisance for the large majority of users which are used to use the coma as a decimal separator.
The entire English speaking part of the R.O.T.W. uses the full stop or period as the decimal separator.
I have seen some posts recently (ngspice?) to do with separators and export.
It is a big headache when you want a project to be portable between countries.
Edit
Hmm? I thought that the period was always used for the decimal point in technical and scientific numbers all over the world and that comma instead of period is for everyday numbers, e.g. prices.
Nope, here in Europe we always (>40 years) use a comma (Edit: Brainfart, I typed period here)to distinguish between units and fractions in numbers. (Except GB I think).
I do like KiCad’s idea of not making any distinction between what is entered, a period or a comma. Wish it was used in the same manner throughout KiCad. So If you feel annoyed by this, then compile a list and open an issue on gitlab.
Personally I’ve stopped caring about comma’s and periods, although I see that uniformity throuhout the KiCad is of course preferable.
It’s the same stupidity as distinguishing between meters and that other unit, or the 10’s of different way’s of formatting dates. I’m not even sure the same date system is used all around this globe.
Talking about dates:
Eeschema / File / Page Settings has a nice dialog to enter the date into the title block, but it’s not ISO8601, which is the only acceptable date format for me:
Over my life I’ve wasted a few hours to try to set the locale of my linux box to ISO8601 date format, but it seems to be one of those pesky things that I can’t seem to get right. I went as far as manually editing some locale file and then compiling it with some obscure program. Duh, it’s 2020 now…
Nope, here in Finland, which is part of Europe, we use comma.
I have been using KiCad for years and I use the point or the coma equally.
When I have English selected, the point is shown.
When I have Spanish selected, the coma is shown.
Moreover, I can enter either a point or a coma. KiCad (or the system, I don’t know) makes automatically the conversion.
And if I change the language on the fly, the point is changed to coma and vice versa.
I thought that this was the expected behaviour of KiCad. Ngspice export forcing period is a special case as it is 3rd party software
The expected behaviour of Kicad, or any software for that matter, is that it treats the minimum legal requirements of standards in a country/region properly. f.i. 4.000 (4(point).000) are considered four thousand by any bank in Europe and many other regions of this world.
Windows, considered byf some to be the worst, can do it and other MS products. OpenOffice can do it. Most software uses a country locale parameter to specify the decimal separator and do not make it depending on a language setting, which is only one parameter of a language locale (and might change even within a country).
At least it can be expected that a piece of software implements it in a consistent way.
Since a few responders have brought up other country specific issues I’ll touch them briefly.
With the date format the same thing. Its quite an anachronism, definitely bad engineering, to give up a logical sequence like d/m/y or y/m/d and use m/d/y instead.
Hours of the day 12/24hr clock. 12:30 is not just after lunch, no it’s just after midnight. How inconsistent and confusing is the 12am/pm bagunca.
Same issue with the metric and (various and different) imperial systems (the later is the legal system only in the US and Liberia). The entire scientific community has recognized many years ago to use the metric system (and so does NASA anyway ever since mankind started to use more than ten fingers to calculate). Even the electronics industry has recognized the limitations of being non metric. All newer components are ‘hard metric’.
I don’t know the insides of KiCad. I’m using Kubuntu and to be able to change language in KiCad I need to have installed its related locale in the system.
If you identify inconsistent locale behaviour, please raise a bug report for the developers to be aware.
KiCad PCB is internally completely metric, but allows both metric and imperial grids, as the through hole component world still revolves around a 0.1". The Imperial grid in the schematic is a legacy issue, to be fixed in the next major release?
I just hope that the choice between decimal point and decimal comma will not
be coupled to the choice of language, country or keyboard even though this might look at first sight a user friendly option. I prefer to have everything installed in English (as there is more info and help available in that language world wide) and because I’m tired of converting decimal comma’s to decimal points in my data sets, I always go for the decimal point notation, even though in my country and language this is not the standard for the general public.
kind regards
Hugo
Kicad is an international project why it supports commas and points and is able to switch the languages. There are some open bug reports for the language switch. The switches behave different between some Kicad parts for Schema and PCB what may change the setup on change with menu option while Gerber and calculator are standalone applications what do not refresh once started. Some of the input fields using DoubleFromString() accept both independent from i18n setup. If extending new rules for points and comma, Kicad should also introduce the SI notation like @Rene_Poschl is using for the lib: 3,3k or 3.3k or 3k3 or 3300R or 0M0033 should be accepted by input parser not regarding if it is a value to calculate or to search in library or output to BOM.
1 Like
No, not here in Switzerland.
By the way, you should NEVER use a point nor comma to group digits. Because it can be mixed up with the decimal separator. Us a narrow non-breaking space (U+202F), if not available use a normal non-breaking space (U+00A0) and if that is also not available use a normal space. Or at least use ’ if you don’t want to use a normal space because a normal space may causes an automatic line break.
While I agree that m/d/y seems illogical, it is the standard that I have seen in USA (the paragon of sensible standards) 
for > 60 years.
Wouldn’t it be even more logical to have only 10 hours in a day and divide those into tenths, hundredths, thousandths? My point is that even the 24 hour clock is making a compromise between being logical and being legacy compatible.
Quick experiment:
doesn’t look hardwired to me, maybe you can be more specific (e.g. “in X click here, then there and then look here”), I was having a problem the other way around: Everything was “.” until I opened “PCBNew” then all decimal separators where “,” , the culprit was a plugin playing with the locale, try to remove all plugins if you have any, better yet, try using a ‘clean’ properties folder and see if you can repeat the problem.
Hope this helps.
Our clock system is certainly legacy, but it’s far from a compromise when logic is concerned. See how superior the sexagesimal system is. And it’s compatible with base 12 which is the best of all numeral systems.
Yes yes yes, Me like 
Add to that other stuff such as inputting mils when the current input is set to metric, and vice versa.
FreeCad also goes a step further and you can add calculations into most any input field. What about entering: E12( 5/4m) to calculate the nearest E12 resistor that does 4mA when it drops 5V?
Whenever I see a date in anything other then https://en.wikipedia.org/wiki/ISO_8601 I always have to stare at it for 20 seconds, then try to think about what is the origin of the website, and when there are 2 (or, heaven forbid 3) numbers that are <13 it’s still a guess what date is actually meant.
About the clock:
From what I gathered the Romans used a 12 hour clock, and it ran from dawn till dusk. Regardless of summer or winter. During night time there was no need for time keeping. Those other 12 hours were added later.
Unfortunately staring doesn’t help even with dates which look like ISO. Guess how infuriating it is to see that some people have (probably unknowingly) stolen the ISO format but turned month and day around. And guess where those people live… Nowadays you can’t know if 2020-04-03 is 3rd of 4th or 4th of 3rd.
The genius of the ISO format was that it wasn’t used anywhere before, therefore being unambiguous, and it allowed alphabetical sorting. It was all ruined by ignorant people.
Of course you can:
Year: 2020
Month: 04 = April.
Day: 3
If the person who wrote it down does not agree with that then he/she either made an honest mistake, made a silly joke, or is and idiot and not to be taken seriously.
And that’s what happens in real life. Unfortunately.