[Garan]

I think it's a bit stranger than that. SSG seems to have been trying to fix the inconsistent format with saved numeric plugindata settings that have caused confusion for authors (and users) for years. Unfortunately, they only implemented it in the 64-bit client so it isn't even consistent within a language and it did not take into consideration values that were previously saved so plugin authors still have to implement a workaround for old uses and 32-bit users that change to 64-bit - so basically, this only fixes 64-bit users that are new plugin installs (or wipe out all their plugin data) and only as long as they never switch back to the 32 bit client. Well intentioned, but more of a step sidewise than a step forward.

I noticed the tonumber() function works the same in the 64-bit DE/FR client as it does in the 64-bit EN client but the 32-bit clients still work the way they did prior to U29. That means that if any FR/DE users change from 32-bit to 64-bit (or vice-versa) they will get an error without even changing client languages. If you execute "return tostring(tonumber('1,000'))" on the various client versions you get:

32-bit EN:nil - the value prior to U29
32-bit FR:1 - the value prior to U29
32-bit DE:1 - the value prior to U29
64-bit EN:nil - the value prior to U29
64-bit FR:nil -changed in U29, FR 64-bit now uses EN version of tonumber()
64-bit DE:nil -changed in U29, DE 64-bit now uses EN version of tonumber()

However, just using the Vindar patch will not resolve this for most of the plugins out there as that just gets past the saving/reading as a string but doesn't coerce numbers into the current format. This could break more plugins than the the EquippedItems() bug back in 2011 that took 3 1/2 years to fix... I would suggest looking into implementing something along the lines of euroNormalize from MoorMap. euroNormalize coerces saved numeric values into the correct current format, that way, numbers will work correctly whether users swap from EN to FR/DE or 32-bit to 64-bit.

FWIW, euroNormalize is defined as:

if (tonumber("1,000")==1) then
	function euroNormalize(value)
		local retcode
		if value~=nil then
			retcode=tonumber((string.gsub(value,"%.",",")))
		end
		return retcode
	end
else
	function euroNormalize(value)
		local retcode
		if value~=nil then
			retcode=tonumber((string.gsub(value,",",".")))
		end
		return retcode
	end
end

I haven't fully tested this with the latest changes in the client but initial testing looks as though it still works correctly.
EDIT: After testing MoorMap positioning and size (both decimal numeric values) in various combinations of EN/FR/DE with 32/64 bit clients, it does still appear to coerce numbers correctly. There is definitely a bug in the Wallet plugin that I need to track down (it loads but positions oddly in FR/DE) but does not seem to be directly related to this issue so I believe euroNormalize is working correctly.