Required Data Annotation is not being translated Required Data Annotation is not being translated asp.net asp.net

Required Data Annotation is not being translated


I would start with setting the globalization element in web.config

<system.web>  <globalization enableClientBasedCulture="true" culture="auto" uiCulture="auto"/>

Next I would check the culture you are getting in a Controller (log it in DB or pass to a view with @ViewBag

culture = CultureInfo.InstalledUICulture.IetfLanguageTag;if (HttpContext.Current != null && HttpContext.Current.Request.UserLanguages != null){    culture = Request.UserLanguages[0];     }

Confirm that the values you use to identify Culture are the values being used by headers


Followup

You are using globalization headers to check for user language, but are setting user language manually in browser.

2 approaches to try:

1) set user language in browser using Javascript:

<script type="text/javascript">      Globalize.culture("@ViewBag.Culture");</script>

Or if culture is set in Javascript (vs C#)

<script type="text/javascript">      Globalize.culture(culturevariable);</script>

2) ParameterisedRequiredAttribute

public class ParameterisedRequiredAttribute : RequiredAttribute{    private string[] _replacements { get; set; }    public ParameterisedRequiredAttribute(params string[] replacements)    {        _replacements = replacements;        ErrorMessageResourceName = ErrorMessagesErrors.SpecificFieldRequired;        ErrorMessageResourceType = typeof(ErrorMessages);    }    public override string FormatErrorMessage(string name)    {        return string.Format(ErrorMessageString, (object[])_replacements);    }}

The first approach seems like a better solution if you are manually setting the language. Simply put, the annotation would have to be re-set everytime the user changes language modes.

Another thing to consider is that the way you currently set language (through headers) is probably your best solution. While this is harder to test because you need a client with dedicated language, this is the way your users are best distinguished (by headers).


Make sure that your current thread context has been updated to use the correct CultureInfo based on the web client's Request headers. This should be automatic if you have the <globalization ..> tag defined. Otherwise, add a filter to intercept the request and perform the update.

var cultureName = "de-DE"; // get this from request headersvar ci = new CultureInfo(cultureName);Thread.CurrentThread.CurrentCulture = ci;Thread.CurrentThread.CurrentUICulture = ci;

See also From where CultureInfo.CurrentCulture reads culture


I have created a sample app in order to reproduce your issue. It works for me so I'll give you my current setup.

I have a Web Application project referencing a library assembly Resources.

I have 2 resx files in the Resource project (language.resx and language.fr.resx). Both files have the same properties:

  • Build Action: Embedded Resource,
  • Custom Tool: PublicResXFileCodeGenerator,
  • Custom Tool Namespace: MyResources

The ViewModel AnswersViewModel has a IDAnswer attribute with the following attribute:

[Required(ErrorMessageResourceName = "RequiredMessage",           ErrorMessageResourceType = typeof(MyResources.Language))]

I have added the namespace MyResource to the web.config file in the View folder and I have updated the section system.web of the main web.config by adding

<globalization enableClientBasedCulture="true" culture="auto" uiCulture="auto"/>

I hope it will help.