Runtime: Setting CultureInfo in Startup gives unicode minussign U+2212 in swedish locale

Created on 13 Nov 2020  Â·  23Comments  Â·  Source: dotnet/runtime

`var ci = new CultureInfo("sv-SE") {DateTimeFormat = {ShortDatePattern = "yyyy-MM-dd"} };

        app.UseRequestLocalization(
            new RequestLocalizationOptions()
            {
                SupportedCultures = new List<CultureInfo> { ci },
                SupportedUICultures = new List<CultureInfo> { ci },
                DefaultRequestCulture = new RequestCulture(ci)
            });`

We have this in startup/configure to make sure that the culture is set to swedish in the UI. and it has worked up until we upgraded to .Net 5. Now I have to add NumberFormat = { NegativeSign="-" } to stop it from returning Ascii 8722 as the negative sign.

Discussion area-System.Globalization

All 23 comments

The behaviour has changed but I dont know why and the longer negative sign means something different.

Tagging @tarekgh, @safern, @krwq as subscribed to this area.
See info in area-owners.md if you want to be subscribed.


Issue Details





















Description:

`var ci = new CultureInfo("sv-SE") {DateTimeFormat = {ShortDatePattern = "yyyy-MM-dd"} };

        app.UseRequestLocalization(
            new RequestLocalizationOptions()
            {
                SupportedCultures = new List<CultureInfo> { ci },
                SupportedUICultures = new List<CultureInfo> { ci },
                DefaultRequestCulture = new RequestCulture(ci)
            });`

We have this in startup/configure to make sure that the culture is set to swedish in the UI. and it has worked up until we upgraded to .Net 5. Now I have to add NumberFormat = { NegativeSign="-" } to stop it from returning Ascii 8722 as the negative sign.

Author: johanskoldekrans
Assignees: -
Labels:

area-System.Globalization, untriaged

Milestone: -

Marked regression as its a change in behavior, please remove if it's by design.

I think this is by design? Per CLDR, the _sv_ culture uses U+2212 MINUS SIGN to represent negative numbers.

image

Hmmm, behaviour has at least changed from hyphen-minus to U+2212 in .Net 5. But when we test the site on different computers we get different results. Some get hyphen-minus still and some get minussign. And we have never seen the longer minussign on any sites before and we have been running core since the alpha versions in production.

We have logic coloring negative numbers in our grids with red and positives with blue or black so the results are very obvious.

Running on our IIS we have hyphen-minus. Just checked. Same code.

@johanskoldekrans Are all of your machines running the same OS? Per https://docs.microsoft.com/dotnet/standard/globalization-localization/globalization-icu, .NET 5 will light up this behavior on Win10 May 2019 Update (build 18362) and later. Versions of Windows Client or Windows Server prior to build 18362 will use the older behavior.

You can find your windows build by running __ver.exe__ from the command prompt, or running __winver.exe__ from Start -> Run.

@johanskoldekrans are you storing the data with the negative sign or just you are doing your operations at runtime by displaying and coloring the numbers? I am asking because if you are storing the data, your logic will be already broken as you cannot guarantee such formatting cannot change between OS's and OS versions. Note that, users can customize such negative signs on their machines and you will be broken again if you assume you always have to get -. Our guidelines is always format data using Invariant culture or fixed format you can parse it back with.

If you are using it only during the runtime, you can easily use CultureInfo.NumberFormat.NegativeSign to get it and use it. This should always gives you the sign used on the running machine.

The data is decimals we are formatting with 0:N2 and we should be forcing the culture to sv-SE. The thing is behaviour has changed and we dont know why. We have always had a hyphen minus before. The data is fetched with ef core with our own nuget using 3.1.* code. Could that interfere?


Från: Tarek Mahmoud Sayed notifications@github.com
Skickat: Sunday, November 15, 2020 8:18:05 PM
Till: dotnet/runtime runtime@noreply.github.com
Kopia: Johan Sköldekrans johan.skoldekrans@penser.se; Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

@johanskoldekranshttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjohanskoldekrans&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886482777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BmIBbBzkjSfsLmD9cgEzpVE1U8MpY80iVIzoCb%2B6DY8%3D&reserved=0 are you storing the data with the negative sign or just you are doing your operations at runtime by displaying and coloring the numbers? I am asking because if you are storing the data, your logic will be already broken as you cannot guarantee such formatting cannot change between OS's and OS versions. Note that, users can customize such negative signs on their machines and you will be broken again if you assume you always have to get -. Our guidelines is always format data using Invariant culture or fixed format you can parse it back with.

If you are using it only during the runtime, you can easily use CultureInfo.NumberFormat.NegativeSign to get it and use it. This should always gives you the sign used on the running machine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F44678%23issuecomment-727621774&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886482777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vH9j9wnzYrBGuFjFutgvpUO%2By%2F1V2Pwb22IuKpf1L%2BY%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOVHC5RXL7EPQQUAJV7TO3SQASO3ANCNFSM4TVIQQZQ&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886492734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b7xchDH%2F0A3Sd7vBCOhI7WgJg6DC44L%2B0kY8koCNDXA%3D&reserved=0.

And another thing is that it looks awful. I have never seen anywhere on a swedish site with long minus sign. We always use hyphen-minus. So it is very strange. Unless we subtract and want to show the difference between the subtracting minus and the negative value.


Från: Johan Sköldekrans johan.skoldekrans@penser.se
Skickat: Sunday, November 15, 2020 8:22:17 PM
Till: dotnet/runtime reply@reply.github.com; dotnet/runtime runtime@noreply.github.com
Kopia: Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

The data is decimals we are formatting with 0:N2 and we should be forcing the culture to sv-SE. The thing is behaviour has changed and we dont know why. We have always had a hyphen minus before. The data is fetched with ef core with our own nuget using 3.1.* code. Could that interfere?


Från: Tarek Mahmoud Sayed notifications@github.com
Skickat: Sunday, November 15, 2020 8:18:05 PM
Till: dotnet/runtime runtime@noreply.github.com
Kopia: Johan Sköldekrans johan.skoldekrans@penser.se; Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

@johanskoldekranshttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjohanskoldekrans&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886482777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BmIBbBzkjSfsLmD9cgEzpVE1U8MpY80iVIzoCb%2B6DY8%3D&reserved=0 are you storing the data with the negative sign or just you are doing your operations at runtime by displaying and coloring the numbers? I am asking because if you are storing the data, your logic will be already broken as you cannot guarantee such formatting cannot change between OS's and OS versions. Note that, users can customize such negative signs on their machines and you will be broken again if you assume you always have to get -. Our guidelines is always format data using Invariant culture or fixed format you can parse it back with.

If you are using it only during the runtime, you can easily use CultureInfo.NumberFormat.NegativeSign to get it and use it. This should always gives you the sign used on the running machine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F44678%23issuecomment-727621774&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886482777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vH9j9wnzYrBGuFjFutgvpUO%2By%2F1V2Pwb22IuKpf1L%2BY%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOVHC5RXL7EPQQUAJV7TO3SQASO3ANCNFSM4TVIQQZQ&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Ca950566faa284e61094808d8899b2e8b%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410646886492734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b7xchDH%2F0A3Sd7vBCOhI7WgJg6DC44L%2B0kY8koCNDXA%3D&reserved=0.

@johanskoldekrans

The data is decimals we are formatting with 0:N2 and we should be forcing the culture to sv-SE.

Ok, so why you cannot use CultureInfo.NumberFormat.NegativeSign to color such numbers? why you want assume - should be always the sign? what happen if the user changed that in the settings to something very different?

The thing is behaviour has changed and we dont know why.

@GrabYourPitchforks pointed before that is is the Unicode Standard (which is called CLDR). .NET is just using the data provided by the standard. We are not hardcoding any of such values.

The data is fetched with ef core with our own nuget using 3.1.* code. Could that interfere?

as long as you read the data as numbers, then the issue is scoped on how you display it and that will depend in the version of the OS/.NET you are running on.

And another thing is that it looks awful. I have never seen anywhere on a swedish site with long minus sign. We always use hyphen-minus. So it is very strange. Unless we subtract and want to show the difference between the subtracting minus and the negative value.

I am seeing this issue is already reported to CLDR https://unicode-org.atlassian.net/browse/CLDR-10779?jql=text%20~%20%22sv%20minus%20sign%22. So you are not alone here.

Ok, great. So it is an issue? Because we have used that code since all versions of net core. Including pre 1.0 so it is strange it just changed bahaviour without any mention in the docs.


Från: Tarek Mahmoud Sayed notifications@github.com
Skickat: Sunday, November 15, 2020 8:36:22 PM
Till: dotnet/runtime runtime@noreply.github.com
Kopia: Johan Sköldekrans johan.skoldekrans@penser.se; Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

@johanskoldekranshttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjohanskoldekrans&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C5cfd3d3f89524171e81308d8899dbc40%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410657859085590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2mCDceCOhDeeGi0diyjAjRg14vmZD39jFouooq3Qka4%3D&reserved=0

The data is decimals we are formatting with 0:N2 and we should be forcing the culture to sv-SE.

Ok, so why you cannot use CultureInfo.NumberFormat.NegativeSign to color such numbers? why you want assume - should be always the sign? what happen if the user changed that in the settings to something very different?

The thing is behaviour has changed and we dont know why.

@GrabYourPitchforkshttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGrabYourPitchforks&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C5cfd3d3f89524171e81308d8899dbc40%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410657859095549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zPeoZH1cjLmWYWD5EiMbZ6972rcUrRgDnFCIdkNzUqs%3D&reserved=0 pointed before that is is the Unicode Standard (which is called CLDR). .NET is just using the data provided from the standard. We are not hardcoding any of such values.

The data is fetched with ef core with our own nuget using 3.1.* code. Could that interfere?

as long as you read the data as numbers, then the issue is scoped on how you display it and that will depend in the version of the OS/.NET you are running on.

And another thing is that it looks awful. I have never seen anywhere on a swedish site with long minus sign. We always use hyphen-minus. So it is very strange. Unless we subtract and want to show the difference between the subtracting minus and the negative value.

I am seeing this issue is already reported to CLDR https://unicode-org.atlassian.net/browse/CLDR-10779?jql=text%20~%20%22sv%20minus%20sign%22https://eur04.safelinks.protection.outlook.com/?url=https:%2F%2Funicode-org.atlassian.net%2Fbrowse%2FCLDR-10779%3Fjql%3Dtext%2520~%2520%2522sv%2520minus%2520sign%2522&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C5cfd3d3f89524171e81308d8899dbc40%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410657859095549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ladueo1QW%2BlYWBIYXRWGrzcgSo76i6dTa0UdWFHHRgE%3D&reserved=0. So you are not alone here.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F44678%23issuecomment-727624299&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C5cfd3d3f89524171e81308d8899dbc40%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410657859105505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wypM1CKzCkqBmYH8cVdVs8tnCQrrlKfEVRCiTU03W3Q%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOVHCZ5FMUX4KHCRX3IPETSQAUTNANCNFSM4TVIQQZQ&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C5cfd3d3f89524171e81308d8899dbc40%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410657859105505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nry4wNhVpU7RQ2j5hwmFx2VMsYQPDL%2Bkp2UdcCqgIMo%3D&reserved=0.

Ok, great. So it is an issue? Because we have used that code since all versions of net core. Including pre 1.0 so it is strange it just changed bahaviour without any mention in the docs.

It is CLDR issue. if CLDR do anything there it will reflect on .NET. As I mentioned this is the Unicode standard and .NET want to stick with the standard. I would suggest you need to fix your code. As I pointed before you were just lucky were not broken before that. Assuming - all the time is not correct and you need to use CultureInfo.NumberFormat.NegativeSign for displaying.
by the way, does your app/library work with Swedish culture only? or it can work with any culture? I am asking because there are other cultures not using - as negative sign already. how did you handle such cases before?

I am not assuming anything. I have been coding since the mid 80s and have never seen this in any code language ever. This is a swedish application for swedes in swedish and if you have started to implement cldr which have a faulty unicode description not just for sweden. You are complaining about our implementation? We are not just lucky. It has never been an issue. You have implemented it correctly before and it seems you are unlucky for using a source that is incorrect.

Just make sure the windows dev team doesnt implement this for the regional settings as well. Or maybe the are also lucky that they have used the correct sign before?

This is a very strange approach you have taken. All we wondered was if this is a non documented breaking change or not. Clearly there seems to be a difference if you set the culture specifically or if the application takes the culture from the client. Then all is ok. The only way to get the wrong sign is to set the culture application wide in the startup. So it also seems to be a difference in how the application behaves which probably isnt best.


Från: Tarek Mahmoud Sayed notifications@github.com
Skickat: Sunday, November 15, 2020 9:34:47 PM
Till: dotnet/runtime runtime@noreply.github.com
Kopia: Johan Sköldekrans johan.skoldekrans@penser.se; Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

Ok, great. So it is an issue? Because we have used that code since all versions of net core. Including pre 1.0 so it is strange it just changed bahaviour without any mention in the docs.

It is CLDR issue. if CLDR do anything there it will reflect on .NET. As I mentioned this is the Unicode standard and .NET want to stick with the standard. I would suggest you need to fix your code. As I pointed before you were just lucky we were not broken before that. Assuming - all the time is not correct and you need to use CultureInfo.NumberFormat.NegativeSign for displaying.
by the way, does your app/library work with Swedish culture only? or it can work with any culture? I am asking because there are other cultures not using - as negative sign already. how did you handle such cases before?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F44678%23issuecomment-727632268&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Cc7c488544e564629fe2c08d889a5e587%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410692901553345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kqpgW9W9PfewZE0luYUGNdYAvzTxuTFobPm8tw2YEdA%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOVHC23BYXOLNSOUUCXEO3SQA3OPANCNFSM4TVIQQZQ&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7Cc7c488544e564629fe2c08d889a5e587%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410692901553345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OEkVidXHuC0mD42pBb0Th43eUGjVM6hVjKPkiiPzmMs%3D&reserved=0.

You are complaining about our implementation?

I am not really complaining about your implementation. don't get me wrong here. what I am trying to say you had some assumption (that negative sign never change) which was not accurate. I am not really blaming anyone here. I am trying to explain what went wrong.

It has never been an issue. You have implemented it correctly before and it seems you are unlucky for using a source that is incorrect.

Actually we always picking up that from the OS. .NET isn't carrying such data. I cannot judge if CLDR is correct or incorrect. This handled by the standard guys who have the experts looking at such issues and decide what every locale should have what properties.

Just make sure the windows dev team doesnt implement this for the regional settings as well. Or maybe the are also lucky that they have used the correct sign before?

Windows currently in the process of converging to CLDR too. I am not seeing Windows changed this till now but I am not even sure if they will do as part of this process. Note that the ICU library we are using (which return such new negative sign), is a Windows component now and would be recommended for usage by Windows team. Please look at Windows blog talking about that converging https://docs.microsoft.com/en-us/archive/blogs/shawnste/locale-data-in-windows-10-cldr.

All we wondered was if this is a non documented breaking change or not.

We have documented breaking change here https://docs.microsoft.com/en-us/dotnet/core/compatibility/globalization. It would be hard to list every single difference there. but if this can help you we can list this specific case.

Clearly there seems to be a difference if you set the culture specifically or if the application takes the culture from the client

As I pointed we provide the properties to know what negative sign used in such environment. So it doesn't matter the source of the culture more than how you handle it.

Last, we are really trying to help here. NET Core has been running on Linux for many years too and using ICU there with such data. Windows also converging to CLDR too. Let's know what is your ask? The CLDR issue is already tracked by CLDR. We have suggested the way to fix this issue by some change from your side. let's know if this not working or facing any other issue. Also, the doc https://docs.microsoft.com/en-us/dotnet/standard/globalization-localization/globalization-icu mentioning the config switch you can use to switch back to use Windows NLS instead of ICU but as I mentioned, Windows can decide to change this part of the data, so I am not sure if they will do that.

@tarekgh Might it help if we add a link to the CLDR table above to the globalization docs? It's not a workaround, but it could serve as a authoritative source to say "this is why you're seeing this behavior; it's coming from this row in the data."

@GrabYourPitchforks I think this will be a good idea.

CC @safern

Update the docs so we know you have implemented CLDR instead. And just close this.


Från: Tarek Mahmoud Sayed notifications@github.com
Skickat: Monday, November 16, 2020 1:17:29 AM
Till: dotnet/runtime runtime@noreply.github.com
Kopia: Johan Sköldekrans johan.skoldekrans@penser.se; Mention mention@noreply.github.com
Ämne: Re: [dotnet/runtime] Setting CultureInfo in Startup gives unicode negativesign instead of normal ascii (#44678)

@GrabYourPitchforkshttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGrabYourPitchforks&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C9053e251ac3e4314e8cb08d889c501f2%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410826521284367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=slwTB%2FZu%2FuyFCYZ%2B0J7qM2adlpvtAq%2Bk%2Fw4MAGftAp0%3D&reserved=0 I think this will be a good idea.

CC @safernhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsafern&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C9053e251ac3e4314e8cb08d889c501f2%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410826521284367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UgPfNfpcZFHW2GKoqpshwL7kA24YChHmEK91ypgDCAA%3D&reserved=0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F44678%23issuecomment-727663886&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C9053e251ac3e4314e8cb08d889c501f2%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410826521294321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zkVDYrfwadI70ey4WtPmMhClTkZ8UP%2FXIKl126agnzw%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOVHCYECBBE4KU7UXZTRH3SQBVRTANCNFSM4TVIQQZQ&data=04%7C01%7Cjohan.skoldekrans%40penser.se%7C9053e251ac3e4314e8cb08d889c501f2%7Cf31efac722714527a63f77f75bdeeb4a%7C0%7C0%7C637410826521294321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kBczPHriB7HD%2B6Wb2rOrGlfxFF147%2FiPXopIHoXmb%2BM%3D&reserved=0.

BTW I am using windows version 19042.630 so that could be why I am seeing this and some devs don't. This is all very strange. As the issue stated on CLDR we dont even have this on our keyboards.

I have been working in development for banks here in Sweden now for over twenty years so I browsed all of our applications and all of our competition and all are using the same hyphen-minus. Of course something called minussign is probably what some burecreat seems like the correct choice but practically this has never been used in the real world.

My regional settings is still correct though. And we have different interpretation from us- and british english that we never had to take into account.

Without mentioning anything about why, I showed som bankers where I work some new blazor-pages, just to see how they reacted. Before anything else they asked why the negative numbers had the strange sign. We are early adopters of your tech and we really like all the changes, hard work and effort that has gone into .Net Core and now .Net 5. But this is just wrong. It would be the same if you all of a sudden saw this unexpected change in US locale.

BTW I am using windows version 19042.630 so that could be why I am seeing this and some devs don't.

Another reason might be that new CultureInfo("sv-SE") applies user overrides only if "sv-SE" matches the locale of the user account in Windows. new CultureInfo("sv-SE", useUserOverride: false) could make the result more consistent between devs.

@johanskoldekrans thanks for all feedback. I hope you can enforce your opinion to the CLDR. It will be good to have someone from the country give feedback to them especially the point that the keyboard don't have this character.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jkotas picture jkotas  Â·  3Comments

EgorBo picture EgorBo  Â·  3Comments

aggieben picture aggieben  Â·  3Comments

chunseoklee picture chunseoklee  Â·  3Comments

btecu picture btecu  Â·  3Comments