Weave Code
Translation Bundle Laravel Package
lexik/translation-bundle
Symfony bundle to import translation files (xliff, yml, php) into a database, edit and add translations through a GUI, export them back to files, and check that every translation domain is fully translated. It overrides the translator service with a database loader.
LexikTranslationBundle is a Symfony bundle that moves translations from flat files into a database, adding a web GUI to edit them. It overrides the translator service with a DatabaseLoader, so database entries load last and override XLIFF, YAML, and PHP files.
Write your translation files as usual, import them via a console command, edit them in the browser, then export back to files whenever needed.
- Import translation files into the database
- Edit and add translations through a web GUI
- Overview of fully translated domains
- Export database translations back to files
- Database content overrides file-based translations
Frequently asked questions about Translation Bundle
- Can I install lexik/translation-bundle in a Laravel app with Composer?
- You can run the Composer command, but it will not give you a working feature. The package is a Symfony bundle that requires symfony/framework-bundle and related components, so installing it into a Laravel application pulls in a parallel framework stack that Laravel never boots. There is no service provider, no publishable config, and no route registration for Laravel. None of its translator override or database loader code is ever reached.
- Why doesn't the database translation override work in Laravel?
- The bundle works by decorating Symfony's translator service and registering a DatabaseLoader that implements Symfony's loader interface, so database rows load last and win over files. Laravel's Illuminate\Translation\Translator uses a different LoaderInterface and exposes no equivalent decoration hook. The package's central promise therefore cannot be replicated by simply requiring it. You would have to write your own database loader against Laravel's translation pipeline.
- What is the closest Laravel alternative to LexikTranslationBundle?
- spatie/laravel-translation-loader implements the database-backed loader half of the pattern: files seed the table, the database becomes the source of truth, and database values override file values. It does not ship an editing GUI, translation completeness overview, or file export, so pair it with your own admin screen and an artisan export command if you need those. That keeps you inside one runtime instead of running Symfony alongside Laravel.
- How do I build a translation editing GUI in Laravel?
- Put translations in a database table and expose it through Filament, Nova, or a small Livewire CRUD screen with per-domain and per-locale filters. Then read those rows back through a custom loader implementing Laravel's LoaderInterface, or use an existing database loader package. Add an artisan command that exports the table back to PHP or JSON files so deploys stay deterministic. This is roughly three to six sprints of work for a polished version, versus zero if files stay engineering-owned.
- Does lexik/translation-bundle support Laravel 11 or Laravel 12?
- No. Version 8.x targets Symfony 8 and depends on Symfony bundles, Doctrine ORM entities, Twig, Symfony Form, and security-csrf. There is no Laravel version constraint because it is not a Laravel package and has no Laravel integration path at all. Check Packagist for its Symfony compatibility matrix rather than looking for a Laravel release.
- Can I run the bundle as a separate admin app and share the database with Laravel?
- Yes, and this sidecar approach is the only realistic integration shape. Deploy a minimal Symfony application whose only responsibility is importing, editing, and exporting translations from the same MySQL or Postgres instance, then have Laravel read that table through its own loader implementation. You keep the working GUI, import and export commands, and completeness overview unchanged, and write roughly 200 lines of Laravel glue. Budget two to four sprints including authentication and CI, plus ongoing ownership of a second runtime and its CVE patching.
- How do I stop cached translations from hiding my database edits?
- This is the most common failure mode of the pattern: someone edits a row and nothing changes because a compiled or cached copy is served. In Laravel either flush a targeted cache key on write, or precompile the whole table into PHP arrays at deploy time. If you need sub-minute propagation you must have cache invalidation, not per-request queries. If deploy-time propagation is acceptable, skip the runtime loader entirely and export to files in CI.
- Does the database translation loader query the database on every request?
- Yes, unless something above it caches the result; the bundle's loader is not a caching layer. Under Laravel the same concern applies to any custom loader you write, so wrap lookups in Cache::rememberForever and invalidate on write. For high-traffic applications the safer route is generating PHP translation arrays during deployment and loading no database rows at runtime. Measure your translation volume (domains times locales times keys) before deciding.
- Is a Doctrine-managed translation table a problem for Laravel and Eloquent?
- It can be. Doctrine migrations create and evolve the schema while Eloquent assumes it is stable, and divergent migration histories become a recurring source of breakage. If you run the Symfony sidecar, give the table a single owner and treat it as read-only from Laravel. Alternatively, generate the schema once and manage all future changes through Laravel migrations, keeping the Symfony side schema-agnostic.
- Is lexik/translation-bundle actively maintained and safe for production?
- Recent 8.0.x releases landed in rapid succession and mostly chase Symfony 8 compatibility, which reads as compatibility firefighting rather than feature velocity. The listed Dependent count is zero and the release metadata looks unreliable, so verify the real latest tag and download numbers on Packagist before treating it as mature. For Laravel teams the maintenance question is largely moot, because you cannot consume it as a dependency anyway.
Weaver
How can I help you explore Laravel packages today?