This project is read-only.

Asp.Net Identity {name}Validator.cs ErrorValue Resources.resx Localization

May 20, 2015 at 5:20 AM
Edited Jun 6, 2015 at 11:02 PM
Looking for a localization approach, concept, opinion...

From a MVC web-app I want to localize ASP.NET Identity Resource.resx (x2) {name}Validator.cs ErrorMessages; see for keys/values requirements (fields). *****

Here is an example from the ASP.NET Identity code adding an error
// errors.Add(Resources.PasswordRequireNonLetterOrDigit);
see code.

And here is the MVC web-app controller code requesting a "create user" and forwarding the "results" object;
// var result = await UserManager.CreateAsync(user, model.Password); // IDENTITY ACCOUNT/REGISTER
// AddErrors(result); // ERROR MESSAGES TO MODEL

I have searched the web (far and wide) and many topics point to EF Data Annotation which handle some localization but not {name}Validator.cs code error messages (and others), EF Data Annotations are helpful but incomplete.

// i.e. Validator
// errors.Add(String.Format(CultureInfo.CurrentCulture, Resources.PropertyTooShort, "Name"));
// errors.Add(String.Format(CultureInfo.CurrentCulture, Resources.PropertyTooShort, "Email"));
// else if (AllowOnlyAlphanumericUserNames && !Regex.IsMatch(user.UserName, [A-Za-z0-9_\.]...)), see code

Note-1) the ASP.NET IDENTITY (.Core and .EntityFramework) Resources.resx files are provided by Microsoft for a set of languages (fr... good to have).

Note-2) a hardcoded regex string is in this ASP.NET Identity codebase, I think (?) data annotations might work here in the Models.

Note-3) the client-side validation also needs localization capabilities.

Note-4) Satellite Assemblies level would be the simplest to implement (specific culture over neutral).

Note-5) the Multilingual App ToolKit capabilities (engineering/light production work) should be taken into consideration functionally

Note-6) the satellite assemblies [fallback] behavior is somewhat similar to data annotation localization initial definition [overriding] behavior; i.e. initial data model to project-coded-configured in BLL, MVC-server, JavaScript-UI-client overriding.

I can just convert the "results" object's language-culture values to the language-culture values for the client. This would solve the localization problem on the server side. Client side would still be a problem; these are 1 time or rare transactions, the extra overhead should not be a problem, use the following.
// HtmlHelper.ClientValidationEnabled = false.

q-1) Is a [from]-natural-language-1 conversion of a "results" object's received values into a [to]-different natural-language-2 "results" object's values a good light-weight code approach? (this ties directly to the client-content a.k.a. the "requirement for localization")

q-2) Can resource Satellite Assemblies be used from the ASP.NET Identity assembly? These are more flexible than neutral cultures languages (en-US (satellite) choice over en (main) for implementation, most website would support multiple languages; en-US, es-MX, fr-CA, and en-CA for example)

q-3) How can I affect the client-side validation messages in ASP.NET Identity?

q-4) Can character set regular expressions be addressed; A-Z and a-z to all available Unicode characters not just English?

q-5) Concatenated error messages are problematic, can these be individual errors pointing to the same source field?

q-6) Should the Resources.resx and IdentityResources.resx DuplicateEmail-key's values be identical?

Aside: The Resources.resx's value single-quote usage seems inconsistent, the IdentityResources.resx value fields do not use the single-quote.

Any other thoughts would be helpful.

Thanks Everyone, Dave from Redding, CA