SwagLanguagePack ab Shopware 6.8 obsolet: Was Shopbetreiber jetzt prüfen sollten

Shopware hat in der GitHub-Beschreibung des Plugins SwagLanguagePack vermerkt, dass es ab Shopware 6.8 als obsolet gilt und nicht mehr kompatibel sein wird. Das betrifft, wie Übersetzungen künftig bereitgestellt werden. Hier lesen Sie, was das für Shopbetreiber und Plugin-Entwickler bedeutet und wie Sie das Upgrade vorbereiten, ohne Übersetzungen zu verlieren.

Die Ankündigung steht in der offiziellen Repository-Beschreibung auf GitHub und ist ein klarer Schnitt: Ab Shopware 6.8 ist dieses Sprachpaket-Plugin nicht mehr kompatibel. Das hat direkte Folgen für Shopbetreiber, die das Plugin nutzen, und für Entwickler von Plugins, die darauf aufsetzen. Prüfen Sie jetzt Ihre Upgrade- und Übersetzungsstrategie, planen Sie Kompatibilitäts-Checks ein und sichern Sie vorhandene Sprachdaten. So erkennen Sie fehlende oder verlorene Übersetzungen, bevor sie im Live-Shop auffallen.

Was genau hat Shopware angekündigt und wo steht das?

Shopware hat in der Beschreibung des offiziellen GitHub-Repositorys des Plugins SwagLanguagePack vermerkt, dass das Plugin ab Shopware 6.8 als obsolet gilt und nicht mehr kompatibel sein wird. Damit ist die Entscheidung dokumentiert und öffentlich einsehbar. Die Repository-Notiz ist die primäre Quelle.

Die Formulierung ist eindeutig: Das Plugin wird für die kommende Major-Version als veraltet erklärt. Eine zusätzliche offizielle Roadmap zur Umstellung oder zu Migrationswerkzeugen gibt es in diesem Repository derzeit nicht. Viele Details sind also offen. Bis Shopware konkrete Werkzeuge anbietet, liegt die Verantwortung für Migration und Anpassung bei Shopbetreibern und Plugin-Entwicklern. Sie müssen selbst Strategien entwickeln und Tests anstoßen, um Datenverlust und Funktionsausfälle zu vermeiden.

Shopware hat in größeren Releases schon öfter einzelne Kernprozesse und APIs umgebaut; meist ziehen die ersten Community-Plugins nach, bis sich ein Standard herausbildet. Aktuell liegt nur die Repository-Notiz vor, ohne Begleitdokumentation oder Migrationsanleitung. Die Ankündigung ist also verbindlich dokumentiert, Details zur Umsetzung fehlen bislang.

Was bedeutet das praktisch für Shopbetreiber mit mehreren Sprachpaketen?

Wer das SwagLanguagePack einsetzt, muss Übersetzungs-, Update- und Deployment-Prozesse prüfen, bevor er auf Shopware 6.8 aktualisiert. Ohne Anpassung riskieren Sie fehlende oder fehlerhafte Übersetzungen nach dem Upgrade.

Konkrete Schritte: Bestimmen Sie zuerst, welche Bereiche des Shops vom SwagLanguagePack abhängen (Storefront, Mailtemplates, Backend-Labels, CMS-Elemente). Prüfen Sie, ob Übersetzungen lokal im Theme, in Drittanbieter-Plugins oder über das SwagLanguagePack gepflegt werden. Erstellen Sie anschließend eine Liste der betroffenen Dateien und Templates und exportieren Sie vorhandene Sprachpakete als CSV/JSON, damit Sie sie unabhängig vom Plugin sichern können. Ein systematisches Vorgehen senkt das Risiko. Das gilt besonders bei mehreren Sprachen und vielen individuellen Anpassungen, weil dort leicht Schlüssel verloren gehen oder Fallback-Mechanismen versagen.

Wenn Sie ein Hosting- oder CI-System nutzen, bauen Sie einen Übersetzungs-Check in den Staging-Workflow ein; erfahrungsgemäß spart das Zeit bei der Fehlersuche. Liegen Übersetzungsdaten in Datenbanktabellen, prüfen Sie die Export- und Importmöglichkeiten. Ohne vorbereitende Prüfungen ist ein Upgrade auf 6.8 riskant. Sichern und exportieren Sie die Sprachdaten vorher.

Welche Folgen hat das für Entwickler von Plugins und Erweiterungen?

Plugin-Entwickler müssen sicherstellen, dass ihre Lösungen nicht mehr vom SwagLanguagePack abhängen und stattdessen die von Shopware vorgesehenen Mechanismen für Übersetzungen nutzen. Direkte Abhängigkeiten auf das Plugin führen ab 6.8 zu Inkompatibilitäten. Testen Sie früh und passen Sie den Code an.

Technisch heißt das: Prüfen Sie die i18n-Implementierung in Ihrem Code, ersetzen Sie Aufrufe, die das SwagLanguagePack explizit referenzieren, und nutzen Sie Core-APIs oder die von Shopware dokumentierten Wege zur Registrierung von Übersetzungen. Legen Sie alle Übersetzungsstrings in den üblichen Plugin-Locales ab (Resources/translations o. Ä.) und testen Sie Lade- und Fallback-Logik ohne das Sprachpaket. Migrationstests sollten Unit- und Integrationsfehler abdecken, damit Übersetzungsfehler durch Regressionen früh auffallen.

Zu Paketabhängigkeiten: Entfernen Sie Composer-Abhängigkeiten oder Feature-Toggles, die das SwagLanguagePack voraussetzen. Testen Sie Plugins gegen eine 6.8-Alpha- oder RC-Umgebung, sobald verfügbar, und erstellen Sie Migrationstests, die mögliche Übersetzungsverluste erkennen. Entwickler müssen also Abhängigkeiten entfernen und Core-konforme Übersetzungsmechanismen umsetzen.

Welche Alternativen zur Bereitstellung von Übersetzungen sind realistisch?

Typische Alternativen sind Übersetzungen in Theme- und Plugin-Ressourcen, in zentralen Datenbanktabellen oder in externen Lokalisierungsdiensten mit Import/Export. Welche Option sinnvoll ist, hängt von Umfang und Aktualisierungshäufigkeit der Übersetzungen ab. Prüfen Sie zuerst die lokalen Ressourcen.

Optionen im Überblick:

• Lokale Plugin- oder Theme-Übersetzungen: Übersetzungen in Resources/translations pflegen und über Build/CI ausrollen, geeignet für statische Texte.
• Shopware-Core-Mechanismen: Wenn Shopware 6.8 erweiterte APIs für i18n anbietet, sollten diese genutzt werden; dokumentierte Core-APIs sind langfristig stabiler.
• Externe Übersetzungsverwaltung: Tools mit CSV/JSON-Export erlauben zentrale Pflege und automatisierte Deployments, sinnvoll bei vielen Sprachen und häufigen Updates.

Jede Lösung hat Vor- und Nachteile bei Wartung, Performance und Deployment-Aufwand. Kurz- bis mittelfristig sind lokale Ressourcen oder Core-APIs die praktikabelsten Alternativen.

Wie bereiten Sie ein Upgrade auf Shopware 6.8 vor, damit Übersetzungen nicht verloren gehen?

Machen Sie zuerst eine Bestandsaufnahme der Übersetzungsquellen, legen Sie Export-Sicherungen an und testen Sie das Upgrade auf Staging. So erkennen Sie früh fehlende Strings oder fehlerhafte Fallbacks.

Praxis-Schritte:

1. Exportieren Sie alle Übersetzungen aus dem SwagLanguagePack als CSV/JSON und sichern Sie die Dateien außerhalb der Shop-Installation.
2. Identifizieren Sie Abhängigkeiten in Plugins und Themes; suchen Sie nach direkten Referenzen auf das Plugin.
3. Erstellen Sie eine Staging-Instanz mit der Zielversion 6.8 (oder einer Vorabversion), spielen Sie das Backup ein und führen Sie automatisierte Tests für Storefront, E-Mails und Backend durch.
4. Richten Sie für kritische Bereiche Fallback-Mechanismen ein (zum Beispiel Fallbacks auf die Standardsprache), bis eine endgültige Lösung steht.

Als Richtwert: Planen Sie für komplexere Setups mehrere Sprints für Analyse, Migration und Tests ein; die genaue Dauer hängt von der Anzahl der Sprachen und dem Umfang individueller Anpassungen ab. Ein methodisches Vorgehen mit Export, Staging-Tests und Anpassungen senkt das Risiko beim Upgrade.

Gibt es eine Übergangsfrist oder offizielle Migrationshilfen von Shopware?

Zum Zeitpunkt der Repository-Notiz sind dort keine offiziellen Migrationswerkzeuge oder Übergangsfristen dokumentiert. Der Hinweis auf GitHub meldet nur die Obsoleszenz; weitere Hilfen müsste Shopware gesondert kommunizieren.

Verlassen Sie sich deshalb nicht auf eine automatische Migration durch Shopware, solange keine ergänzende Dokumentation oder Tools veröffentlicht sind. Verfolgen Sie die relevanten Shopware-Kanäle und Repository-Updates, um Hinweise auf Migrationsskripte, API-Änderungen oder empfohlene Vorgehensweisen zu bekommen, und lesen Sie die offiziellen Release-Notes zu 6.8, sobald sie verfügbar sind. Falls Shopware später Tools bereitstellt, kann das den Aufwand senken. Bis dahin sind lokale Exporte und Tests die wichtigste Strategie, die Planung liegt bei Shopbetreibern und Entwicklern.

Häufige Fragen

Kann ich das SwagLanguagePack bis nach dem Upgrade behalten?

Wenn das Plugin in 6.8 als obsolet gilt, ist es nicht mehr kompatibel; es nach einem Upgrade im Live-System zu behalten, führt wahrscheinlich zu Fehlern. Nutzen Sie Staging-Tests, sichern Sie Sprachdaten und migrieren Sie Übersetzungen vor dem Upgrade in andere Strukturen. Wir raten davon ab.

Wo finde ich konkrete Hinweise zu neuen Übersetzungsmechanismen in Shopware 6.8?

Konkrete Hinweise werden voraussichtlich in den offiziellen Release-Notes und in den Core-Repositories erscheinen. Verfolgen Sie die relevanten Shopware-Kanäle und prüfen Sie die 6.8-Dokumentation, sobald sie veröffentlicht ist.

Wie teste ich am schnellsten, ob meine Plugins betroffen sind?

Führen Sie automatisierte Unit- und Integrationstests in einer 6.8-Staging-Umgebung aus und suchen Sie im Code nach direkten Referenzen auf das SwagLanguagePack. Exportieren Sie Sprachdateien und prüfen Sie, ob alle nötigen Keys ohne das Plugin geladen werden. Testen Sie kritische Pfade zusätzlich manuell.

Gibt es kurzfristige Workarounds für kritische Übersetzungen?

Kurzfristig können Sie Übersetzungen in Theme- oder Plugin-Ressourcen einbetten und per Deployment ausrollen. Das ist allerdings wartungsintensiver als eine Core-konforme Umsetzung und sollte nur eine Übergangslösung sein.

Fazit

Mit der Einstufung des SwagLanguagePack als obsolet ab Shopware 6.8 ändert sich für Shopbetreiber und Entwickler direkt etwas. Prüfen Sie, welche Übersetzungen von dem Plugin abhängen, sichern Sie alle Sprachdateien und planen Sie Upgrades auf Staging, um Kompatibilitätsprobleme zu erkennen. Wenn Sie Plugins betreiben oder pflegen, entfernen Sie die Abhängigkeiten vom SwagLanguagePack und nutzen Sie Core-konforme Übersetzungsmechanismen. Falls nötig, exportieren Sie Sprachdaten in ein externes Übersetzungsmanagement, bis eine dauerhafte Lösung steht.

Unsere Empfehlung: Analysieren Sie zuerst die Übersetzungsquellen und nehmen Sie einen Testlauf für 6.8 in Ihren Release-Plan auf, damit der Live-Shop nach dem Upgrade keine Sprachlücken hat. Wenn Sie dabei Unterstützung möchten, finden Sie mehr zu unserer Shopware-Wartung.