{status.via};
- }
- return status.kind === 'platform'
- ? Platform
- : 'Missing';
-}
+export const supportedCultures =
+ coverage.locales?.map(({locale}) => locale) ?? coverage.cultures ?? [];
-# Supported cultures and capabilities
+# Supported cultures
## Orientation
-This inventory is generated for {coverage.generatedFor} from
-{coverage.source}. The verified
-{coverage.package.id} assets target
-{coverage.package.targetFrameworks.join(', ')}, and their locale
-evidence is {coverage.package.localeData}.
-
-`DateOnly` ordinals are present in the
-{coverage.package.apiAvailability.dateOnlyOrdinals.join(', ') || 'none'}
-assets. Clock notation is present in the
-{coverage.package.apiAvailability.clockNotation.join(', ') || 'none'}
-assets. Those lists come from exact members in each package XML documentation
-file, not from a version-number assumption.
+Humanizer 4 treats locale support as all-or-nothing. Every culture listed below
+supports every applicable localized feature. Regional cultures may reuse a
+same-language parent, and calendar or numeric formatting may use .NET
+globalization data when no Humanizer override is needed; neither represents
+partial support.
## Example
-Use the culture code in the first column with `CultureInfo`:
+Use a culture code from the list with `CultureInfo`:
```csharp
using System.Globalization;
@@ -50,101 +34,19 @@ var culture = CultureInfo.GetCultureInfo("pt-BR");
Console.WriteLine(123.ToWords(culture));
```
-{coverage.coverageKind === 'yaml-capabilities' ? (
- <>
-
- The table contains {coverage.locales.length} checked-in locale files.
- Own means that locale contributes at least one canonical
- block for the capability. Via … means the capability is
- fully inherited through the immediate same-language parent.
- Platform means an optional calendar or number-formatting
- override is absent, so Humanizer uses .NET globalization data.
-
- The canonical source-generator parser rejects invalid schemas, missing - required capabilities, inheritance cycles, and cross-language parents - before this output is written. -
-
- Grammatical-case duration coverage is narrower than general locale
- coverage and is classified separately as distinct,
- invariant, or not-applicable. Case and unit
- realizations may be authored, evidenced as rendering the same as another
- case, or explicitly not applicable; release validation rejects
- unsupported applicable entries. An Own or
- Via … cell in this table does not imply that
- HumanizeWithCase supports every case or duration unit.
- See the duration guide for the runtime contract.
-
| Culture | -Parent | - {coverage.capabilities.map((capability) => ( -{capability.label} | - ))} -
|---|---|---|
{locale.locale} |
- {locale.parent ? {locale.parent} : '—'} |
- {coverage.capabilities.map((capability) => (
-
- |
- ))}
-
- This published release predates the current canonical YAML model. Its
- culture list comes from locale dependencies in the verified
- {coverage.package.id} metapackage, plus neutral
- en from the verified
- {coverage.package.apiPackage} package. It does not claim
- per-capability ownership that the packages cannot prove.
-
| Published culture |
|---|
{culture} |
This version supports {supportedCultures.length} cultures:
+ +{locale}Humanizer for .NET
-
- A mature .NET library for turning dates, times, numbers,
- quantities, strings, enums, and collections into language people
- understand.
+
+ Humanizer adds focused extension methods for readable strings,
+ dates, times, numbers, quantities, enums, and collections—across
+ every supported culture.
Start
- Install the package, import the namespace, and call the extension
- that matches the value you want to present.
- Add the latest stable Humanizer package to your project.
- Use focused extension methods on the values you already have.
-
- Follow the version-correct guide, then move directly into
- precise reference when you need it.
- Scenarios Start with the value you have {scenario.description} {prompt} Upgrading
- Use version-specific guidance for package, namespace, analyzer,
- and behavior changes instead of reconstructing history.
- Reference Language support
- Generated API pages live beside the guides, share their version,
- and remain searchable as one documentation set.
+ Humanizer 4 makes one promise: every listed culture supports
+ every applicable localized feature. Missing behavior or English
+ fallback is a bug, not a capability tier.
Version-correct by design
+ Choose your Humanizer version once. The guides, runnable examples,
+ search results, and generated API reference follow that package.
+ Languages
- Understand culture selection and locale behavior, then find the
- focused contribution guidance when language output needs work.
-
+
+
+
+ Humanizer for .NET
+
Turn .NET values into words people understand.
+
-
- Start with Humanizer
+
-
+
+ Run the five-minute example
-
- Browse the API
+
+ Find an API by task
-
-
- Illustrative C#
- input → output
+
-
-
-
-
+ Install from NuGet
+
- dotnet add package Humanizer
-
-
- // less machine, more human
-
- {'\n'}
-
- "PascalCaseInput"
-
- .Humanize()
- {'\n'}
-
- → "Pascal case input"
-
-
-
-
- From package to useful text in minutes.
-
-
+
-
- Install
-
-
- dotnet add package Humanizer
-
-
- Humanize
-
-
-
- using{' '}
- Humanizer;
- {'\n\n'}
-
- "Underscored_input_string_is_turned_into_sentence"
-
- {'\n '}.Humanize();
-
-
-
- Go deeper
-
+
+
+
+
+ {transformations.map(({input, output}) => (
+ C# input
+
+ Readable output
+
+
+ ))}
+
+ {input}{output}
+
- Start with the job in front of you.
+
+
- Use the method that says what it does.
- {scenarioGroups.map((scenario) => (
-
+ {taskRoutes.map(({title, prompt, sample, to}) => (
+
-
-
- {scenario.title}
- {title}
+ {scenario.sample}
-
+ {sample}
+
+
))}
Move between releases with the boundaries in view.
- Exact signatures, in the version you selected.
+
+
+
+ See supported cultures
+
+ Supported means supported.
+
+ Guides and signatures stay together.
+
+
+ Open the guides
-
-
Culture-aware output, with a direct correction path.
-