aspnetcore: Localised number format and wrong input type for decimal fields

@javiercn What does that mean, “affected-few”? That most ASP.NET Core users in the world use English number formats? That would be new to me. And what does “severity-minor” mean? That it’s not a blocking issue to not be able to use decimal numbers in forms? That’s a strange ranking app you use there. Must be heavily US-biased.

What about .Net Core 5? Is this fixed?

Bro, It’s only been almost two years. Give them some time to sort this out. Come on man!

@mkArtakMSFT Can you please explain why you believe the question has been answered / the bug has been fixed? I cannot see how this is the case. Please reopen until this has been fixed. In case you didn’t know, there are other regions in the world than those that use a decimal point. And currently I can’t use proper HTML with decimal numbers with ASP.NET Core MVC data binding.

It’s really sad to see this issues is pushed from version to planning to version but never really fixed…

…really Microsoft?!? That’s not how an issue of this gravity of e.g. german speaking world should be treated!

Yep… I thought so^^

See this Gist here: FIX: Localised number format and wrong input type for decimal fields

@mkArtakMSFT Thanks for the update. I’d suggest you put a bold warning in the ASP.NET Core documentation then which says that this product does not support other server environments than English (and few more) and will not for an unspecified time. At least everybody knows what to expect then, and when to look for alternatives.

We’ve moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

FTR, no jQuery validation around here. The problem solely lies in ASP.NET Core.

I’m tired of searching for a permanent solution to this problem in every new project for years. Can you please solve this problem in 7.0-rc1 milestone?

Seems to be an old issue: https://github.com/aspnet/Mvc/issues/2780 https://github.com/aspnet/Mvc/issues/6024

With locals that use comma as the decimal separator, the rendered value in the text input field causes the client-side validation to fail (when using the jQuery validation library that comes with the razor pages project template).

The expectation by the validator is that the browser returns the value as a floating-point number, but since it only does this for type=“number”, it fails the validation.

The issue does not seem to be the client-side validation, however, people do seem to workaround this by hacking the client-side validator: https://weblogs.asp.net/jdanforth/jquery-validate-and-the-comma-decimal-separator

type=“number” fields use invariant culture and we should consider parsing as such in model binding.

@mkArtakMSFT Did you want to reopen this issue?

API review notes:

• Do we need this API at all?
  • If this is just a bug fix, can we get away with using just an AppContext switch?
  • This has been the behavior since before ASP.NET core. We are afraid people rely on the old behavior, and this new API isn’t exactly in your face.

API Approved!

Do we prefer “render” mode over “rendering” mode?

Hm, I really don’t have a preference here. Maybe I like “render” a bit more just because the “ing” doesn’t really add any important information. Totally willing to change my mind though!

I like that idea. What would you name the enum? FormValueFormattingMode?

I think FormInputRenderMode might be good because FormValueFormattingMode doesn’t necessarily represent the fact that this option also controls whether hidden <input name="__Invariant" ... /> elements are generated.

What about the values? InvariantCulture and CurrentCulture?

I’ve chosen DetectCultureFromInputType instead of InvariantCulture because it still might use CurrentCulture for some input types.

And I think AlwaysUseCurrentCulture highlights that while the other option may use CurrentCulture, this one will definitely use it.

Just ran into this.

I did this : <input asp-for="Number" class="form-control" type="number" value="@Model.Number.ToString("N", CultureInfo.InvariantCulture)" />

It is ugly, and I don’t like it, but hey, such is life for we few, we rest-of-the-world, minor-severity-bug-affected few.

// Edit: Just discovered that Number.ToString("F", CultureInfo.InvariantCulture) might be a better option. “N” format adds thousands separators, which also break the number display. “F” does not.

Guys, I have changed my culture’s number format to EN without changing the whole culture, on the client side I’m formatting date, number, currency(using JS library). In the backend I return/receive them in EN as below code function in a base controller: public override void OnActionExecuting(ActionExecutingContext context) { SetCultureNumberFormat(); base.OnActionExecuting(context); } private void SetCultureNumberFormat() { if (CultureInfo.CurrentCulture.Name == “ar”) { var cultureInfo = CultureInfo.CurrentCulture.Clone() as CultureInfo; cultureInfo.NumberFormat = CultureInfo.GetCultureInfo(“en-US”).NumberFormat; CultureInfo.CurrentUICulture = CultureInfo.CurrentCulture = cultureInfo; } }

I am having same problem:

I have this Entity:

namespace Backend.Models
{
    public class Tax
    {
        public int ID { get; set; }

        [Required]
        public string Name { get; set; }

        [Required]
        [Column(TypeName = "decimal(10,3)")]
        public decimal Value { get; set;}

    }
}

When I use scaffold Razor Page using Entity Framework (CRUD) and execute the solution I have this html error:

Location in spanish, decimal is comma separated, because html throw this error saying is not a number.

Also, if I use dot decimal separator the database save a number without decimals:

¿This can be related to this issue?

¿How can I solve this issue?

Thanks in advance.

Experiencing the same issue on latest 3.1 stream of .NET Core. I have German culture, so we use “,” as decimal separator. When I send a decimal value from an input field to the controller, the value “214,50” is sent to the controller. But when mapped to my ViewModel in the controller, the comma is lost and the value 21450 in mapped to my models attribute which is a decimal type…

However, with a piece of old legacy code within the same solution, the mapping works just fine although the setup is exactly the same.

EDIT: I just found out that the error only occurs when I use GET. When I send the data via POST, the binding works just fine.