Wie der Titel bereits beschreibt, ist es im JTL- Shop 5.5.0 nicht möglich, auf der Startseite die Sprache von Deutsch auf eine andere Sprache zu wechseln.
Nach intensiver Analyse liegt bei mir ein reproduzierbares und systematisches Problem vor, das nicht eingeloggte Benutzer betrifft und im direkten Zusammenhang mit 404-Seiten, Routing und der Startseite steht.
Ausgangslage
- Mehrsprachiger JTL-Shop (DE, EN, FR, UA)
- Sprachumschaltung aktiv
- Unterseiten lassen sich korrekt in andere Sprachen wechseln
- Startseite ist in mehreren Sprachen vorhanden
- Problem tritt ausschließlich ohne Login auf der Startseite auf
- Ein nicht eingeloggter Benutzer landet direkt auf der Startseite.
- Im Sprachmenü kann eine andere Sprache ausgewählt werden.
- Die Auswahl wird jedoch nicht übernommen:
- Die Startseite bleibt weiterhin Deutsch.
- Erst beim Wechsel auf ein Untermenü bzw. eine Unterseite wird die Seite korrekt in der gewählten Sprache angezeigt.
- Diese Unterseite muss zusätzlich erneut aufgerufen werden, damit die Sprache greift (wirkt äußerst unprofessionell).
- Wird anschließend der Browser-Zurück-Button verwendet, um zur Startseite zurückzukehren, erscheint diese erneut in Deutsch, trotz zuvor aktiv gewählter Sprache.
Dieses Verhalten ändert sich, wenn der Benutzer zufällig eine 404-Seite bekommt und über den angezeigten Link zu → Homepage navigiert.
In diesem Fall wird die Startseite zwar korrekt in der zuvor gewählten Sprache angezeigt, allerdings ist die Sprachumschaltung anschließend auf der Startseite in dieser Sprache blockiert.
Beobachtetes Verhalten - 404 - Homepage
- Der Benutzer befindet sich auf einer Seite, die in der gewählten Sprache nicht existiert.
- Beim Sprachwechsel wird korrekt die jeweilige 404-Seite angezeigt.
- Auf der 404-Seite befindet sich ein Link „Homepage“.
- Klickt man auf diesen Link, landet man auf der Startseite in der zuvor gewählten Sprache.
- Ab diesem Zeitpunkt ist die Sprachumschaltung auf der Startseite nicht mehr möglich – die Sprache ist faktisch eingefroren.
- Erst über den Browser-Zurück-Button gelangt man wieder in einen Zustand, in dem die Sprachumschaltung funktioniert.
- JTL erzwingt unterschiedliche SEO-Slugs für die 404-Seite je Sprache:
- 404, 404_1, 404_2, …
- Identische Slugs pro Sprache sind by design nicht möglich.
- Unabhängig vom verwendeten 404-Slug tritt das beschriebene Verhalten reproduzierbar auf.
- Der „Homepage“-Link auf der 404-Seite lässt sich nicht über das Backend konfigurieren.
- Der Link scheint auf eine sprachlose Startseiten-Route (/) zu verweisen.
- Nach diesem Aufruf wird die Startseite offenbar als finaler Fallback behandelt.
- Die Sprachlogik wird anschließend nicht erneut ausgewertet.
- Ein Sprachwechsel auf der Startseite sollte sofort die gewählte Sprache anzeigen – auch für Gastbenutzer.
- Der „Homepage“-Link auf der 404-Seite sollte auf die sprachkontextuelle Startseite verweisen (z. B. /en/, /fr/).
- Die Sprachumschaltung sollte konsistent funktionieren, unabhängig davon, ob der Benutzer
- direkt auf die Startseite kommt,
- über eine Unterseite navigiert,
- oder über eine 404-Seite zurückgeführt wird.
- Sprachumschaltung auf Unterseiten funktioniert korrekt.
- Auf der Startseite wird die Sprache bei Gastbenutzern erst nach Navigation auf eine Unterseite korrekt angewendet.
- Der Pfad 404 → Homepage führt zu einem Zustand, in dem die Startseite sprachlich fixiert ist.
- Das Verhalten wirkt wie ein Sonderfall im Zusammenspiel von
- 404-Handling,
- SEO-Slugs (404_1, 404_2, …),
- und Startseiten-Routing.
Wie ist im JTL-Shop konzeptionell vorgesehen, dass
- die Startseite für Gastbenutzer sofort in der gewählten Sprache angezeigt wird,
- die Sprachumschaltung unabhängig vom Navigationspfad konsistent funktioniert,
- und 404-Fallbacks nicht zu einem Sprach-Lock führen?
Gibt es hierfür eine empfohlene Konfiguration (CMS / SEO / Routing),
eine vorgesehene Template-Lösung,
oder handelt es sich um eine bekannte Limitation bzw. einen Bug?
Allen noch schöne Weihnachts-Feiertage.
TDS2018
Fehlerbild & Fazit nach intensiver Analyse
Nach stundenlanger systematischer Fehlersuche zeigt sich zusätzlich ein grundlegendes Problem im Zusammenspiel zwischen JTL-Wawi, JTL-Shop und internationalisierten Inhalten (kyrillisch).
Reproduzierbarer Befund
- JTL-Wawi akzeptiert kyrillische Zeichen in Artikelgruppen.
- Der Abgleich zum JTL-Shop läuft fehlerfrei durch.
- Kyrillische Bezeichnungen werden im Shop-Menü korrekt angezeigt.
- Beim Klick auf ein kyrillisches Menü erzeugt der Shop jedoch keine gültigen Links → 404.
- Ursache ist eine Inkompatibilität im Routing / Slug-Handling zwischen Wawi und Shop bei nicht-lateinischen Zeichen.
Warum lässt die Startseite des Shops keine saubere Sprachumschchaltung zu
(inkl. Sonderfall 404 → Homepage),
während Unterseiten korrekt reagieren?
Dieses Verhalten verschärft das Problem zusätzlich und macht die Internationalisierung faktisch unzuverlässig.
Fazit
Dass kyrillische Inhalte in JTL-Wawi erlaubt, im Shop sichtbar, aber nicht routbar sind, ist für international tätige deutsche Unternehmen und deren Kunden IMHO nicht tragbar.
In Kombination mit der fehlerhaften Sprachlogik der Startseite entsteht ein strukturelles Problem.
Programmierer – hier besteht klarer Handlungsbedarf auf Framework-Ebene
(Slug-Normalisierung, Routing-Konsistenz, Sprachkontext auf der Startseite).
Zuletzt bearbeitet:
