Localization

Every built-in validator reads its DefaultMessage from ValidationConfiguration.Localizer, an IStringLocalizer keyed by validator attribute type name. Out of the box the package ships English and French message catalogues and selects between them using CultureInfo.CurrentUICulture.

Built-in cultures

Selection uses the current UI culture’s two-letter ISO language name, so en-US, en-GB and en-AU all resolve to en, and fr-FR and fr-CA to fr. Any other culture falls back to English — there is no per-region variation and no exception for an unknown culture.

CultureInfo.CurrentUICulture = new CultureInfo("fr-CA");

var errors = Query.Validate(new Query { Id = 0 });
// "'Id' doit être supérieur à '0'."

Message keys and defaults

The key for each message is the validator’s attribute type name, including the Attribute suffix — GreaterThanAttribute, not GreaterThan.

Supplying your own localizer

ValidationConfiguration.Localizer is a static, settable IStringLocalizer. Assign any implementation to replace the catalogue wholesale — this is also how you change the default English wording without touching every attribute.

using Immediate.Validations.Shared;

ValidationConfiguration.Localizer = myLocalizer;

A worked example backed by .resx files. Add Validators.resx and Validators.fr-CA.resx to your project, with one entry per validator type name:

<data name="GreaterThanAttribute" xml:space="preserve">
  <value>'{PropertyName}' has to be more than '{ComparisonValue}'.</value>
</data>
<data name="NotNullAttribute" xml:space="preserve">
  <value>'{PropertyName}' is required.</value>
</data>

Then wire a ResourceManagerStringLocalizer at startup:

using Immediate.Validations.Shared;
using Microsoft.Extensions.Localization;

var resourceManager = Resources.Validators.ResourceManager;

ValidationConfiguration.Localizer = new ResourceManagerStringLocalizer(
	resourceManager,
	typeof(Program).Assembly,
	resourceManager.BaseName,
	new ResourceNamesCache(),
	NullLogger<Program>.Instance
);

ResourceManagerStringLocalizer resolves against CultureInfo.CurrentUICulture itself, so per-request culture selection (for example ASP.NET Core’s RequestLocalizationMiddleware) works without further wiring.

What is not localized

• Messages set explicitly via a validator’s Message property. Those are compiled into the generated code as literals.
• The root-null sentinel. When Validate is handed a null reference-typed target it returns a single error, `target` must not be `null`., which is a hard-coded literal in the generated code and never passes through the localizer. See property path rules.
• Display names. {PropertyName} renders the humanized C# identifier, or [Description] if you supply one — neither is culture-aware.

Custom validators

Your own validators opt into localization by reading the same configuration point:

public static string DefaultMessage =>
	ValidationConfiguration.Localizer[nameof(DivisibleByAttribute)].Value;

Because DefaultMessage is a property, it is re-read on each failure, so a culture change between validations is picked up. A const string DefaultMessage is baked in and cannot be localized.