Was lehrt dieser Artikel? #
Dieser Artikel zeigt Ihnen, wie ich es geschafft habe, die URLs dynamischer Seiten zu übersetzen, mit anderen Worten: Slugs. Normalerweise verwenden wir für jede Übersetzung eines dynamisch erstellten Inhalts denselben Slug. In diesem Beitrag zeige ich Ihnen, wie Sie verschiedene Slugs für jedes Gebietsschema verbinden können, wie man sie abfragt und wie man das Problem durch die Erstellung einer dynamischen Sprachumschaltkomponente in Next.js 13 App Router löst.
Abfrage nach verschiedenen Schneckenarten #
Die Lokalisierung mit Sanity.io ist ziemlich einfach. Allerdings müssen Sie möglicherweise einige Plugins verwenden, wenn Sie Ihre Anwendung skalieren möchten. Ich habe die Strategie der Dokument-Internationalisierung mit diesem Plugin auf meine blog Beiträge angewendet. Wenn Sie den obigen Link überfliegen, können Sie offensichtlich herausfinden, dass Sie für ein Dokument so viele Übersetzungen erstellen können, wie Sie möchten, und je nach Ihrer Konfiguration verschiedene Dokumente als Übersetzung aufeinander verweisen und alle übersetzten Felder eines Dokuments in Form eines Arrays mit einer groq Abfrage ähnlich der untenstehenden abrufen können. Übrigens haben die meisten Headless CMS graphQL oder andere tools, um die Felder abzufragen und diese Dokumente auf ähnliche Weise zu verbinden. Daher; Sanity ist nur mein Weg der Präferenz, aber Sie bekommen die Idee.
Bis jetzt ist alles in Ordnung. Das Problem tritt auf, wenn der Benutzer die Sprache auf einer Blog Seite wechselt. Das größte Problem für mich war, wie ich den Benutzer auf die andere übersetzte Version des Dokuments umleiten kann. Denken Sie daran, dass unser Slug unser Hauptparameter für das Abrufen von Daten auf der Seite /[lng]/blogs/[slug] ist. Nehmen wir an, die URL lautet /en/how-to-solve-language-switch-in-localized-sanity-documents. Wenn ein Benutzer die Sprache wechselt, wird daraus /tr/how-to-solve-language-switch-in-localized-sanity-documents. Diesmal gibt es kein Dokument mit dem Slug-Parameter how-to-solve-language-switch-in-localised-sanity-documents für die Sprache tr in Ihrer Anfrage. Zunächst habe ich versucht, dieses Problem zu lösen, indem ich darauf geachtet habe, für alle Sprachen eines Dokuments in Sanity denselben Slug zu verwenden, aber dann wollte ich die Slugs für eine bessere SEO-Erfahrung an die jeweiligen Sprachen anpassen.
App-Router-Layout neu überdenken #
Das Problem dabei ist, dass wir für eine bessere SEO-Kompatibilität unterschiedliche Slugs für jedes Gebietsschema benötigen. In diesem Fall habe ich jedoch ein anderes Problem. In meinem Projekt hatte ich eine layout.ts, die sich in meinem (pages) Ordner befindet und alle Seiten einschließlich [slug].ts umschließt. Der Header, der die Sprachumschalter-Komponente umschließt, wird in diesem Layout gerendert. Ein einziger Sprachumschalter für alle Seiten schien also anfangs eine gute Idee zu sein.
Dieser Switcher scheint nicht dynamisch für meine [slug].ts Seite zu sein, so dass ich mich entschlossen habe, meine Seitenaufteilung zu überdenken.
Dies ist die neue Ordnerstruktur, die ich geplant habe.
Überarbeitung des alten Sprachumschalters #
Und ich habe jetzt das Layout mit statischen Sprachwechsler-Optionen von meiner [slug].ts Seite entfernt. Alles, was ich tun muss, war meine getPageData Funktion anzupassen, die ursprünglich verwendet wurde, um Blog-Post zu holen und ihn als Prop zu übergeben und andere übersetzte Dokumente Slugs als headerLinks hinzuzufügen.
Und übergeben Sie diese headerLinks als dynamicLinks prop an die Komponente LanguageSelector.ts.
And voila !
