Fix culture parameter being ignored in Blazor WebAssembly

[Copilot]

Problem

When using Humanizer in Blazor WebAssembly applications, explicitly passing a culture parameter to methods like DateTime.Humanize(), TimeSpan.Humanize(), and related methods was being ignored, always returning English results even when proper localized resources were available.

// In a Blazor WebAssembly component
var germanCulture = new CultureInfo("de-DE");
var result = DateTime.Now.AddHours(-3).Humanize(culture: germanCulture);
// Expected: "vor 3 Stunden"
// Actual: "3 hours ago" ❌

This issue was specific to Blazor WebAssembly and did not affect regular .NET applications. The ToWords() methods worked correctly, but time-based humanization methods did not, despite all ultimately using the same resource loading mechanism.

Root Cause

The Resources.GetResource() method used ResourceManager.GetString(resourceKey, culture) which, in Blazor WebAssembly environments, can incorrectly fall back to the neutral/invariant culture (English) even when:

• An explicit culture is provided as a parameter
• Satellite assemblies for that culture are properly configured and deployed

This happens because:

1. In Blazor WebAssembly, satellite assemblies are loaded lazily
2. ResourceManager's fallback logic may cache an incorrect neutral culture result before the satellite assembly loads
3. The cached fallback result persists for subsequent lookups

Solution

Modified Resources.GetResource() to ensure the exact culture's resource set is loaded before falling back:

1. First attempt: When a specific culture is provided, use ResourceManager.GetResourceSet(culture, createIfNotExists: true, tryParents: false) to load the exact culture's resource set without parent fallback. This ensures the satellite assembly is loaded in Blazor WebAssembly scenarios.
2. Second attempt: If not found in the exact culture (or culture was null), fall back to the standard ResourceManager.GetString() behavior which performs the full fallback chain.

This approach:

• ✅ Fixes the Blazor WebAssembly issue by loading satellite assemblies before fallback occurs
• ✅ Prevents incorrect neutral culture results from being cached
• ✅ Maintains backward compatibility with all existing code
• ✅ Preserves previous behavior for null culture parameter (falls through to GetString)

Changes

• Modified src/Humanizer/Localisation/Resources.cs: Updated GetResource() method to load the exact culture's resource set with createIfNotExists: true before falling back to GetString()

After This Fix

// In a Blazor WebAssembly component
var germanCulture = new CultureInfo("de-DE");
var result = DateTime.Now.AddHours(-3).Humanize(culture: germanCulture);
// Returns: "vor 3 Stunden" ✅

All Humanizer methods that accept a culture parameter will now work correctly in Blazor WebAssembly:

• DateTime.Humanize(culture: ...)
• TimeSpan.Humanize(culture: ...)
• DateOnly.Humanize(culture: ...)
• TimeOnly.Humanize(culture: ...)

Fixes #2197
Fixes #1089

Original prompt

---

This section details on the original issue you should resolve

<issue_title>culture parameter being ignored in razor component (Blazor WebAssembly)</issue_title>
<issue_description>I'm currently having the following issue:

I'm using Humanizer in a razor component running in a WebAssembly Blazor project. My component has a class Localizer which provides a CultureInfo. When passing a DateTime through the Humanizer, I always get the English result. Here's the code snippet:

<small class="pr-2">
    <abbr title="@item.Date.ToString(Localizer.GetCulture())">
        @item.Date.Humanize(culture: Localizer.GetCulture())
    </abbr>
</small>

The Localizer is not the problem, as the Date format in the tooltip is correctly changed when I change the culture:

Culture en-US:

Culture de-DE:

Some additional information:
The same issue happens with TimeSpan, but non time related functions seem unaffected e.g. 5.ToWords(culture: Localizer.GetCulture()) works just as expected.

Upon further analysis, the problem seems to occur while loading the resource string:

The culture has been correctly passed down, but loading the resource always returns the english string.</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #1089

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull Request Overview

This PR fixes a Blazor WebAssembly-specific issue where explicitly passed culture parameters were being ignored in Humanizer's time-based methods, causing them to always return English results instead of the requested localized text.

• Modified the Resources.GetResource() method to use a two-step resource retrieval approach that prevents premature fallback to neutral culture in WebAssembly environments
• Added proper handling for explicit culture parameters by first attempting direct resource set access before falling back to standard ResourceManager behavior
• Updated test assertions to reflect correct resource string format

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Humanizer/Localisation/Resources.cs	Implemented two-step resource retrieval to fix culture parameter handling in Blazor WebAssembly
src/Humanizer.Tests/Localisation/ResourcesTests.cs	Updated test assertions to match corrected resource string format

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting

• @codex fix this CI failure
• @codex address that feedback

[chatgpt-codex-connector]

Avoiding fallback still calls GetString for first lookups

The new logic probes ResourceManager.GetResourceSet(culture, createIfNotExists: false, …) (and again with tryParents: true) but never allows the resource set to be created. When the satellite assembly has not yet been loaded—which is exactly the Blazor WebAssembly scenario this change targets—both calls return null and the method immediately falls back to ResourceManager.GetString, which performs the same neutral‑culture fallback and caches the result. As a result, explicit cultures are still ignored on the first lookup. To actually bypass fallback you need to load the exact culture’s resource set (e.g. createIfNotExists: true) before resorting to GetString.

Useful? React with 👍 / 👎.

[clairernovotny]

@copilot address this issue

[clairernovotny]

@codex address this with a fix

[chatgpt-codex-connector]

For now, I can only help with PRs you've created.

[clairernovotny]

@copilot address this, you ignored it just now:

The new logic probes ResourceManager.GetResourceSet(culture, createIfNotExists: false, …) (and again with tryParents: true) but never allows the resource set to be created. When the satellite assembly has not yet been loaded—which is exactly the Blazor WebAssembly scenario this change targets—both calls return null and the method immediately falls back to ResourceManager.GetString, which performs the same neutral‑culture fallback and caches the result. As a result, explicit cultures are still ignored on the first lookup. To actually bypass fallback you need to load the exact culture’s resource set (e.g. createIfNotExists: true) before resorting to GetString.

[clairernovotny]

@copilot fix this:

The new logic probes ResourceManager.GetResourceSet(culture, createIfNotExists: false, …) (and again with tryParents: true) but never allows the resource set to be created. When the satellite assembly has not yet been loaded—which is exactly the Blazor WebAssembly scenario this change targets—both calls return null and the method immediately falls back to ResourceManager.GetString, which performs the same neutral‑culture fallback and caches the result. As a result, explicit cultures are still ignored on the first lookup. To actually bypass fallback you need to load the exact culture’s resource set (e.g. createIfNotExists: true) before resorting to GetString.

[Copilot]

@copilot fix this:

The new logic probes ResourceManager.GetResourceSet(culture, createIfNotExists: false, …) (and again with tryParents: true) but never allows the resource set to be created. Wh...

Fixed in commit 6be1677. Changed to use createIfNotExists: true when loading the exact culture's resource set, ensuring satellite assemblies are loaded before falling back to GetString.