Unity ignores culture settings.

(Using Unity 2018.3 Beta 11)
I live in germany and here we seperate numbers with “,” instead of “.”.
Even though i have set my language to English US and switched all the seperators manually Unity still uses “,”.
That wouldn’t be a problem (its just annoying) but now this is a bigger problem than i thought.
If you parse a number in Unity with float.Parse() it just ignores your .NET settings.
So all my data that i loaded into unity was changed from 0.033333 to 33333.0 for example.

Workaround (for people with the same issue):

CultureInfo ci = (CultureInfo)CultureInfo.CurrentCulture.Clone();
ci.NumberFormat.CurrencyDecimalSeparator = ".";
String s = reader.ReadLine();
float f = float.Parse(s, NumberStyles.Any, ci);

Could you please submit a bug report for this issue? Did this use to work in previous versions?

I noticed a culture related issue too, but the issue occurs randomly only, thus I never bothered file a bug report.

When I start the Unity editor, I can use the period and comma symbols in text-fields to enter numbers, such as the Transform Position fields. When I enter “1,2” in the Transform Position X field for example, Unity automatically changes it “1.2” and it just works.

Then, at some random time, this stops working. If I then enter “1,2” Unity changes it to “0”. I noticed this on a PC with a German culture setting. On another PC, where I en-US culture is used, I can’t remember to have experienced the same issue.

I noticed this bug in 2018.3.7b after i upgraded all my projects.
I remember that my old Unity 2018.1 installation was fine. Also this problem seems to be related to the .Net 4.6 upgrade.

Yea thats also an issue i have. But i didnt care until the whole parsing was messed up.
I would recommend Unity to always use “.” and ignore other cultures completely. Sometime i have to use other computers and the parsing is different on each one depending on the country.

I half-agree :slight_smile:

The editor should respect the OS locale like any GUI app[1], but optionally have a toggle to ignore it and use only the dot for decimal points. In code we’re all writing US-English numbers anyway, so it’s just going to lead to confusion about which setting is in use, therefore ignoring culture is the safest.

[1]Technically, it wouldn’t hurt to allow it to use “,” AND “.”, since the number fields don’t have formatting options to use thousands separators at all (which is where the other symbol would be used, unless the culture prefers apostrophes). This is also a great option for people who just mash a key in the general vicinity of the full stop, hoping they hit something the system understands.

I can’t open the Editor to test it now, but I remember I never had problems with a decimal comma in Unity’s components like Transform or Rigidbody (and my own MonoBehaviours as well), but it never really worked properly with values of materials and shaders – setting some shader’s property default to ‘1,2’ would make it 0 just as you say.

I don’t mind it changing ‘1,2’ to ‘1.2’ as I confirm the input, but I very much like the comfort of being able to type a decimal number solely with the Numpad without having to move my hand to the dot key (Czech culture settings).
E.g. when I need to set a Transform (or a bunch of Transforms) to specific values, that’s nine numbers I want to type quickly and a forced decimal dot would slow the process down.

1 Like

With so many people using small laptops these days, they tend to forget numpad exists and is definitely only giving you one decimal point option :slight_smile:

Unfortunately, this would cause other problems as some countries use the “,” to delimitate 10E3 digits. For example 1,234,567.89$

Do you actually format any of the fields in the editor according to culture?

But surely you don’t need this kind of formatting inside the input fields of the Editor, or do you?

3928459--335530--Insp.png

I can’t imagine wanting to use the thousand-separator in a scenario such as this one. Most input fields are too small to display a large number in its entirety anyway and when you confirm the input, it displays it as it wants no matter what you typed.

If there is some field which uses digit separators about which I’m not aware of, couldn’t you use something like the C# 7.0 digit separators for the input part?

float number = 1_000_000.25f;

We do, but we clearly forgot some place… :frowning:

Well, then my request is for consistency :wink:

1 Like

In order to minimize the risk involved by switching to .NET 4.6 as the default .NET version we opted for an approach where we always use the invariant culture when parsing floats unless the user specify a locale. This matched the previous behaviour of past Unity releases and seemed to be what most users were recommending on forums. Above all else we wanted to make sure we did not introduce issues with data persistence (which must always use invariant culture). People from all cultures must use the decimal point when they write code. Maybe when we officially support multiple languages/locales we can revisit this and offer the option to use the OS locale for decimal symbol.

The thing is, the original post hints at rather the opposite. The OS is setup to use en-US but Unity somehow still uses de and not the invariant culture

Yeah, in some plugins that I was using, culture stopped working in some beta version (after b7 I think?);
Had to contact the authors, and they’ve figured out that the errors were directly related to the incorrect float parsing / culture issues.

The internals of the system absolutely must stick to ONE culture, otherwise everything goes straight to hell. Source code won’t be compatible just because users collaborating are from different countries.

Microsoft tried something batshit insane like that once. Each translation of the Office suite also had a translation of Visual Basic. If you saved the source code as text, which was the bloody default, you had code you could only share with people who used the same language Office. BRILLANT!

Don’t ever mix code and culture. Code IS its own culture.

3 Likes