The apply_unit() is used
1.in saving the answers
2.in grading the student responses.
The 2,2 apply_unit() converts number to the PHP internal convention i.e. thousandssep (, ,space) are eliminated and decsep , is converted to . if it is the only one and that there is a . used.
the newengine apply_unit() eliminates the thousandssep associated with the thousandssep and converts the decsep associate to the actual user (either teacher or student) language .
What are the needs
1.in saving the answers
We need an universal conversion of written numbers to the internal PHP number to help the teacher set correctly the answer in PHP internal number format.
We shoudl add help to the editing form and get a more explicit is_numeric() validate message.
$string['invalidnumericanswer'] = 'One of the answers you entered was not a valid number.';
$string['invalidnumerictolerance'] = 'One of the tolerances you entered was not a valid number.';
For import we should use actual 2,2 that should be improved
i.e detecting all variants of thousandssep (i.e. half space)
or detecting the position of the , and .
2. In handling the response a 2,2 style should be the default for 2,0 and preceeding version (i.e. imported ) questions because
we don't know if the teacher have given or not indications on the number writing.
or as we will do at UQAM migrate from a french site 1.9 with . convention learned by 40 000 students to a 2 version with a , mandatory ?
So we need at least a specific field to identify at least the decsep which was used when creating a question.
It should be a the answer level.
Given that decsep can be , or . and that thousandssep possible values are limited to not many values, the choice offered to the teacher could be more a list of the available combination than a complete list of all the defined locales.
I will experiment on this.
I have set a working branch from qe2_wip and will start to work first on the edit and import problem using a specific 2,0 style apply_unit() function.
The following from PHP.net http://ca2.php.net/manual/en/class.numberformatter.php
illustrates well the problem
When displaying or printing a number it is converted to a locale-specific string.
For example, the number 12345.67 is
"12,345.67" in the US,
"12 345,67" in France and
"12.345,67" in Germany
Also from unix as PHP docs refer to UNIX http://linux.about.com/library/cmd/blcmdl3_strtod.htm
The strtod, strtof, and strtold functions convert the initial portion of the string pointed to by nptr to double, float, and long double representation, respectively.
The expected form of the (initial portion of the) string is optional leading white space as recognized by isspace(3), an optional plus (``+'') or minus sign (``-'') and then either a decimal number, or (ii) a hexadecimal number, or (iii) an infinity, or (iv) a NAN (not-a-number).
A decimal number consists of a nonempty sequence of decimal digits possibly containing a radix character (decimal point,* locale dependent*, usually ``.''), optionally followed by a decimal exponent. A decimal exponent consists of an ``E'' or ``e'', followed by an optional plus or minus sign, followed by a non-empty sequence of decimal digits, and indicates multiplication by a power of 10.
- locale dependent* this means that (float) casting uses PHP locale.
We cannot take for granted that the PHP locale settings are constant on moodle installations ...
Is this could be a problem when saving answer as in