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.
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.
@Edy@ZimM_1 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!
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”.
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.
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.
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.
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:
// Should print "December 18, 2016" no matter what.
Debug.Log(string.Format("{0:MMMM d, yyyy}", DateTime.Now));
// Should print the date in the current Unity Editor interface.
// For example, should print "diciembre 18, 2016" for Spanish.
// EditorApplication.defaultCulture is a fictitious property that will return the locale of the Unity Editor.
Debug.Log(string.Format(EditorApplication.defaultCulture, "{0:MMMM d, yyyy}", DateTime.Now));
@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.
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.
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?
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…
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.
