Kultur & URL-Routing

Auf einem mehrsprachigen Portal, in dem die aktive Sprache in der URL liegt – und wie sich das Wechseln der Sprache verhält – ist mit einer einzigen Option konfigurierbar, UrlCultureStrategy. Sie steuert den gesamten Stack konsistent: das Request-Routing des Servers, die href- und SEO-Tags des Blazor-Dokuments sowie sowohl <LanguageDropdown /> auf Blazor als auch auf React sind sich alle einig, wo die Sprache hingehört. Einsprachige Portale bleiben unbeeinträchtigt – es gibt nichts zu verhandeln, sodass jede Strategie identisch funktioniert.

Wie die Sprache in der URL erscheint

Drei Strategien stehen zur Verfügung. Der Standard behält das Verhalten bei, das vor der Existenz der Option ausgeliefert wurde, sodass bestehende Portale keine Änderungen benötigen.

PfadPräfix (Standard)

Die Standardsprache wird bei nackten URLs und jeder anderen Sprache unter einem /{culture} Pfadpräfix bereitgestellt:

• /contacts – der Standardsprache, ohne Präfix.
• /fr/contacts – jede nicht-standardmäßige Sprache, unter ihrem Kulturpräfix.
• Eine präfixierte Standard-Sprach-URL (/en/contacts) leitet dauerhaft auf das nackte Formular um, und ein Erstbesucher, dessen Browser Accept-Language mit einer unterstützten nicht-standardisierten Sprache übereinstimmt, wird auf die präfixierte URL dieser Sprache weitergeleitet – sodass jede Seite pro Sprache eine kanonische, crawlbare Adresse hat.

PathPrefixAll

Jede Sprache ist präfixiert, einschließlich des Standard-— , /en/contacts/fr/contacts , — für eine einzelne, symmetrische URL-Form ohne spezielles unpräfixiertes Standard. Eine nackte Seiten-URL leitet auf das Präfix der aufgelösten Sprache um (übernommen aus dem Kulturcookie oder Accept-Language, und fällt auf die Standardsprache zurück).

CookieOnly

Die Sprache erscheint in der URL nie. Es wird vom .AspNetCore.Culture Cookie gelöst (zurück auf Accept-Language) und an Ort und Stelle angewendet – keine Umleitungen, keine Pfadumschreibung. Am besten für SPA-ähnliche Portale, die die Sprache wechseln, ohne navigieren zu müssen.

Wahl einer Strategie

Leg die Strategie fest, wo LocalizationOptions du die Lokalisierung in deinem Host konfigurierst. Standardmäßig steht PathPrefix, also ist dies ein opt-in:

Das ist die einzige Verkabelung, die benötigt wird – dieselbe Option steuert die Blazor- und React-Hosts (beide identisch konfiguriert LocalizationOptions ), und alles darunter folgt daraus.

Basis href, kanonisch und hreflang – für dich erledigt

Unabhängig von der gewählten Strategie hält das Framework das URL-Identitäts-Markup jeder Seite synchron damit, sodass Suchmaschinen und der Blazor-Kreis sich immer darauf einigen, wo sich eine Sprache befindet:

• Basis-href – das Dokument <base href> verfolgt die Pfadbasis der Anfrage, sodass die vorgerenderte Seite und die Blazor-Server-Leitung denselben Anwendungsroot unter jedem Präfix auflösen.
• Kanonische URL – jede Seite bewirbt ihre kanonische Adresse in der aktiven Sprache, vorgegeben oder nackt gemäß der Strategie.
• hreflang wechselt – ein alternativer Link pro unterstützter Sprache plus x-default, der jeweils auf die URL dieser Sprache für die aktuelle Seite zeigt.

Zwei Framework-Komponenten erzeugen dieses Markup – <CultureBaseHref /> für das Basis-HREF und <CultureAlternateLinks /> für die kanonischen, hreflang- und Open-Graph-Lokaltags. Beide sind direkt praxisorientiert PowerPortalsPro.Web.Blazor.Components und strategisch bewusst; die Demo verbindet sie mit seiner App.razor SEO-Head-Komponente:

Sprachwechsel

Auf beiden Stacks <LanguageDropdown /> werden die konfigurierten Sprachen des Portals aufgelistet und die aktive Sprache gewechselt, wenn der Nutzer auswählt. Es folgt automatisch der konfigurierten Strategie:

Bei einer Präfix-Strategie navigiert der Switch zur URL der gewählten Sprache, sodass die Seite an ihrer kanonischen, korrekt präfixierten Adresse neu lädt. Darunter CookieOnly schaltet es über den Kulturkeks an Ort und Stelle, ohne Navigation. So oder so wird der Cookie gesetzt, sodass jede andere Oberfläche mit gleichem Ursprung synchron bleibt.

Die Strategie in der benutzerdefinierten Benutzeroberfläche lesen

Eigene Switcher- oder sprachbewusste Links bauen? Lesen Sie die aktive Strategie direkt – serverseitig in LocalizationOptions Blazor oder aus dem Lokalisierungsmanifest in React, wo buildLocalePath() sie in die URL einer Sprache für die aktuelle Seite umgewandelt wird:

Anmerkung

Alles oben Genannte tritt nur dann in Kraft, wenn ein Portal mehr als eine UI-Kultur unterstützt. Eine Single-Culture-Seite bedient jede Seite mit ihrer Bare-URL, unabhängig von der Strategie, sodass es keine Umleitungs- oder Präfix-Kosten für Sprachen gibt, die Sie nicht veröffentlichen.