continental comma with JSXG

[Bjoern-Ge]

The new continental comma is not working together with JSXG.

Using the Decimal separator option set to "," some JSXG handover points are not working.

When ans1 is a point, it works as long as the point has integers as coordinates.

When the coordinates are floats, the answer is invalid, as Java hands over a float with a dot as separator.

[aharjula]

Well, there are many things in play here.

1. In the world inside [[jsxgraph]], we speak JavaScript, and it has no continental commas. So, even injecting values into that script one needs to use the separator it expects. The tricky bit is that one could also tune the separator in JSXGraph and might use text fragments where one would want to use non-JavaScript separators. So, we cannot simply force all injections to use a particular syntax inside the [[jsxgraph]] block, as we can not know which ones are used in which way.
2. The binding functions, by default, will use JSON as their output format, and as that is JavaScript, those will not play well together with any inputs expecting commas. You can, of course, override the serialisation as you wish, but I would strongly suggest that if the input is coming from stack_jxg it should not expect commas.
3. Unless of course, the input is also used as an accessible alternative, in which case you need to also change the script side serialisation to make the accessible input use the "correct" separators.
4. If we start affecting the input expectations based on the active locale selected separator, things will get messy if the script logic is "custom".

Point 3. is the problem. As long as we can assume that the serialisation of graph state can use "normal" syntax, then simply configuring the matching inputs would be enough for all use cases. But if someone actually needs to use localised syntax, then things get really messy really fast. Especially when the question should be able to change locale on the fly, which is the long-term goal.

If we allow input by input tuning of the syntax (which is something I want), then we cannot simply switch the whole stack_jxg-library to a version using a particular syntax as in that case, one would need to be able to select the syntax binding by binding. That would lead to an API change in the stack_jxg-functions as they would need to have an extra parameter to tell what syntax to use in a particular binding.

Personally, I would strongly recommend that all [[jsxgraph]] binding logic should use JSON-syntax and not mix localised syntax with them. But as accessibility is an issue, those wanting to stretch it to the level of continental commas will need to write custom bindings at this point, and even in a future that would give tools for it one will need to carefully follow rules to make it work in a sensible way over toggleable locales, and I am fairly certain that very few current custom bindings would simply work with any of the ideas my head currently contains for doing this.

[Bjoern-Ge]

ok I underestimated that problem.

The key question is what is needed.

From my side, it is good if JSXG and only JSXG is excluded from the comma setting.

There is the case (3) that will happen. In my case, this is very rare.

It would be great for me if only JSXG was excluded and the text output in the question is still working according to the comma setting. Also, it would be nice if other input fields still have the setting. The "answer can be typed like..." then is a bit unclear for JSXG input. It could be according to the comma setting or not. I tend to say without, as (3) is less problematic then.

[Bjoern-Ge]

For anyone using the dev with the continental comma and JSXG. I changed all questions that use JSXG with "input-ref" back to decimal separator '.' in the database without using versions by:

UPDATE mdl_qtype_stack_options LEFT JOIN mdl_question ON mdl_qtype_stack_options.questionid = mdl_question.id SET mdl_qtype_stack_options.decimals = "." WHERE mdl_question.questiontext LIKE "%input-ref%"