Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  4. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Mono Upgrade Editor is using Window's locale settings

Discussion in 'Experimental Scripting Previews' started by Edy, Nov 25, 2016.

  1. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,171
    As you can see in the attached picture, the float-point fields in the editor are using commas instead of dots for separating the decimals. This also happens when using string.Format for composing strings with numbers.

    upload_2016-11-25_18-7-46.png

    It looks like Unity is taking the host's locale settings. This can lead to different results from the same application. All other versions use the same locale for showing the same numeric format everywhere by default.

    I believe that Unity should use Culture.InvariantCulture globally by default. It should be a specific choice for the user to set a different global culture.
     
  2. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    941
    I can confirm, any C# that's being run inside of Unity defaults to the host locale.
    Code (CSharp):
    1. // Will log the date in the host locale
    2. Debug.Log(string.Format("some date {0:MMMM d, yyyy}", DateTime.Now));
    I believe this is a breaking change, Unity should set the global default locale to whatever it was before the upgrade (English-US?).
     
  3. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    @Edy @ZimM Can one or both of you submit a bug report for this issue, and let me know the bug number? This is certainly a breaking change that we should correct. Thanks!
     
  4. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    941
  5. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    Thanks for reporting this issue. We will investigate it and let you know when it is corrected via the bug report.
     
  6. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    As it turns out, this is a breaking change from the behavior of the pervious version of Mono that Unity used, but it is a change we will make. Using the host machine's locale settings on Windows brings the behavior into line with the way Mono worked before on macOS. So the current behavior of Mono on Windows is really a "bug".
     
  7. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    941
    That actually makes sense in general, but perhaps you might consider setting the locale to "en-US" for Editor code only? Basically, everything that happens outside of Game View. Since Unity Editor only has English interface, and pretty much all stuff on the Asset Store uses English for text as well, it would be quite annoying having to type something like
    string.Format(new CultureInfo("en-US"), "{0:dddd MMMM d, yyyy}", DateTime.Now)
    every single time there is a need to format something for the UI. Not to mention that even Unity's UI is now inconsistent across machines.
     
    Last edited: Dec 14, 2016
  8. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    This is something we will consider, but a change like this would be a breaking change on macOS and Linux, so it looks like we need to break the behavior of the Editor on some platform. I'm not sure what the best option is now.
     
  9. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,063
    FWIW, we are interested in shipping the Editor in multiple languages in the future, so it's probably not a good idea to make assumptions now that the en-US culture can just be applied to everything outside the Game view.
     
  10. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    941
    In any case, default locale must be set by the Editor itself, not blindly taken from the system. For example, if the Editor is in English language, then the default locale is "en-US", if the Editor is in Spanish - then it probably can be set to "es-ES". Otherwise users will get a mix of languages and formatting style, which is bad, since very often the language in which users would like to have Unity is different from the system locale. I have a russian locale, and, well, russian number and date formatting in all-English Unity interface looks terrible in the preview version.

    My opinion is also from the Asset Store developer point of view. Obviously, not every asset developer would be able to translate their assets into multiple languages, in fact, I'm pretty sure 99% won't even bother doing languages other English. I definitely won't, personally, as that would cost a *lot* of money to pay the translators for, especially when I need to update something, and especially because it would give users false impression that I am also able to provide personal support in those languages. That's why I believe the default locale for at least the Editor code should be en-US no matter what the Editor language is. That way, multi-language support would be opt-in for Asset Store developers. Otherwise I'd have to specify the en-US locale every single time I need to format something for the UI, which is pretty pointless. And if I *am* willing to support different languages in my Asset Store product, then that intent should be obvious from the code. Basically:
    Code (CSharp):
    1. // Should print "December 18, 2016" no matter what.
    2. Debug.Log(string.Format("{0:MMMM d, yyyy}", DateTime.Now));
    3.  
    4. // Should print the date in the current Unity Editor interface.
    5. // For example, should print "diciembre 18, 2016" for Spanish.
    6. // EditorApplication.defaultCulture is a fictitious property that will return the locale of the Unity Editor.
    7. Debug.Log(string.Format(EditorApplication.defaultCulture, "{0:MMMM d, yyyy}", DateTime.Now));
     
    Last edited: Dec 19, 2016
  11. StaffanEk

    StaffanEk

    Joined:
    Jul 13, 2012
    Posts:
    373
    Please not like this, not like this. Make this changeable in the editor.
     
  12. thomak-dev

    thomak-dev

    Joined:
    Mar 8, 2015
    Posts:
    13
    So this made it into the actual 2017.1 release. In my opinion unacceptable.
     
  13. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    The original bug looks like is was corrected in time for 2017.1. Can you submit a new bug report if you are still seeing this problem?
     
  14. thomak-dev

    thomak-dev

    Joined:
    Mar 8, 2015
    Posts:
    13
    I submitted a bug: Case 930798. If you need more info let me know.
     
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    Thanks, we will investigate this!
     
  16. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    3,234
    @JoshPeterson, what's the correct behavior here? Will Unity's runtime set a specific culture, or will you use the user's culture?

    It would be utter madness if the user's culture was used. That would mean that if you submit an asset store package that assumes that a float's ToString method returns data looking a specific way, that asset store package might break on other people's system.

    Code results changing from OS to OS is horrible enough already. Code results changing arbitrarily depending on user language is the worst idea! The only thing that makes sense is to always use the invariant culture, and let us specifically ask for it if we want code results to be localized.


    To put it in the other way,
    - if you use the invariant culture, dates doesn't show up the way I set it up in Windows.
    - if you use the user's culture, code might randomly break.

    It should be very obvious which is the best choice.

    If you're really going to localize the editor (please don't), and you really want the punctuation and dates and whatnot in the editor to be culture-dependent (which doesn't provide any value to the end-user whatsoever), please put in the work on your end to get the user's culture instead of pushing it to us.
     
    Mikael-H and moonjump like this.
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    We're not sure yet. Our editor team is currently working out the best way to handle things. We will get back when we have some ideas or decisions to present. Thanks for your input - it is helpful.
     
  18. Mikael-H

    Mikael-H

    Joined:
    Apr 26, 2013
    Posts:
    249
    It seems the decimal separator changes to ',' for me when switching to 4.6 backend in the editor. It also changes the default .ToString() result for doubles to include ',' instead which caused some funny bugs for me before I could figure out what was causing it and added invariant culture as parameter. Switching back to .Net 3.5 gave me back the precious point decimal separator.

    Is this a bug? If so I'll submit a bug report! Is it a setting? Is so, can I please have my '.' decimal separators back? :D
    My OS is on a culture setting which uses ',' as separator, but I prefer not to use it in Unity if I do not have to.

    Also, I just want to point out that I entirely agree with @Baste above, please keep the editor culture independent! I can't balive that there actually is a valid business case for localizing the editor but I guess you guys investigated it before embarking on such a venture...
     
  19. StaffanEk

    StaffanEk

    Joined:
    Jul 13, 2012
    Posts:
    373
    Please don't fudge my locale settings Unity . Please don't fudge me like this. I want my code to work. I don't give a crap about your culturally sensitive SJW bullshit.
     
    mbbmbbmm, dadude123 and Mikael-H like this.
  20. marcelopaulon

    marcelopaulon

    Joined:
    Jun 17, 2017
    Posts:
    1
  21. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    339
    StaffanEk and dadude123 like this.
  22. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    339
    Not `new CultureInfo("en-US")`, but `CultureInfo.InvarianCulture`. And yes, you should explicitly specify culture every time to guarantee consistence. Unity must not patch underlying framework class library, whichever target is: Mono, Xamarin, UWP, .NET Full, .NET Core, etc.
     
  23. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    941
    There is no need to patch the framework. Unity just needs to add one single line of code somewhere in the Editor:
    Code (CSharp):
    1. Thread.CurrentCulture = CultureInfo.invariantCulture;
     
  24. spacefrog

    spacefrog

    Joined:
    Jun 14, 2009
    Posts:
    516
    I just stumbled over this issue in Unity2017.3.1.f1
    I'll test int Unity 2017.4 LTS version, but would like to know if there is anything happening to resolve this problem ?

    Another question:
    Is the deployed engine runtime also affected by this ? I know i had to implement CulturInfo precautions back in the days when i started to develop for WP8 deploy, as there the engine runtime used dotNet, not the mono runtime. So it would look plausible to me that those current problems when using NET 4.6 extent to the deployed code too ...
     
    Last edited: Mar 30, 2018
  25. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    It looks like the bug report is still open. I'm not directly involved with the team working on it, so I'm not sure about its status.

    I believe that this only impact the editor though.
     
  26. Dmitriy-Yukhanov

    Dmitriy-Yukhanov

    Joined:
    Jul 27, 2012
    Posts:
    1,025
    Hey guys!

    Any update on this?
    I see the issue is still not fixed:
    https://issuetracker.unity3d.com/is...nspector-fields-with-experimental-net-4-dot-6

    And looks like Vuforia can't be used with new .NET runtime since it saves marker XMLs with dot-separated floats when making unitypackage with markers at their website, but Unity with new .NET can't parse those floats because it expects the commas because of this locale bug.

    Tried it on 2018.2 - still the same issue persists :(
    So I had to revert to the old .NET runtime since we are often update markers while at the active development stage and it's too annoying to fix commas -> dots by hands each time we update markers (and it's uncomfortable to spread this special knowledge across whole development team).

    cc\ @JoshPeterson
     
  27. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,329
    I don't have an update on this issue, unfortunately. A different team is tasked to work on it. I'll update the bug report with the information you've mentioned though.

    Please vote this issue up on the issue tracker if it matters to you. I know it sounds trite, but those votes do help us prioritize bug reports.
     
    Qbit86 and Dmitriy-Yukhanov like this.
  28. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    46
    I really need to chime in here since after digging through numerous bug reports I think this bug is the root cause.
    The Animator component in all versions since 2017/2018 cycle, when using .Net4.6, is internally saving numbers with "." but parsing the numbers shown in the inspector as-is, that is, with "," - resulting in a behaviour where animating e.g. rotations leads to
    • user animates to "30,54" (that's what the Inspector shows)
    • user drags the time slider in the Animation window
    • value jumps to "3054,00" in inspector
    • user animates again
    • value jumps to "305400,00" in inspector
    and so on.

    I just made a new bug report, because this is really seriously affecting us (we can't animate anymore using .Net 4.x!)
    Case 1073448

    Here are related bug reports:

    Issue ID 930798
    https://issuetracker.unity3d.com/is...nspector-fields-with-experimental-net-4-dot-6

    https://forum.unity.com/threads/tim...-and-undocumented-behaviour-continued.531997/
    and
    https://forum.unity.com/threads/timeline-animation-bugs-weird-and-undocumented-behaviour.526500/

    Issue ID 1040868
    https://issuetracker.unity3d.com/is...n-timeline-gives-unpexpected-incorrect-values
     
    HaBe, Dmitriy-Yukhanov and Qbit86 like this.
  29. HaBe

    HaBe

    Joined:
    May 29, 2014
    Posts:
    31
    While I do understand that you guys at Unity are looking into localizing your editor frontend, you don't seem to realize that you still have to keep the data and related behaviour in the back consistent, independent from the system or thread culture.
    That's why you have things like presentation, application and data layers in any modern comercial project for decades.

    It's like the third time now that I'm confronted with this problem since you introduced .Net 4.x, and reading that .Net 4.x will be the new standard with the upcoming 2018.3 release gives me nightmares. What are we that we are not working on english locale based systems expected to do then? Search every ToString and Parse/TryParse in every asset that we've bought in the last years and decide on every single line if it's necessary to fiddle with it? Hope that you'll finally be able to find a solution in the next 10 years to come? Sorry for letting off steam here, but this is going on for too long now with too many topics.

    At least give us information on some solutions/workarounds etc. instead of staying silent. It's beyond me why you still don't have better information politics in place, especially on breaking changes and stuff like that, instead of shipping these silently and just leaving smaller users alone with it to the point where Unity isn't an option anymore. Why wouldn't you care?
     
    Last edited: Sep 14, 2018
  30. bobdonovan

    bobdonovan

    Unity Technologies

    Joined:
    Aug 2, 2017
    Posts:
    3
    Hi HaBe, thanks for bringing this very important point to our attention. We will make sure that all the serialization is done using 'Culture-Invariant' culture before 18.3 is released while leaving the frontend open to use any culture (CurrentUI culture by default). We are putting forward a solution enforcing that every numerical .ToString() not specifying a culture in the editor would result in an exception. This will allow us to systematically validate all code to be explicit on which locale they want to use, either `InvariantCulture` or `CurrentUICulture`.
    Thanks for your feedback.
     
    Qbit86 and Dmitriy-Yukhanov like this.
  31. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    3,234
    Just to reiterate the point - Unity now displays the decimal points in the transform's UI with . or , depending on what language our OS has, Norwegian or English.

    Every single time in my life that any UI in any program ever has tried to localize, it's been worse than if it just displayed in English. As someone you would be trying to help by using current culture for anything, please don't. Please, please, please do the full English imperealism, because you're just making your product worse for us foreginers by respecting local culture in the UI.
     
  32. Dmitriy-Yukhanov

    Dmitriy-Yukhanov

    Joined:
    Jul 27, 2012
    Posts:
    1,025
    @bobdonovan thanks for chime in, please also consider that float.Parse and such should be InvariantCulture too since we all have dozens of config files where dots are used and now all code which reads them is broken on OSes with locales where float separator is comma (just with Vuforia xml configs which they generate on server and which we have to import to the project to set up markers).
     
    bobdonovan likes this.
  33. Kuura

    Kuura

    Joined:
    Apr 16, 2015
    Posts:
    43
    This gets rid of the commas in the editor

    Code (CSharp):
    1. using UnityEngine;
    2. using UnityEditor;
    3. using System.Threading;
    4.  
    5. [InitializeOnLoad]
    6. public class Startup {
    7.     static Startup() {
    8.         Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-us");
    9.     }
    10. }
     
    Nickolauson and Dmitriy-Yukhanov like this.
  34. Dmitriy-Yukhanov

    Dmitriy-Yukhanov

    Joined:
    Jul 27, 2012
    Posts:
    1,025
    Thanks for sharing @Kuura!
    It also fixes the problem with float.Parse().
     
  35. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    339
    AFAIR ReSharper/Rider has warning for not specifying explicit culture in TryParse, Format, ToString methods; it can be configured to be an error.
     
    bobdonovan and Dmitriy-Yukhanov like this.
  36. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    339
    It's better to use CultureInfo.InvarianCulture instead of "en-US" culture.
     
    Dmitriy-Yukhanov likes this.
  37. Dmitriy-Yukhanov

    Dmitriy-Yukhanov

    Joined:
    Jul 27, 2012
    Posts:
    1,025
    The problem is commonly with third-party or built-in code.
    For example, Vuforia Editor assembly has float.Parse without specified Culture:

    Editor\Data\PlaybackEngines\VuforiaSupport\Managed\Editor\Vuforia.UnityExtensions.Editor.dll
    Code (CSharp):
    1. namespace Vuforia.EditorClasses
    2. {
    3.     // Token: 0x02000096 RID: 150
    4.     internal class VuforiaUtilities
    5.     {
    6.         // Token: 0x060003BC RID: 956 RVA: 0x00012220 File Offset: 0x00010420
    7.         public static bool SizeFromStringArray(out Vector2 result, string[] valuesToParse)
    8.         {
    9.             result = Vector2.zero;
    10.             bool flag = false;
    11.             if (valuesToParse != null && valuesToParse.Length == 2)
    12.             {
    13.                 flag = true;
    14.             }
    15.             if (!flag)
    16.             {
    17.                 return false;
    18.             }
    19.             try
    20.             {
    21.                 result = new Vector2(float.Parse(valuesToParse[0]), float.Parse(valuesToParse[1]));
    22.             }
    23.             catch
    24.             {
    25.                 return false;
    26.             }
    27.             return true;
    28.         }
    29. ...
     
    StaffanEk likes this.
  38. bobdonovan

    bobdonovan

    Unity Technologies

    Joined:
    Aug 2, 2017
    Posts:
    3
    Thanks for the feedback everybody. We are considering your valuable input to work out the best and safest solution for 18.3. At this point, having consistency with previous versions' behaviours and making sure that our serialization is fully robust with InvariantCulture everywhere is more important to us than having better locale support.
     
    fherbst likes this.
  39. bobdonovan

    bobdonovan

    Unity Technologies

    Joined:
    Aug 2, 2017
    Posts:
    3
    Good to know. Thanks!
     
  40. zeitweise

    zeitweise

    Joined:
    Aug 12, 2013
    Posts:
    6
    Just as a side note: Using the locale of the user's system is currently breaking shader graph, too.

    This was really irritating because I didn't understand why the shaders were invalid previously. I used Kuura's hot fix and now my shader graph shaders work fine when using floating point.

    P.S. I'm on Mac and these problems appeared first after switching to Net 4.x
     
    Last edited: Sep 21, 2018 at 12:48 PM