SwagLanguagePack obsolete from Shopware 6.8: what shop owners should check now

In the GitHub description of the SwagLanguagePack plugin, Shopware has noted that it is considered obsolete from Shopware 6.8 and will no longer be compatible. This affects how translations will be provided in future. Here you can read what this means for shop owners and plugin developers and how to prepare the upgrade without losing translations.

The announcement is in the official repository description on GitHub and marks a clear cut: from Shopware 6.8, this language pack plugin is no longer compatible. This has direct consequences for shop owners who use the plugin and for developers of plugins that build on it. Review your upgrade and translation strategy now, plan compatibility checks and back up your existing language data. That way you spot missing or lost translations before they show up in the live shop.

What exactly has Shopware announced and where?

In the description of the official GitHub repository of the SwagLanguagePack plugin, Shopware has noted that the plugin is considered obsolete from Shopware 6.8 and will no longer be compatible. The decision is therefore documented and publicly visible. The repository note is the primary source.

The wording is unambiguous: the plugin is declared outdated for the upcoming major version. There is currently no additional official roadmap for the transition or for migration tools in this repository. So many details are still open. Until Shopware offers concrete tools, responsibility for migration and adaptation lies with shop owners and plugin developers. They have to develop their own strategies and run tests to avoid data loss and functional failures.

Shopware has reworked individual core processes and APIs in major releases before; usually the first community plugins follow until a standard emerges. At the moment there is only the repository note, without accompanying documentation or a migration guide. So the announcement is officially documented, but details on implementation are still missing.

What does this mean in practice for shop owners with several language packs?

If you use the SwagLanguagePack, you need to review your translation, update and deployment processes before updating to Shopware 6.8. Without adjustments, you risk missing or incorrect translations after the upgrade.

Concrete steps: first, determine which areas of the shop depend on the SwagLanguagePack (storefront, mail templates, back-end labels, CMS elements). Check whether translations are maintained locally in the theme, in third-party plugins or via the SwagLanguagePack. Then create a list of the affected files and templates and export existing language packs as CSV/JSON so that you can back them up independently of the plugin. A systematic approach reduces the risk. This is especially true with several languages and many customisations, where keys are easily lost or fallback mechanisms fail.

If you use a hosting or CI system, build a translation check into the staging workflow; in our experience, this saves time when troubleshooting. If translation data is stored in database tables, check the export and import options. Without preparatory checks, upgrading to 6.8 is risky. Back up and export your language data beforehand.

What are the consequences for developers of plugins and extensions?

Plugin developers must make sure their solutions no longer depend on the SwagLanguagePack and instead use the translation mechanisms Shopware intends. Direct dependencies on the plugin will lead to incompatibilities from 6.8. Test early and adapt your code.

Technically, this means: review the i18n implementation in your code, replace calls that explicitly reference the SwagLanguagePack and use core APIs or the methods documented by Shopware for registering translations. Store all translation strings in the usual plugin locales (Resources/translations or similar) and test loading and fallback logic without the language pack. Migration tests should cover unit and integration errors so that translation errors caused by regressions are spotted early.

Regarding package dependencies: remove Composer dependencies or feature toggles that require the SwagLanguagePack. Test plugins against a 6.8 alpha or RC environment as soon as one is available, and write migration tests that detect possible translation losses. In short, developers need to remove the dependencies and implement translation mechanisms that conform to the core.

Which alternatives for providing translations are realistic?

Typical alternatives are translations in theme and plugin resources, in central database tables or in external localisation services with import/export. Which option makes sense depends on the volume of translations and how often they are updated. Check the local resources first.

Options at a glance:

• Local plugin or theme translations: maintain translations in Resources/translations and roll them out via build/CI, suitable for static texts.
• Shopware core mechanisms: if Shopware 6.8 offers extended APIs for i18n, these should be used; documented core APIs are more stable in the long term.
• External translation management: tools with CSV/JSON export allow central maintenance and automated deployments, useful for many languages and frequent updates.

Each solution has pros and cons in terms of maintenance, performance and deployment effort. In the short to medium term, local resources or core APIs are the most practical alternatives.

How do you prepare an upgrade to Shopware 6.8 so that translations aren’t lost?

Start with an inventory of your translation sources, create export backups and test the upgrade on staging. This helps you detect missing strings or faulty fallbacks early.

Practical steps:

1. Export all translations from the SwagLanguagePack as CSV/JSON and store the files outside the shop installation.
2. Identify dependencies in plugins and themes; look for direct references to the plugin.
3. Create a staging instance with the target version 6.8 (or a pre-release), import the backup and run automated tests for the storefront, emails and back end.
4. Set up fallback mechanisms for critical areas (for example fallbacks to the default language) until a permanent solution is in place.

As a guideline, plan several sprints for analysis, migration and testing in more complex set-ups; the exact duration depends on the number of languages and the extent of customisation. A methodical approach with exports, staging tests and adjustments reduces the risk of the upgrade.

Is there a transition period or official migration help from Shopware?

At the time of the repository note, no official migration tools or transition periods are documented there. The note on GitHub only reports the obsolescence; Shopware would have to communicate any further help separately.

So don’t rely on an automatic migration by Shopware as long as no supplementary documentation or tools have been published. Follow the relevant Shopware channels and repository updates for hints on migration scripts, API changes or recommended approaches, and read the official 6.8 release notes as soon as they are available. If Shopware provides tools later, this may reduce the effort. Until then, local exports and tests are the most important strategy, and planning is up to shop owners and developers.

Frequently asked questions

Can I keep the SwagLanguagePack until after the upgrade?

If the plugin is considered obsolete in 6.8, it is no longer compatible; keeping it in the live system after an upgrade is likely to cause errors. Use staging tests, back up language data and migrate translations to other structures before the upgrade. We advise against keeping it.

Where can I find specific information on new translation mechanisms in Shopware 6.8?

Specific information is expected to appear in the official release notes and in the core repositories. Follow the relevant Shopware channels and check the 6.8 documentation as soon as it is published.

What is the quickest way to test whether my plugins are affected?

Run automated unit and integration tests in a 6.8 staging environment and search your code for direct references to the SwagLanguagePack. Export language files and check whether all required keys load without the plugin. Also test critical paths manually.

Are there short-term workarounds for critical translations?

In the short term, you can embed translations in theme or plugin resources and roll them out via deployment. However, this requires more maintenance than an implementation that conforms to the core and should only be a temporary solution.

Conclusion

With the SwagLanguagePack classified as obsolete from Shopware 6.8, things change directly for shop owners and developers. Check which translations depend on the plugin, back up all language files and plan upgrades on staging to detect compatibility problems. If you run or maintain plugins, remove the dependencies on the SwagLanguagePack and use translation mechanisms that conform to the core. If necessary, export language data to an external translation management system until a permanent solution is in place.

Our recommendation: analyse your translation sources first and add a test run for 6.8 to your release plan so that the live shop has no language gaps after the upgrade. If you would like support with this, find out more about our Shopware maintenance.