OK, this is going to be tricky.

For all of the advanced question options that EM now controls (e.g. min/max value, min/max sum), there is no way to have them support comma as the radix separator (decimal point). Comma is a reserved character in programming languages (e.g. to generate lists), so EM would have no way of telling whether you were trying to enter a floating point number or a comma needed for a function.

For example, say your minimum value was (using a period as the separator), {min(0.5,q1)}. If you tried it with a comma separator, it would be this: {min(0,5,q1))} - which would be treated as using 0 as the minimum, not one half.

Sorry, but there is no way around this, so, users will need to use a decimal point as separator when entering min/max values and sums in advanced question options.

However, it should be possible to:
(1) Pre-process all entered numbers input with comma to convert to decimal first (prior to doing validations - so that the validations pass), and
(2) Post-process numerical values for text display to convert from the period to comma separator (e.g. for the "Please enter a number between X and Y", and when re-displaying the value in a numerical input field).

Whether we should do that via a str_replace() function, or via a masking function (jQuery masks - http://archive.plugins.jquery.com/project/meioMask) is another matter.

In all of this, I presume that the database inserts need to use the period separator, so the internal representation would always be with a period.

Tom,

You can have a look at 1.91 :
.split('{$sSeperator}').join('.')
And
.split('.').join('{$sSeperator}')

In 1.92, the SESSION variable are put with dot too.
Maybe some problem with {INSERTANS:...} but it's not important.

Tom,

If you're OK, i get the bug, but when it's on LM i think it's important to speak with you :)

Denis

Attached is a survey that tests all of the question types the support numeric input. It is currently set to use a period as the radix separator. Switching to using comma will let us test accuracy of any fixes done here.

This fix will also require better validating numbers. Currently, LS uses onkeypress="return goodchars('-0123456789,')". However, you can enter number like '-12-3.4.56-7-' and still have that pass the first validation step.

When only numbers are allowed, we should use EM and regexMatch('/^-?[0-9].[0-9]$/') to validate numbers (and the comparable one for countries that use a comma as the radix separator.

This is too much work for the 1.92 RC4 release.

Hello Tom,

Sur for number like '-12-3.4.56-7-' :)

For testing if it's an numeric, no regexp:
return parseFloat(data)==data;
( but after replace the ,).

( maybe done at .blur() ?)

There are other possibility for numeric :
http://stackoverflow.com/questions/18082/validate-numbers-in-javascript-isnumeric
But with numeric question of LS, i think parsefloat is good.

True, parseFloat() would work adequately for testing whether numeric, so regex would not be needed for this.

However, would it make more sense to forcibly change the input values, or let people enter what they want, and then use CSS styling to show if the entered value was not truly numeric?

<q>However, would it make more sense to forcibly change the input values, or let people enter what they want, and then use CSS styling to show if the entered value was not truly numeric? </q> Don't know.

I already use some script to show number like this : 10 000,00 ( in english 10,000.00), calculate some other input, show it with good seperetor and put it in good value in database.

To see, but not for 1.92RC4.

Note to self on strategy:

(1) replace noop_checkconditions() with fixnum_checkconditions() - use it only for input fields that only accept numbers

(2) have fixnum_checkconditions()
(a) call join('.',split(',',value)), if needed
(b) call parseFloat() to determine whether a true number
(c) ensure that the $('#java'+sgqa) field uses a decimal point as the radix separator
(d) update the input field $('#answer'+sgqa) with the parseFloat() value (to fix bad inputs like -1.2.3), after replacing period with comma (if needed)
(e) call checkconditions to do the proper validations

(3) Update displays of totals and remaining values to use commas if needed

(4) Add .onlynum class to inputs that only accept numbers so that LEMsetTabIndexes() can add fixnum_checkconditions() as the tab function to call for those fields

(5) Need way to display numeric values from {INSERTANS:xxx}, and for validation messages (e.g. "Sum must be between X and Y"). This only affects tailoring, and should only affect tailoring of values coming from .onlynum variables.
(a) add .onlynum attribute to LEMvarNameAttr? If so, then LEMval() could do period to comma conversion, BUT don't want to do that for math processing. So, could consider using it in EM::GetJavaScriptFunctionForReplacement() function, which sets the innerHTML. Would only want to do that if final output is a floating point number with a period as the radix separator.
(b) create LEMfixnum() function that does period to comma conversion in tailoring, if needed
(c) create LEMradix variable on each page. Have LEMfixnum() use that to determine whether to convert period to radix
(d) have GetJavaScriptFunctionForReplacement() wrap replacement in LEMfixnum() instead of htmlspecialchars; have LEMfixnum call htmlspecialchars if not a number.

(6) Create validation type for numbers? This would color-code if not numeric vs. forcing the value to be numeric - that is probably overkill.

Fixed with GitHub patch https://github.com/LimeSurvey/LimeSurvey/commit/1101ba6d064f7898191276dec03ce4263997c338

1.92RC5 release