Languages and cultures

Humanizer localizes behavior by culture, not by translating one final string. Choose a culture for the operation, then confirm that its exact name has a generated Humanizer 4 accepted-culture mapping. Configurator.IsCultureSupported performs that exact-name check in application code. An accepted regional name can map to a neutral same-language profile, but Humanizer does not infer support by walking an arbitrary .NET parent chain.

Humanizer 4 ships its runtime, generated locale data, and analyzers in the single Humanizer package. Installing the package does not select a culture; the application still chooses one with CultureInfo.

Example

This complete example selects French explicitly:

using System.Globalization;
using Humanizer;

var french = CultureInfo.GetCultureInfo("fr-FR");
Console.WriteLine(42.ToWords(french));

The output is:

quarante-deux

Use culture selection for per-call and ambient-culture patterns. Use supported cultures for the current inventory. Use the scenario finder to reach the focused guide for number words, dates, clock notation, collections, or another localized task.

How culture resolution works

Do not infer support from a package name or English fallback. A regional culture can reuse a same-language profile such as fr only when its exact name is in the accepted-culture inventory. That mapping is an implementation detail, not partial support. Caller-created LocaliserRegistry<TLocaliser> instances retain their public parent-chain fallback behavior. Report incorrect inherited behavior just as you would incorrect directly authored behavior.

Found a wrong translation, parser result, or platform-specific format? Follow the language correction guide or open a prefilled locale issue.

Related guides and API

• Choose a culture
• Grammar and platform formatting
• Scenario finder
• Package selection
• API reference