Mono Upgrade Editor is using Window's locale settings

@bobdonovan are you still following this? It's very confusing to get official reply from you and then still seeing the broken behaviour.

 

That's weird cause this is not happening in any 2018.2 version, only in 2018.3.

 

Still I have commas in 2018.3.8f1.

I'm working with uscript and visual studio and need to fix those commas manually after detecting syntax error in script.
I'm not a programmer, I really don't know how to fix it permanently myself, need to fix by hand every float I'm using:/

 

There's a very helpful script on page 1 of this thread that corrects the issue. You just have to save it a c# script and put it in your asset folder. https://forum.unity.com/threads/editor-is-using-windows-locale-settings.442847/#post-3958150

 

It looks like the issue is finally fixed in 18.3.11, thanks
Editor: Fixed OS locale being used for Editor windows. (930798, 1116416)

 

Not serialization related, but cultural related, in latest 2018.3.12f1,

https://forum.unity.com/threads/hug...uage-behavior-change-from-5-6-to-2018.664942/

 

We have experienced the same problem with our udp-script, however it does not generate any error

int.TryParse(text, out speed);

simply does not give an output.

By using

System.Globalization.NumberStyles.Number, CultureInfo.CurrentCulture.NumberFormat

we have managed to get it to work in previous versions of unity (including 2017.2.0f3, 2018.1.0f2, 2018.2.0b9), but from Unity 2018.3 and forward

TryParse()

is not working with .Net 4x.. However, when rolling back to api compatability level 2.0, it works like a charm in 2018.3, but generate a lot of errors in 2019.1.

I get a feeling the problem we experience is related to the one mentioned in this post. We have tried @gresolio 's solution both in 2018 and 2019, but it doesn't seem to work.

Any solution to this?

Code (CSharp):

1.     private void ReceiveData()
2.     {
3.        
4.         client = new UdpClient(port);
5.         while (true)
6.         {
7.  
8.             try
9.             {
10.                 IPEndPoint anyIP = new IPEndPoint(IPAddress.Any, 0);
11.                 byte[] data = client.Receive(ref anyIP);
12.  
13.                 string text = Encoding.UTF8.GetString(data);
14.  
15.                 int.TryParse(text, out speed); // ORIGINAL, USED TO WORK!
16.                
17.                 //int.TryParse(text, System.Globalization.NumberStyles.Number, CultureInfo.CurrentCulture.NumberFormat, out speed);
18.  
19.                 lastReceivedUDPPacket = text;
20.                 allReceivedUDPPackets = allReceivedUDPPackets+text;
21.                
22.             }
23.             catch (Exception err)
24.             {
25.                 print(err.ToString());
26.             }
27.         }
28.     }

 

Could you please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

It's important that you report these issues together with a reproduction project if you want them to get fixed. If you don't do it, it might be a long time until someone else reports them or until Unity Technologies find them.

After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.

 

Just stumbled upon this bug, and it's pretty bad. Have the old OBJ exporter script broken, because it now prints commas into the file lol.
Furthermore, the behaviour is inconsistent with my Windows settings. Even though my region is set to "Russia", I always make sure the system-wide decimal symbol is set to ".":



Unity doesn't seem to respect that.

 

Still broken in 2018.4.0f1 windows standalone runtime.
My app has an editor and Input Fields with decimal places are broken when reading the values using float.parse in Germany and most likely other locales that use comma instead of decimal.
Will this be back ported from 2019?

 

Still broken in Unity 2019.4.

 

2020.3.4f1 and it's still broken

 

Also in Unity 2021.3.20. I don't think Unity has any intention of correcting this.

As a reminder, including this script anywhere in the project fixes the issue:

Code (CSharp):

1. using System.Globalization;
2. using System.Threading;
3. using UnityEngine;
4.  
5. #if UNITY_EDITOR
6. [UnityEditor.InitializeOnLoad]
7. public static class FixCultureEditor
8. {
9.     static FixCultureEditor()
10.     {
11.         Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
12.     }
13. }
14. #endif
15.  
16.  
17. public static class FixCultureRuntime
18. {
19.     [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
20.     static void FixCulture()
21.     {
22.         Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
23.     }
24. }

 

I don't think it's a bug on your side per se, I think it's more that the entire .NET ecosystem is broken with regards to culture settings, and you're going with the flow on that.

The tl;dr is that .NET uses the user's culture settings when formatting strings, if no formatting has been defined. Back before 2016 at some point, Mono on Windows used some invariant culture instead - either US English or actually Invariant, idk.

So the old default was that roundtripping worked, even if you did ToString on an Indian computer and did Parse on a German computer. You did, however, get the wrong format for display strings unless you specified the local culture.
The new default is that roundtripping breaks unless you specify a specific culture, but you get the correct format for display strings.

As a programmer, this is utterly maddening, and Microsoft has 100% made the wrong design choice here, and everywhere else. As a user from a country that uses different decimal notation than the US one, I have never cared about the decimal notation ever, except when using Excel where the culture thing also breaks stuff.


So from most standpoints, the old Unity behaviour from before 2016 where the culture was invariant was superior to the current behaviour, and we have run into actual crashes on console when trying to update (very) old games to newer Unity versions due to this. Yeah, we should have used InvariantCulture, but we didn't know any better and just thought that the programming language doing the correct thing by default wasn't a bug!

I assume that there's no bug for you to fix as any bug is presumably marked as "By Design", and all the user-facing strings you are showing that have floating point data is using (afaik) invariant culture. Fixing this now would could also be bad with regards to having compatibility with the greater .NET ecosystem for future things like integrating with NuGet or whatever

 

Thank you! There are quite a few bug numbers above in this thread. However, they got marked as "resolved" without actually fixing the issue.

For example, I had submitted 930798. The issue was fixed it in the editor and marked as resolved, but the runtime (just printing out a float number) is still broken and uses the locale's decimal sign (comma in my case) instead of a dot. Other case numbers mentioned above fixed specific case usages (i.e. broken serialization due to using the locale culture instead of an invariant culture), but didn't addressed the root of the problem either.

Here's a quick repro:

1) Change the locale settings of your computer to something non-US, for example Spain.
2) Create a blank, empty project in any of the latest Unity versions (tech, lts, alpha, beta, internal, etc).
3) Create a new script that logs a float number to the console on Start:

Code (CSharp):

1. using UnityEngine;
2.  
3. public class Test : MonoBehaviour
4. {
5.     void Start()
6.     {
7.         float a = 1.234f;
8.         Debug.Log($"Number: {a}");
9.     }
10. }

4) Add that script to a GameObject and run the scene. This is printed to the console:

"Number: 1,234"

If you add

float.Parse("1.234")

to the code you get an exception on non-US cultures.

I may submit the above as a new bug if you want, but it's as simple as that. Also, I suspect the issue might be taken in deeper consideration if someone from the Unity staff submits it.

Everything could be fixed if Unity just establishes the Invariant Culture as default culture on startup, in both runtime and editor. That would provide a consistent and invariant behavior across all devices and cultures, just at it used to work at Unity <2016.