Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    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:
    2,497
    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.
     
    Mikael-H likes this.
  2. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    963
    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:
    6,920
    @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:
    963
  5. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    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:
    6,920
    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:
    963
    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:
    6,920
    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

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    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:
    963
    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:
    380
    Please not like this, not like this. Make this changeable in the editor.
     
    Menion-Leah likes this.
  12. thomak-dev

    thomak-dev

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

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    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:
    16
    I submitted a bug: Case 930798. If you need more info let me know.
     
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

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

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    @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:
    6,920
    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:
    309
    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...
     
    MihaPro_CarX likes this.
  19. StaffanEk

    StaffanEk

    Joined:
    Jul 13, 2012
    Posts:
    380
    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.
     
  20. marcelopaulon

    marcelopaulon

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

    Qbit86

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

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    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:
    963
    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:
    734
    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:
    6,920
    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. codestage

    codestage

    Joined:
    Jul 27, 2012
    Posts:
    1,931
    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:
    6,920
    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 codestage like this.
  28. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    802
    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
     
  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
    serjabc, MihaPro_CarX, Qbit86 and 3 others like this.
  30. bobdonovan

    bobdonovan

    Unity Technologies

    Joined:
    Aug 2, 2017
    Posts:
    14
    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 codestage like this.
  31. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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. codestage

    codestage

    Joined:
    Jul 27, 2012
    Posts:
    1,931
    @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. Muuuuo

    Muuuuo

    Joined:
    Apr 16, 2015
    Posts:
    57
    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. }
     
  34. codestage

    codestage

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

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    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 codestage like this.
  36. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    It's better to use CultureInfo.InvarianCulture instead of "en-US" culture.
     
    gresolio and codestage like this.
  37. codestage

    codestage

    Joined:
    Jul 27, 2012
    Posts:
    1,931
    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:
    14
    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.
     
    Mikael-H and fherbst like this.
  39. bobdonovan

    bobdonovan

    Unity Technologies

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

    zeitweise

    Joined:
    Aug 12, 2013
    Posts:
    7
    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
    OtakuD likes this.
  41. OtakuD

    OtakuD

    Joined:
    Apr 24, 2014
    Posts:
    49
    Yes, took me hours to realise this was the issue as it posted all manner of unrelated errors!
     
    Qbit86 likes this.
  42. gresolio

    gresolio

    Joined:
    Jan 5, 2014
    Posts:
    17
    Code (CSharp):
    1. using System.Globalization;
    2. using System.Threading;
    3. using UnityEngine;
    4. #if UNITY_EDITOR
    5. using UnityEditor;
    6. #endif
    7.  
    8. #if UNITY_EDITOR
    9. [InitializeOnLoad]
    10. public static class FixCultureEditor
    11. {
    12.     static FixCultureEditor()
    13.     {
    14.         Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
    15.     }
    16. }
    17. #endif
    18.  
    19. public static class FixCultureRuntime
    20. {
    21.     [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
    22.     static void FixCulture()
    23.     {
    24.         Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
    25.     }
    26. }
     
    MilenaRocha, skalou, Zottman and 18 others like this.
  43. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    @gresolio Thank you so much! I can't understand why this cannot be fixed in Unity's side.
     
  44. orb

    orb

    Joined:
    Nov 24, 2010
    Posts:
    3,037
    Happy belated 2nd anniversary, stupid locale bug. Why haven't you died from SIDS already?
     
    Menion-Leah likes this.
  45. bobdonovan

    bobdonovan

    Unity Technologies

    Joined:
    Aug 2, 2017
    Posts:
    14
    FYI, this issue is fixed in the latest 2018.3 Beta version. We are now using decimal point everywhere whatever the OS locale is.
     
    codestage likes this.
  46. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Are you referring to a beta that is not released yet? Because...
    upload_2018-12-5_19-26-4.png
     
  47. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,497
    Nandorand, ratking and fherbst like this.
  48. Heavynator

    Heavynator

    Joined:
    Dec 22, 2018
    Posts:
    1
    Just as a heads-up: This also breaks the tutorial "Getting Started 04: Prefab Power - Ramping up".
    In step 13 you need to change the position of the "PushableBox" object, the tutorial wants you to change the Y variable to 2.5, which is impossible because it automatically changes to 2,5 all of the time and doesn't trigger the next step in the tutorial.
    If this bug really exists for 2 years, this is sure to drive off many people that get stuck at the tutorial due to this...
     
  49. Vencarii

    Vencarii

    Joined:
    May 19, 2016
    Posts:
    9
    Also not fixed in 2018.3.5f1 :(
     
    fherbst likes this.
  50. Royall

    Royall

    Joined:
    Jun 15, 2013
    Posts:
    120
    Still broken in 2018.3.6f1