float.Parse different for German OS

I’ve got this very weird bug where float.Parse doesn’t work correctly in Germany, this appears to be because in Germany floating point numbers are defined with a comma, whereas my xml file that is being read in has numbers stored with a full stop.

I think there is a way round this but is there a more universal way of dealing with this that will force full stop usage in all languages?

I think I’ve found the answer

NumberStyles.Float in System.Globalization

I would have thought that might be the default, but I guess not.

its by default “what the system uses”, anything else requires enforcement

damn… that works in the UK but not in Germany. Back to the drawing board.

@dreamora - how would you get round the issue of having a default xml file made in the UK that needs to be read in countries that use “,” by default. Using NumberStyles.Float just seems to completely break the parsing.

If it isn’t a major issue, can you use a regex to convert the comma to a period, and then use float.Parse?

Add this in an Awake function:

System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");

Then everything will use “.” instead of “,” and you don’t have to change any code.

–Eric

This is what I ended up doing, bit of a hack, Eric I’ll try your solution later.

	var nfi = Thread.CurrentThread.CurrentUICulture.NumberFormat;
	var nfs : String = nfi.NumberDecimalSeparator;
	
	return float.Parse(f.Replace("."[0], nfs[0]));

Or you can just use Culture.InvariantCulture not sure if it’s the correct Syntax.
Type InvariantCulture into Google.

There’s an extra wrinkle here in that I need to support users that already have the product and will have floats stored using the comma format in their preferences so I think I’m going to have to stick with some sort of hack, if only I’d known about this in advance. Rats.

It seems putting this in Awake isn’t enough, sometimes it works and sometimes not I have to force it to be called each time I use the parsing functions, maybe something to do with threading?

System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");

the way you want to go there will not wake and is neither acceptable. forcing your own culture onto the user will confuse him and not help anybody. especially unity won’t respect your desires there either.

what you are meant to do is store and parse the data culture independent (microsoft has a lengthy article on it, I think even linked indirectly from float parse MSDN docs and I’m sure there are about 4 dozen articles world wide at very least on the matter), so you can save and load it correctly.

Sadly that is impossible when the default settings are shipped with the product, the user never sees any of these values so forcing it on them is perfectly acceptable in this case since they won’t know about it.

1 Like

Depends on: if you don’t allow them to input any number it is no problem indeed (though unity still might override it with the system settings beyond your control). But if they enter numbers, then it won’t be acceptable.

There is no number entry fortunately, but I could of course just set it whilst the xml is parsed and then switch it back to native. It’s only an issue during the loading phase.

I had to use this to read a text asset of numbers, since a Dutch friend had it converting ‘.’ to ‘,’ and the values would be out by 3 decimal places.

Double.Parse(sIO, System.Globalization.NumberStyles.Any, CultureInfo.InvariantCulture);

Here’s a quick way to change the values to match the current culture.

At the top of your class,
http://www.askexpertpro.com/15008/parsing-numbers-containing-commas-or-periods