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

[tbolon]

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 ?

[Eilon]

@tbolon 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). Because of that, ASP.NET Core's localization system won't know what to translate off of because it will get "random" text depending on what's installed. That's why ASP.NET Core requires that you specify a specific error message so that it knows exactly what to key off of.

[tbolon]

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...

[Eilon]

Crazy idea time:

If the system sees that ErrorMessage isn't set, it can try to call into the loc system with some well-known key (such as System.ComponentModel.DataAnnotations.Required.Message) to see if the loc system returns a value not equal to that key. If it returns the key, clearly it has not been localized and so it should fall back to getting the data annotation attribute's intrinsic error message. If it returns some other value, it can assume it was localized and use that as the error message.

@DamianEdwards @ryanbrandenburg @hishamco - does this sound like it might work?

[ryanbrandenburg]

I can't think of any technical reason why that wouldn't work, but I'm kind of wary of adding magic keys which do specific things.

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[effyteva]

Any updates on this one?
It's very critical for large applications...

[anna-git]

Can this post help you? https://geeksaddictions.wordpress.com/2016/11/28/data-annotations-fallback-on-shared-resources-if-not-found/

[iamdroppy]

I agree with OP, this should be enhanced.

[alexandrejobin]

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.

[roeldewit]

I found a GitHub project that makes it easy to just add a Resource file for the translated validation messages: https://github.com/ridercz/Altairis.ConventionalMetadataProviders

[alexsandro-xpt]

+1

[poke]

Iterating on @Eilon’s idea here: To avoid hardcoding magic keys for the validations, maybe we could provide a way to essentially configure it like this:

```c#
services.AddMvc()
.AddDataAnnotationsLocalization(options =>
{
options.DefaultErrorResourcePathProvider = (ValidationAttribute attribute) =>
{
return "Default_" + attribute.GetType().Name;
});
});

That way you could set up your own “magic” string for finding the message for a validation attribute. And if there is no provider specified, it would fall back to the default behavior.

The logic to attempt the localization could then look like this:

```c#
if (_stringLocalizer != null)
{
    // always allow explicit overriding
    if (!string.IsNullOrEmpty(Attribute.ErrorMessage) &&
        string.IsNullOrEmpty(Attribute.ErrorMessageResourceName) &&
        Attribute.ErrorMessageResourceType == null)
    {
        return _stringLocalizer[Attribute.ErrorMessage, arguments];
    }

    // use default error resource path provider
    if (_defaultErrorResourcePathProvider != null)
    {
        var path = _defaultErrorResourcePathProvider(attribute);
        LocalizedString message = _stringLocalizer[path, arguments];
        if (!message.ResourceNotFound)
        {
            return message.Value;
        }
    }
}

// fall back to default
return Attribute.FormatErrorMessage(modelMetadata.GetDisplayName());

While this probably won’t solve _all_ problems, it should probably get us closer to what would be desired to make validation errors localizable.

[BlueBird67]

Still no simple solution for this huge problem?

[maftieu]

@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.

[Eilon]

I'm not aware of one. The Orchard CMS project has translations for many common .NET concepts (because it's built on .NET!). I did a search on their translation repo and found several matches for The field {0} is required:

https://github.com/OrchardCMS/OrchardCore.Translations/search?q=the+field+required&unscoped_q=the+field+required

However, I don't see license info on their site.

@sebastienros - what license should be on the https://github.com/OrchardCMS/OrchardCore.Translations repo?

[sebastienros]

@Eilon The project you are pointing to is one that contains all the translations strings for Orchard Core, in order to be able to generate nuget packages out of it. These files are automatically pushed by Crowdin which is a collaborative website to edit translation files.

But I will look at how we handle the localization for these default strings and follow up here.

[Eilon]

@sebastienros - if there's a license on the repo it would make it easier for people to grab some arbitrary translations if they wanted. Right now there's no license so it's not clear what is allowed.

[progmars]

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?

<sub><sup>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...</sup></sub>

[vjacquet]

As a workaroung 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

[effyteva]

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

[maftieu]

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.

// 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;
                    }
                }
            }
        }
    }
}

[effyteva]

Thank you @maftieu, this solution works great!