runtime: Provide localization for default error messages in System.ComponentModel.Annotations

We have no plans to add additional functionality to data annotations.

@ajcvickers Do you have any update on that matter? It seems to effectively be a special case here, but an important one IMO. The validation messages are always (almost) displayed to the end users, not being able to provide localized ones is kind of a road blocker here.

Sure there are other options such as inheriting the attribute and customizing the error message, but it’s not as clean and efficient.

In my opinion most answers are from a very ignorant and arrogant point of view. “America first”, so it is enough that validation messages are in english, who cares for the rest of the world? Is it really that difficult to specify a different resource file? Like “.AddDataAnnotationsLocalization(loc => loc.UseThisFile(…))”. All messages are already inside a resource file, so it should be easy to replace it during runtime.

Thanks @karelz. I agree with not localizing in general–I’m very happy that we have got there. However, maybe data annotations is special since these messages are intended for customers. I will talk to @divega about it.

FYI: We’re probably localizing the BCL.

@terrajobst So the exceptions are going to be localized in the end? 😦 Are there any plans to do something like what was suggested here? Maybe programmatic or opt-in/out?

Just for the record, this breaks the validation story of UI frameworks like WPF and WinForms, which rely on the exception messages to be readable to the end user.

Hello,

I tried many things in order to translate common validation messages and finnaly I got a good solution (which is working in Dot.Net Core 2.2 and 3). I want to share my solution. Addittionally I want that any one check my code if I broke any internals or doing bad things by mistake.

I forked the official ASPNetCore Movie project and added my solution on branch localize-dataannotations.

Commit #2fd8907 was my first try which I used the solution from @audacity76 (see: https://github.com/aspnet/Localization/issues/286#issuecomment-257828296 ).

But that was the wrong way because Internal components (from MS) was used. In Dot.Net 3 the code is no longer working because the adapter class’s are sealed and cannot be inherited.

With commit #ee12381 and #238bfe1 I found a solution wich works.

There I deleted the class’s which has been inherited from the sealed one’s (LocalizedRequiredAttributeAdapter and LocalizedStringLengthAttributeAdapter).

For debugging I used the form “~/Movies/Edit/1” and the field “Genre”.

---

By the way I want to explain why I have to avoid the recommended workaround by manually touch each attribute and set the resource key + file in each attribute.

We want to build a new plattform for internal applications. The new framework should be an improvement of the current one. One of the most important requirements is a very good maintainability.

My current role is to survey the Dot.Net Core environment for this purposes. I’m a big fan of C# and Dot.Net Core but other in the team have doubts.

Now my problem is that I cannot go to my collegues and tell them that we should use Dot.Net Core when basic things like localization of validation messages are not working in an easy way. They will (and have already) ask me why MS did not add localization in version 3.0. I cannot explain it too.

The recommended workaround from you is not good because our most important requirement “maintainability” is decreased a lot. On the top it will increase mistakes by careless. Models which are generated and decoreated with dataannotations (like from the ef-core scaffold) must be touched manually.

I realy want to use DotNetCore. So an easy to use solution is high priority.

@danstur @danmosemsft Note that this issue is not about localization of general exception messages from this code. This is instead specifically about providing localization for the error messages that come from the validation system, such as “‘Foo’ is a required value.”. The way validation works makes it much more likely that these will be exposed to a non-technical end-user than is the case for more framework exception messages.

I am actually strongly opposed to localization of exception messages in general, for basically the same reason as @danstur states. The first thing many developers do with a message is google for it. Localized exception messages are horrible for that, so localizing the messages makes things more difficult for developers, which is their primary reason for existence.

@divega Whatever you do please make that behaviour optional. Translating technical messages like exceptions or model validation errors is awful for developers that have to support users across the globe and prefer analysing error logs without Hungarian or Chinese messages intermixed.

A good UI shouldn’t show these messages to the user anyhow.

Well, apparently that has already begun. I was the one to open this issue and I hope I haven’t created a monster. As @os1r1s110 said:

The validation messages are always (almost) displayed to the end users, not being able to provide localized ones is kind of a road blocker here.

And that is true.

However, I’ve noticed that since ASP.NET Core 2.2, kestrel messages seems to be translated as well (they appear translated on the console when debugging), which is awful.

Let’s be very clear here: validation messages which are displayed to the final UI being translated is one thing; logging, exception and just everything else is another thing entirely. In fact, I think that if you keep going on this route, you should not only make it optional, but more specifically make it opt in.

Translated technical messages never really help no one. Even beginners. In fact, I think it may make their life harder, since obviously there’s way more content in English than any other language. When I started programming, I always had to first search for the exception message in english and then search about the exception itself. It’s not a very pleasant experience. There are times when two exceptions had similar texts and I ended up losing time just searching for their english equivalent. And no, it’s not just as easy as translating back, because of course a sentence can be translated in various different ways. And to make it worse, much of the time the messages aren’t simply translated - they’re localized, which makes it even harder to translate back.

@divega Whatever you do please make that behaviour optional. Translating technical messages like exceptions or model validation errors is awful for developers that have to support users across the globe and prefer analysing error logs without Hungarian or Chinese messages intermixed.

A good UI shouldn’t show these messages to the user anyhow.

It really makes big sense to allow Data annotations messages to be localized. Honestly, what is the purpose to create an error handling layer for “validation messages” while there’s already a validation layer on classes ?

When I write this

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

It is expected that the validation message is poped up for the user with localization.

@ajcvickers So basically, the built-in validation attributes are useless. Don’t use them! Ever! Instead, create your own attributes that provide a decent feature set, like localisation of the messages. Either do it in your own project or build, share and use a NuGet package that replaces the entirely broken validation attributes. They’re just wasted space in a project deployment. I’ve tried several things but wasn’t able to get localised messages working. I can set a message programmatically – either once and the same for all subsequent requests, or as static property with no access to the current request’s language. This is a very frustrating situation. The documentation should really contain a huge warning that says that the BCL validation attributes are a dumb stub and should never used for real applications because they cannot support multilingual UIs.

PS: I’m not interested in prelocalised texts from Microsoft. The default texts are bad already. For example they include the model property name, a technical term defined by a programmer (which isn’t even necessary because the message will appear directly under the relevant input field anyway, that proximity is much better than making the user search and compare strings across the page), and that’s quoted in typewriter marks (Americans won’t see much of a difference), pretty ugly to look at. These default messages just cannot be presented to a user, so I have to provide my own messages. I’m happy to do that, but there’s not even an interface to allow that. That’s the issue. The entire API does not allow per-request localisation.

That’s a fair point. FYI: We’re probably localizing the BCL.

@danmosemsft Having one global issue where we could voice concerns about localising developer facing strings would be great.

Because as seen here if someone provided a PR with translations there’s a good chance this would be included without bigger input by the community.

If people have valid use cases for translating these messages I’m certainly not against it. But as someone who has to deal with translated exception messages when analysing bugs I want a programmatic, offline ability to get the English exception messages or model validation errors. The full framework approach simply doesn’t work very well for those of us that have global user bases.

Considering that virtually no other language translates their exceptions should also hint that the value of doing so is far from universally recognised.

@ajcvickers It is not common to use custom strings. For basic things like Field xxx is required the message is evident enough. And in most cases is used just as is. So for all the people not living in English speaking nations or working on multilanguage products there should be an option for translation. I am actually sad to see issues dating back 2 years to fix this and nothing has been done in this time.