His account here doesn't display where he's from, but I'm betting that he's talking about locale-specific numeric data. I.e. how dots are sometimes commas and commas are sometimes dots in other locales.
And yes, this is a general problem in MapTool (should be corrected now), but all input needs to be treated using the locale-correct techniques, and I'm betting that the macro functions don't.
There are actually very few macro functions that do any conversion to a number (but there are a few), there are probably quite a few more that convert a number to a string. Those that do convert though are forced to do it in a non locale specific way (more details on this below).
Hopefully, there is a single place in MapTool where a class can be dropped to do all the locale-specific stuff, then other parts of the code can invoke it.
(Hmm, it just occurred to me that my patches to the I18N class that Craig wanted for doing a properties file lookup followed by formatting would probably fit the bill for output, but not input. Maybe that's the correct place to do input processing as well? double-Hmm...)
You didn't really think it would be that easy now did you?
Most of the string to number parsing occurs in the parser project --not MapTool-- there are some exceptions --getProperty, getLibProperty, also I think in MapToolVariableResolver, some of the json functions-- conversely most of the number to string conversion happens in MapTool.
So the change would have to occur in the Parser project --possibly DiceLib too-- and MapTool at the same time. This will also affect DiceTool etc too if you wanted to keep them using the latest jars for parser/dicelib...
This would of course also introduce difficulties sharing campaigns that use decimals across some different locales, but that is a procedural issue rather than a coding one. Oh and don't forget breaking forward compatibility of campaigns in certain locales too. The campaign would still load fine but decimal numbers would cause parser errors when macros are run.