Suggestion: Support multilingual websites via route.

[drma-tech]

I'm configuring my websites to support language changes via route, so I can index all pages in all languages ​​on Google.

In addition to configuring routes per page.

I also make changes via tag:

<link rel="alternate" href="https://www.streamingdiscovery.com/en/legal/terms" hreflang="en">
<link rel="alternate" href="https://www.streamingdiscovery.com/pt/legal/terms" hreflang="pt">
<link rel="alternate" href="https://www.streamingdiscovery.com/es/legal/terms" hreflang="es">
<link rel="alternate" href="https://www.streamingdiscovery.com/en/legal/terms" hreflang="x-default">

and via sitemap:

<url>
	<loc>https://www.streamingdiscovery.com/en/platforms/9</loc>
	<lastmod>2026-04-09</lastmod>
	<xhtml:link rel="alternate" hreflang="en" href="https://www.streamingdiscovery.com/en/platforms/9" />
	<xhtml:link rel="alternate" hreflang="pt" href="https://www.streamingdiscovery.com/pt/platforms/9" />
	<xhtml:link rel="alternate" hreflang="es" href="https://www.streamingdiscovery.com/es/platforms/9" />
</url>

But I noticed that your component doesn't have any mechanism to detect this.

Some suggestions I thought of were:
1 - We could configure some kind of regex to duplicate the pages;
2 - Generate the HTML files based on the sitemap, instead of reading tags as is currently done;

[jsakamoto]

Hi @drma-tech,
Thank you for reporting this issue. I have asked GitHub Copilot to implement improvements for now. If all goes well, I hope to be able to release an improved version in the near future.

As a temporary workaround, you can add URL paths to be prerendered as static HTML by specifying them in the BlazorWasmPrerenderingUrlPathToExplicitFetch MSBuild property, separated by semicolons. This might be a useful interim solution for you.

dotnet publish -p BlazorWasmPrerenderingUrlPathToExplicitFetch "/en/legal/terms;/pt/legal/terms;/es/legal/terms"

Of course, I understand that this workaround is not practical if there are a large number of pages that need to be specified for BlazorWasmPrerenderingUrlPathToExplicitFetch.

[drma-tech]

I was already familiar with this feature, but I thought it was limited to the context of that page.

My default is EN, but if I add the index for other languages, it also maps the complete site for those languages.

<BlazorWasmPrerenderingUrlPathToExplicitFetch>/pt/;/es/</BlazorWasmPrerenderingUrlPathToExplicitFetch>

[drma-tech]

Even so, I couldn't translate the static pages. They are all being generated in English (which is the project's default).

The current way I'm doing it - in program.cs - which is recommended for Blazor WASM:

var app = builder.Build();

var nav = app.Services.GetService<NavigationManager>();
var js = app.Services.GetRequiredService<IJSRuntime>();

await ConfigureCulture(nav, js);

Where within the method, I do this:

CultureInfo.DefaultThreadCurrentCulture = cultureInfo;
CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;

But it doesn't work for your component because it's not executed.

I tried applying it to your "ConfigureServices" method, but I can't access the route (which is where the language is);

I also tried in app.razor (I have the route and everything), but it's too late, any attempt to change culture info doesn't work.

I also tried using JavaScript:

<script src="_framework/blazor.webassembly#[.{fingerprint}].js" autostart="false"></script>
<script>
    function isValidLanguage(lang) {
        return ["en", "pt", "es", "zh"].includes(lang);
    }
    let lang = window.location.pathname.split('/')[1] || "en";

    if (!isValidLanguage(lang)) {
        lang = "en";
    }
    Blazor.start({
        applicationCulture: lang
    });
</script>

It works, but only in the browser; it had no effect running through your component.

So, I've run out of options. I think there needs to be some solution in your component that allows you to apply culture info per route.

[jsakamoto]

@drma-tech
I have released version 7.1.0, which has been improved to follow the href attribute of the link element with rel=alternate. I will continue working on support for sitemap.xml and addressing culture-related issues. Please give me some more time.

[drma-tech]

If you have any workaround to make my resources (translation files) work for now, that would be great.

[jsakamoto]

@drma-tech Sure. I was a bit busy maintaining my products for the new .NET SDK, but I'm still working on the issue with deciding culture based on URL routing. The issue ticket was closed once, but that was not my intention; it was caused automatically by merging a branch that fixes one of the problems you reported, so I reopened this issue. Please give me more time.

[jsakamoto]

Hi @drma-tech,
I've created a sample project that demonstrates how to switch CultureInfo.CurrentCulture based on the URL path — in a way that works both at runtime in the browser and during pre-rendering with BlazorWasmPreRendering.Build.

👉 Sample project: 📦WasmApp1.zip

This sample app has pages that display the current date in English and French cultures. When you run dotnet publish, BlazorWasmPreRendering.Build generates pre-rendered HTML files with the date formatted in each language — English for /en/home and French for /fr/home.

The Key Idea

The trick is to set CultureInfo.CurrentCulture inside the OnInitialized lifecycle method of App.razor, by inspecting the first segment of the current URL path.

This works during pre-rendering because the pre-rendering engine renders each URL by executing the full Blazor component lifecycle — including OnInitialized. So when it pre-renders /fr/home, the App component reads "fr" from the URL and sets the culture to French before any child components render.

Why Program.cs doesn't work

When running as a normal Blazor WebAssembly app in the browser, Program.cs executes after the page (and its URL) has already been loaded — so reading the URL and setting the culture there works fine.

However, BlazorWasmPreRendering.Build pre-renders your Blazor WebAssembly app by internally running it as a Blazor Server process. In that mode, Program.cs runs when the server process starts up and begins listening for HTTP requests — before any HTTP request actually comes in from the crawler. At that point, there is simply no "current URL" to inspect, so setting the culture in Program.cs has no effect during pre-rendering.

Why Blazor.start({ applicationCulture }) doesn't work

As mentioned above, BlazorWasmPreRendering.Build pre-renders your app by running it as a Blazor Server process. To emphasize again: during pre-rendering, the server-side .NET process generates HTML strings entirely on its own — no browser is involved at all. Since there is no browser, no JavaScript is ever executed. The Blazor.start({ applicationCulture }) call lives in JavaScript, so it simply never runs during pre-rendering.

---

I hope this answer is helpful in showing how to implement URL-based culture switching that works both at runtime and during pre-rendering with BlazorWasmPreRendering.Build.

[drma-tech]

This doesn't work (at least not for resources). I had already tried it. I was researching more to understand how it works.

Resources are a special case that needs to be loaded during Blazor initialization (in this case, in program.cs).
Or during page refresh (I need to force load every time I change the language)
Navigation.NavigateTo("/pt/", forceLoad: true);

Then I discovered two things:

• 1 - There's a component that solves this (I haven't tested it yet):
  https://github.com/ScarletKuro/Blazor.WebAssembly.DynamicCulture

• 2 - And you can also do this in index.html

<script src="_framework/blazor.webassembly#[.{fingerprint}].js" autostart="false"></script>
<script>
    Blazor.start({
        configureRuntime: runtime => runtime.withConfig({
            loadAllSatelliteResources: true
        })
    })
</script>

This forces all assemblies to be loaded into memory, so when I change the CultureInfo (without force load), it applies the correct resource, because it's already in available memory. But before I try this component, see if you can apply this configuration "loadAllSatelliteResources" at the code level (Since you said that JavaScript doesn't run).

[jsakamoto]

@drma-tech
Ah, got it. So you're using .resx-based localization. That explains why dynamically switching the CurrentCulture during the Blazor component lifecycle isn't picking up the right .resx files.

Reading your reply, I’m a little worried you might not fully realize that BlazorWasmPreRendering runs as Blazor Server—or essentially, as a classic MPA (Multi-Page Application). Or perhaps you aren't familiar with how MPAs work in the first place? As I've been saying repeatedly, that JavaScript code isn't even executed during the prerendering process, so either way, the solution you described for Blazor Wasm simply won't work.

Anyway, one way to tackle this is to use a different localization solution, like the "Blazor I8n Text" library. That said, it’s not the most polished tool out there, so I wouldn’t exactly recommend it.

The better option is that, luckily, BlazorWasmPreRendering lets you inject ASP.NET Core middleware during the prerendering process. You should be able to leverage that to switch .resx files based on URL path parameters. I’m going to try and verify this for you, so just give me a bit more time.

[drma-tech]

No, I've never heard of MAP. From what I've researched, it's a multi-page app. So you create some kind of service like Blazor Server and access each of the pages. If you can implement this middleware, it will be great because it can be used for various other purposes. Or you can create some mechanism to have several services, one for each language (each with its own initialization).