Skip to main content
Version: 2.13.14

Grammar and platform formatting

Orientation

Humanizer APIs expose grammatical gender and grammatical case where the result needs information that a number or date cannot carry by itself. These arguments affect language rules; they are not presentation-only labels.

Calendar names and numeric punctuation are a separate layer. .NET Framework uses Windows NLS, while modern .NET normally uses ICU. When those sources disagree, test Humanizer 2.13.14 on every target platform the application supports.

Example

using System.Globalization;
using Humanizer;

var spanish = CultureInfo.GetCultureInfo("es");

Console.WriteLine(1.ToWords(GrammaticalGender.Feminine, spanish));
Console.WriteLine(2.ToWords(GrammaticalGender.Masculine, spanish));

CultureInfo.CurrentCulture = CultureInfo.GetCultureInfo("cs");
CultureInfo.CurrentUICulture = CultureInfo.CurrentCulture;
Console.WriteLine(new DateTime(2026, 7, 27)
.ToOrdinalWords(GrammaticalCase.Genitive));

Pass grammar explicitly when the surrounding noun or sentence determines it. The default gender or case is a locale convention, not a guess about your domain text.

Pitfall

Not every grammatical option has a distinct natural form in every locale. Do not manufacture a gender or case by post-processing Humanizer output. Choose a supported overload and test the complete phrase native speakers will see.

Caller-supplied custom format providers remain authoritative. Consult the selected-version language inventory for any Humanizer-specific calendar or number-formatting overrides. When none are documented, calendar names and numeric punctuation follow the runtime globalization data for the target framework and platform.

For incorrect grammar or platform-specific output, use the language correction guide or open a prefilled locale issue.

Version notes

This page is scoped to Humanizer 2.13.14. Runtime globalization data can differ by target platform, so test on the target framework and operating systems you ship.