aspnetcore: Ability to translate all DataAnnotations without having to specify ErrorMessage

Currently, ValidationAttributeAdapterOfTAttribute.GetErrorMessage uses IStringLocalizer only when ErrorMessage is set:

protected virtual string GetErrorMessage(ModelMetadata modelMetadata, params object[] arguments)
{
    if (modelMetadata == null)
    {
        throw new ArgumentNullException(nameof(modelMetadata));
    }

    if (_stringLocalizer != null &&
        !string.IsNullOrEmpty(Attribute.ErrorMessage) &&
        string.IsNullOrEmpty(Attribute.ErrorMessageResourceName) &&
        Attribute.ErrorMessageResourceType == null)
    {
        return _stringLocalizer[Attribute.ErrorMessage, arguments];
    }

    return Attribute.FormatErrorMessage(modelMetadata.GetDisplayName());
}

The consequence is that you have to set the ErrorMessage property each time you want to translate an error message.

Suppose you just want to translate the default RequiredAttribute ErrorMessageString, which is The {0} field is required. for all your Model classes.

  1. You must override the default DataAnnotationLocalizerProvider to return a shared resource.
  2. You add a generic entry named, for example, “DataAnnotations_Required” with the translated value format: Le champ {0} doit être renseigné.
  3. You must replace all the [Required] attributes with [Required(ErrorMessage = "DataAnnotations_Required")]

More generally, there is no way to just adapt the generic DataAnnotation validation messages to your language. (the ones in System.ComponentModel.Annotations.SR.resources) without having to replace all your data annotations.

The documentation only provide a sample where the messages are customized for each property (despite the fact that only the property name change).

There is no easy workaround either:

  • You can’t inherit from RequiredAttribute to fix the ErrorMessage property, since the framework uses strict type comparison
  • Replacing the default ValidationAttributeAdapterProvider is not trivial, because you have to replace all adapters with custom ones to override the GetErrorMessage method.

Is there a better way to achieve localization for all default data annotation error messages ? Or room for improvement in asp.net core mvc to reduce the burden of writing all this custom code ?

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 42
  • Comments: 29 (10 by maintainers)

Most upvoted comments

Thanks for contacting us.

We’re moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it’s very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Any updates on this one? It’s very critical for large applications…

Inspired by this old blog post, and similarly to what proposed vjacquet, I ended up with an IValidationMetadataProvider that uses a ressource file to get the correct translation according to the current language.

This can be combined with the model binding message provider as described at the end of this paragraph.

You just have to declare it like this in your Startup.cs

services
    .AddControllersWithViews(o =>
    {
        o.ModelBindingMessageProvider.SetAttemptedValueIsInvalidAccessor((value, fieldname) =>
            /* provide your own translation */
            string.Format("Value {0} for field {1} is incorrect", value, fieldname));
        // and do the same for all the Set*Accessor...

        o.ModelMetadataDetailsProviders.Add(new MetadataTranslationProvider(typeof(Resources.DataAnotation)));
        //                                                                          ^^ this is the resx ^^
    })

You just have to create a resx file (with designer) in which key is the attribute type name. Here its called Resources.DataAnotation.

image

// Inspired from https://blogs.msdn.microsoft.com/mvpawardprogram/2017/05/09/aspnetcore-mvc-error-message/
public class MetadataTranslationProvider : IValidationMetadataProvider
{
    private readonly ResourceManager _resourceManager;
    private readonly Type _resourceType;

    public MetadataTranslationProvider(Type type)
    {
        _resourceType = type;
        _resourceManager = new ResourceManager(type);
    }

    public void CreateValidationMetadata(ValidationMetadataProviderContext context)
    {
        foreach (var attribute in context.ValidationMetadata.ValidatorMetadata)
        {
            if (attribute is ValidationAttribute tAttr)
            {
                // search a ressource that corresponds to the attribute type name
                if (tAttr.ErrorMessage == null && tAttr.ErrorMessageResourceName == null)
                {
                    var name = tAttr.GetType().Name;
                    if (_resourceManager.GetString(name) != null)
                    {
                        tAttr.ErrorMessageResourceType = _resourceType;
                        tAttr.ErrorMessageResourceName = name;
                        tAttr.ErrorMessage = null;
                    }
                }
            }
        }
    }
}

This is a huge problem because it impact even some small hello world project that is not made inside the USA. if you are in any country that don’t speak english and you create a simple mvc web project, you get all the messages in english wihout any easy way to provide translations. nothing works. no nuget packages, no resx files to download, to install, no classes to implement. nothing works. and it is just the start of hello world project. How this is not solved yet?

Still no simple solution for this huge problem?

In MVC5 and lower, it was really easy to make the validation work in other language. Just publish your website with the right resources files that came from Microsoft and you were good.

  • \fr\System.ComponentModel.DataAnnotations.resources.dll
  • \fr\System.Web.Mvc.resources.dll
  • \fr\EntityFramework.resources.dll

With MVC Core 2.1, if i want to localize the error messages from DataAnnotations and MVC libraries, i need to:

  • Use the ErrorMessage property on each DataAnnotations validation attribute to tell them the resource key to use. By doing this, it also require me to create an english resource file and define all validation error messages that is already present in original library (weird).
  • Change all ModelBindingMessageProvider properties to support my languages like so:
services.AddMvc(options =>
    {
        options.ModelBindingMessageProvider.SetValueIsInvalidAccessor(x => $"The value '{x}' is invalid.");
        options.ModelBindingMessageProvider.SetValueMustBeANumberAccessor(x => $"The field {x} must be a number.");
        options.ModelBindingMessageProvider.SetMissingBindRequiredValueAccessor(x => $"A value for the '{x}' property was not provided.");
        options.ModelBindingMessageProvider.SetAttemptedValueIsInvalidAccessor((x, y) => $"The value '{x}' is not valid for {y}.");
        options.ModelBindingMessageProvider.SetMissingKeyOrValueAccessor(() => "A value is required.");
        options.ModelBindingMessageProvider.SetUnknownValueIsInvalidAccessor(x => $"The supplied value is invalid for {x}.");
        options.ModelBindingMessageProvider.SetValueMustNotBeNullAccessor(x => $"The value '{x}' is invalid.");
        options.ModelBindingMessageProvider.SetMissingRequestBodyRequiredValueAccessor(() => "A non-empty request body is required.");
        options.ModelBindingMessageProvider.SetNonPropertyAttemptedValueIsInvalidAccessor(x => $"The value '{x}' is not valid.");
        options.ModelBindingMessageProvider.SetNonPropertyUnknownValueIsInvalidAccessor(() => "The supplied value is invalid.");
        options.ModelBindingMessageProvider.SetNonPropertyValueMustBeANumberAccessor(() => "The field must be a number.");
    })

The problem with that?

  • When Core 2.0 came out, 4 new validation messages were added to the framework (MissingRequestBodyRequiredValueAccessor, NonPropertyAttemptedValueIsInvalidAccessor, NonPropertyUnknownValueIsInvalidAccessor and NonPropertyValueMustBeANumberAccessor) . We have to be very careful and search for new strings to localize by our own each time we upgrade the framework.

My thought on this is if the library has messages that is intended to be used in UI like the RequiredAttribute, RangeAttribute, etc, the library should come localized by the owner (Microsoft). If i want to override the messages, i can do it with my own resource files.

You are right. In my case there was no satellite resource assembly loaded, so resources were always returned in English. Despite that, perhaps the ValidationAttributeAdapterProvider could, at least, be enhanced to match sub-classes. So we could create a custom LocRequiredAttribute : RequiredAttribute class with a fixed ErrorMessage set.

One additional point to take into consideration: some validation messages are obtained through DefaultModelBindingMessageProvider, and there is an opportunity to translate them using MvcOptions and Set...Accessor() methods. eg. SetValueMustBeANumberAccessor used to display validation error for numbers.

This part is never addressed in the documentation and I discovered it only by chance.

It seems there are some inconsistencies or, at least, some rough edges regarding localization & model binding in asp.net core for now. I don’t know how exactly they could be solved…

Thanks for contacting us.

We’re moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it’s very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

The ones who works with localization knows that it is not only DataAnnotation which needs to be translated/localizaed, additionally there is ModelBinding and IdentityDescriber errors as well, and each requires different solution.

I know that most developers prefer official solutions, but sometimes the wait is too long 😃 So, recently I’ve developed a nuget package (XLocalizer) that makes it so easy to localize all validation messages in startup or in json file.. Additionally it supports online translation and auto resource creating as well.

@Eilon

unfortunately the problem is that the built-in data annotations will return already-localized resources if the right resources are installed on the system (via NuGet, or in .NET Framework).

Is there any NuGet package that provides default texts translated in any other languages? I can’t find any…

I have an app, hosted in Azure, that can be in FR or EN. I only receive english data annotation messages when deployed on Azure. But I would like to have a NuGet providing FR translations for “The field {0} is required” that could be deployed with my app.

Data Annotations can be used independently from MVC (for example if you’re using console apps or minimal api’s).

You want to be able to plugin a translation mechanism directly into Data Annotations. Whatever will be done for this (once it eventually get’s picked up), please don’t just limit it to MVC only.

As a workaround for the the original DataAnnotations issue, I implemented a IValidationMetadataProvider using the following code

public void CreateValidationMetadata(ValidationMetadataProviderContext context)
{
    var query = from a in context.Attributes.OfType<ValidationAttribute>()
                where string.IsNullOrEmpty(a.ErrorMessage)
                   && string.IsNullOrEmpty(a.ErrorMessageResourceName)
                select a;
    foreach (var attribute in query)
    {
       var message = attribute switch
       {
           RegularExpressionAttribute regularExpression => "The field {0} must match the regular expression '{1}'.",
           MaxLengthAttribute maxLength => "The field {0} must be a string or array type with a maximum length of '{1}'.",
           CompareAttribute compare => "'{0}' and '{1}' do not match.",
           MinLengthAttribute minLength => "The field {0} must be a string or array type with a minimum length of '{1}'.",
           RequiredAttribute required => @"The {0} field is required.",
           StringLengthAttribute stringLength when stringLength.MinimumLength == 0 => "The field {0} must be a string with a maximum length of {1}.",
           StringLengthAttribute stringLength => "The field {0} must be a string with a minimum length of {2} and a maximum length of {1}.",
           RangeAttribute range => "The field {0} must be between {1} and {2}.",
           // EmailAddressAttribute
           // PhoneAttribute
           // UrlAttribute
           // FileExtensionsAttribute
           _ => null
       };
       if (message != null)
           attribute.ErrorMessage = message;
    }
}

Validation attributes in comments already works when the ErrorMessage is empty because they set the internal DefaultErrorMessage in their constructor.

Modifying the attribute when discovering the metadata is not satisfactory but now that the ErrorMessage is always set, the stringlocalizer is always called.

But I wonder if the issue could not simply be fixed by the attribute adapters: instead of ignoring attribute with an empty ErrorMessage, couldn’t the GetErrorMessage simply call the stringlocalizer with a literal default error message?

In ValidationAttributeAdapterOfTAttribute, add a protected virtual string “DefaultErrorMessage” Then remove the line https://github.com/dotnet/aspnetcore/blob/cc96e988f491375fa8e29fc42d558303d5b131f3/src/Mvc/Mvc.DataAnnotations/src/ValidationAttributeAdapterOfTAttribute.cs#L75

And replace line https://github.com/dotnet/aspnetcore/blob/cc96e988f491375fa8e29fc42d558303d5b131f3/src/Mvc/Mvc.DataAnnotations/src/ValidationAttributeAdapterOfTAttribute.cs#L79 by

return _stringLocalizer[!string.IsNullOrEmpty(Attribute.ErrorMessage) ? Attribute.ErrorMessage : DefaultErrorMessage, arguments];

Then, for instance, in the RequiredAttributeAdapter, override the DefaultErrorMessage as protected override string DefaultErrorMessage => “The {0} field is required.”;

For now, this code would only work for the client validation. To make it work also when using the IObjectModelValidator, you’d have to call GetErrorMessage in the Validate method DataAnnotationsModelValidator whether Attribute.ErrorMessage is set or not, i.e. by removing the line https://github.com/dotnet/aspnetcore/blob/c836a3a4d7af4b8abf79bd1687dae78a402be3e9/src/Mvc/Mvc.DataAnnotations/src/DataAnnotationsModelValidator.cs#L100

Is System.ComponentModel.DataAnnotations for .NET Core available anywhere on Github? I could only find: System.ComponentModel.DataAnnotations namespace but this is old .NET Framework reference code.

By far the simplest solution to this issue would be to:

  1. Copy DataAnnotationsResources.resx into DataAnnotationsResources.{lang}.resx.
  2. Translate ~60 default messages.
  3. Make pull request.
  4. Satellite assembly {lang}/System.ComponentModel.DataAnnotations.resources.dll assembly with proper public key signature can be generated.
  5. Perhaps download satellite assembly separately via NuGet?

As someone already mentioned, there is no easy way around the fact that default messages are hardcoded in each attribute’s constructor. At least, they are hard-coded to point to internal DataAnnotationsResources.resx file.

For example:

namespace System.ComponentModel.DataAnnotations {
    /// <summary>
    /// Validation attribute to indicate that a property field or parameter is required.
    /// </summary>
    [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Parameter, AllowMultiple = false)]
    [SuppressMessage("Microsoft.Performance", "CA1813:AvoidUnsealedAttributes", Justification = "We want users to be able to extend this class")]
    public class RequiredAttribute : ValidationAttribute {
        /// <summary>
        /// Default constructor.
        /// </summary>
        /// <remarks>This constructor selects a reasonable default error message for <see cref="ValidationAttribute.FormatErrorMessage"/></remarks>
        public RequiredAttribute()
            : base(() => DataAnnotationsResources.RequiredAttribute_ValidationError) {
        }

Also, there is no easy way around fallback logic in ValidationAttributeAdapter<TAttribute>:

        /// <summary>
        /// Gets the error message formatted using the <see cref="Attribute"/>.
        /// </summary>
        /// <param name="modelMetadata">The <see cref="ModelMetadata"/> associated with the model annotated with
        /// <see cref="Attribute"/>.</param>
        /// <param name="arguments">The value arguments which will be used in constructing the error message.</param>
        /// <returns>Formatted error string.</returns>
        protected virtual string GetErrorMessage(ModelMetadata modelMetadata, params object[] arguments)
        {
            if (modelMetadata == null)
            {
                throw new ArgumentNullException(nameof(modelMetadata));
            }

            if (_stringLocalizer != null &&
                !string.IsNullOrEmpty(Attribute.ErrorMessage) &&
                string.IsNullOrEmpty(Attribute.ErrorMessageResourceName) &&
                Attribute.ErrorMessageResourceType == null)
            {
                return _stringLocalizer[Attribute.ErrorMessage, arguments];
            }

            // Uses default error message from attribute's default constructor and injects property display name.
            // For `RequiredAttribute` it would be `DataAnnotationsResources.RequiredAttribute_ValidationError`
            return Attribute.FormatErrorMessage(modelMetadata.GetDisplayName()); 
        }

Hi, Could someone at Microsoft could try to solve this issue? It’s been here for more than 3 years, with multiple suggested solutions by the community. Any large localized solution suffers from this issue badly, as it requires repetitive attributes for no good reason.

Thanks, Effy

One more sad gotcha.

I’ve overridden all model binding messages with translations using ModelBindingMessageProvider.SetValueIsInvalidAccessor and other ModelBindingMessageProvider values to return my custom resource strings.

And then I discovered the dreadful truth. If my API controller receives the data as JSON, then ModelBindingMessageProvider validation messages are not being used at all. Instead, Json.Net kicks in and I get something like this in response:

  "errors": {
    "countryId": [
      "Input string '111a' is not a valid number. Path 'countryId', line 3, position 23."
    ]
  },

I looked in GitHub source of Json.Net - indeed, it seems to have such exact error messages defined with line numbers etc.

So, ModelState manages to pull them in instead of using its own ModelBindingMessageProvider messages.

I tried to disable Json.Net error handling:

.AddJsonOptions(options =>
                {
                 ...
                    options.SerializerSettings.Error = delegate (object sender, Newtonsoft.Json.Serialization.ErrorEventArgs args)
                    {
                        // ignore them all
                        args.ErrorContext.Handled = true;
                    };
                })

but it made no difference.

Is there any way to catch these Json deserialization errors and redirect them to ModelBindingMessageProvider, so that my localized messages would work?

Some rant follows: This all localization & validation business gets really messy really soon. I come from PHP Laravel framework. While it had a few localization issues for global validation texts, at least I could completely extend and override the entire process of message collection because it was all in one place. In contrast, ASP.NET Core has scattered validation messages and mechanisms throughout multiple places - ModelBindingMessageProvider, model attributes, and now also Json.Net error messages…

I agree with OP, this should be enhanced.