Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Translation Bundle

Translation Bundle Laravel Package

runroom/translation-bundle

Runroom Translation Bundle helps PHP applications manage multilingual translation resources, offering simple tools to organize, store, and retrieve translated messages so content stays consistent across locales and workflows.

View on GitHub
Deep Wiki
Context7

Manage translations on the Sonata Admin interface

Frequently asked questions about Translation Bundle
Is runroom/translation-bundle a Laravel package?
No. It is a Symfony bundle built for Symfony's DI container, Doctrine ORM and the Sonata Admin ecosystem, even though it is often listed alongside Laravel/PHP packages. There is no Laravel service provider, config file or Eloquent support, so it will not install or run in a Laravel application without a rewrite. The only portable idea is the pattern itself: storing translations in the database with an admin CRUD surface.
What does Runroom Translation Bundle actually do?
It moves translation catalogues out of developer-owned YAML/XLIFF files and into database rows that editors manage through Sonata Admin. It provides translation entities, admin classes, a database-backed translation loader and import/export tooling to seed the database from existing translation files. The practical win is that copy changes ship without a deploy. It is a conventional, low-ceremony bundle rather than a full translation management platform.
How do I install runroom/translation-bundle?
Install it with Composer, register the bundle in your Symfony application's bundle configuration, and run a Doctrine schema migration to create the translation tables. Then run the bundle's import command once to load your existing translation catalogues into the database. Pin exact versions of PHP, Symfony, Sonata Admin and Doctrine in composer.json before you start.
Which Symfony, Sonata Admin and PHP versions are supported?
The bundle targets Symfony 5/6-era applications that already run Sonata Admin and Doctrine, but you must check the composer.json constraints for the exact release you install. Compatibility needs to be pinned for PHP, the Symfony major/minor, Sonata Admin and the Doctrine DBAL driver, because all four matter. Release cadence follows Runroom's own project needs, so support is not guaranteed to track the newest Symfony release.
Can I use it with Laravel, Filament or Nova?
No. It depends on Symfony's DI container, Doctrine ORM and Sonata Admin, so there is nothing for Filament or Nova to hook into. Porting it would mean replacing the admin layer and the translation loader, which is rarely justified. For Laravel, spatie/laravel-translation-loader plus an admin UI is the closer off-the-shelf equivalent.
How do I import existing YAML or XLIFF translations into the database?
The bundle ships import/export tooling that reads your existing translation files and writes them into the translation tables. Before importing, inventory your catalogue: file count, key count, locales, pluralization and ICU message usage. Then diff the imported set against the source files to quantify anything lost in the conversion, since pluralized and parameterized messages are the usual casualties.
Does a database-backed translation loader hurt performance in production?
It can. Every translation key lookup risks becoming a query unless a caching layer is explicitly configured, which is the single most common production pitfall for this class of package. A cache warmer, Redis, or an in-process cache is essential before you switch the translator over. Measure with your real key count per request rather than assuming it will be fine.
How do I safely migrate from file-based translations to database translations?
Install and register the bundle in a feature branch, run the schema migration in a disposable environment, and import the catalogue. Switch the translator to the database loader behind a feature flag, keeping files as a fallback source for at least one release cycle. Freeze file edits, hand ownership to the admin UI, and document the new source of truth so the two catalogues do not drift.
How do I stop file and database translation catalogues from drifting apart?
Declare a single source of truth and enforce it: once the admin UI owns the copy, freeze direct edits to YAML/XLIFF files. The import/export commands are only safe when one direction is authoritative. Keep the old files read-only in the repository as a reference until the migration is fully validated.
Is runroom/translation-bundle actively maintained, and should I depend on it?
It has zero dependents and negligible stars, which suggests it is used primarily by its authors and that you would own the upgrade path, potentially via a fork. Sonata Admin is a mature but narrowing ecosystem, so betting translation management on it constrains future admin modernization. If you adopt it, pin versions and budget for a fork-and-own plan.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core