Overview
This repository solves one specific problem: keeping CultureInfo-based formatting aligned with Windows National Language Support data when modern .NET runtimes would otherwise expose ICU-backed culture values. It packages that behavior as a small extension layer so consumers can stay on standard System.Globalization abstractions instead of adopting a separate formatting model.
The public surface is deliberately small, but the repository carries substantial curated locale data and tests behind it. The main value is deterministic control over the culture data that backs existing date, time, and number formatting code.
Concepts
The concepts in this repository are less about new types and more about controlling which culture data your existing formatting code depends on. Codebelt.Extensions.Globalization keeps CultureInfo as the consumer-facing abstraction and changes the data source behind it.
Reuse CultureInfo, replace the formatting data
The central idea is to keep normal CultureInfo usage in place while enriching its DateTimeFormat and NumberFormat members with embedded Windows NLS values. That makes the package useful when an application already formats dates or numbers through framework APIs but the runtime-default ICU data no longer matches the required output.
Make culture differences explicit and deterministic
The package does not guess or synthesize missing locale data at runtime. Its enrichment path depends on embedded surrogate resources, and the public API fails with InvalidOperationException when a requested culture has no curated NLS surrogate, which turns data coverage into something callers can validate and test instead of discovering through silent formatting drift.
Handle single-culture and batch enrichment with the same contract
The repository supports both direct enrichment of one CultureInfo instance and batch enrichment of multiple cultures. That shared contract matters because read-only cultures are cloned before enrichment, writable cultures are updated in place, and repeated requests for the same culture name reuse cached enriched instances rather than rebuilding them on every call.
Usage guidance
Prefer this repository when Windows-compatible culture formatting is part of the application contract and the rest of the codebase already speaks in terms of CultureInfo. Apply the enrichment close to the boundary where cultures enter formatting, serialization, or presentation code so downstream code continues to consume ordinary framework culture objects.
If the platform-default CultureInfo behavior is acceptable, or you only need a few explicit format strings, keep the plain framework APIs. The package is most useful when the source of culture data itself is the requirement.