- Does lordjancso/translation-bundle work with Laravel?
- No. It is a Symfony bundle built on symfony/framework-bundle, Symfony's TranslatorInterface, dependency-injection service decoration and Doctrine ORM entity mapping, none of which Laravel provides or can emulate through configuration. Composer will happily install the vendor code into a Laravel app, but there is no bundle registration, no kernel registry and no DI extension contract to hook into, so nothing boots. Treat the stack mismatch as a hard blocker rather than an adapter task, and reimplement the pattern with a database-backed loader on the Laravel side if you want the capability.
- How do I install and register the Translation Bundle in a Symfony application?
- Install it with Composer, then register the bundle in your application's bundle list and create its configuration under your config directory. After that you run Doctrine migrations to create the message and locale tables, import your existing catalogs, and make sure the cache and resource directories are writable by the web user. Budget this as Symfony platform work rather than a single dependency bump, and wire an explicit translation cache clear into your publish workflow so edits appear immediately.
- Which PHP and Symfony versions does this bundle support?
- Do not assume a supported range. Open the require block in its composer.json and compare the declared PHP and symfony/* constraints against your LTS target before you spend any engineering time. A bundle that depends on framework-bundle internals is sensitive to major-version changes, so an undeclared or stale constraint is a real upgrade hazard rather than a formality.
- How does the bundle keep existing trans() calls working?
- It hooks into Symfony's translator, so your application code stays unchanged and existing trans() calls continue to resolve strings normally. The difference is that the message catalogue is loaded from database tables instead of static files, which is what allows texts to be edited at runtime without a redeploy. That also means catalogue changes take effect through your cache and publishing path, so plan for how and when the translation cache is refreshed.
- Do I need Doctrine and migrations to use it?
- Yes. The bundle ships Doctrine ORM entity mapping for translation and locale storage, so you need Doctrine configured and you need to run migrations to create the tables. Importing an existing catalogue into those tables is a separate task you will have to plan. Before deploying, ask the maintainer or read the source to confirm whether writes are atomic and lock-protected, because a translation manager is a write path into data your application reads at runtime.
- Is the translation editing interface secure out of the box?
- Do not assume it is. A web-facing translation editor is a privileged admin surface, and the realistic risks are unauthenticated route exposure, stored cross-site scripting through translation strings, and path traversal if any storage is file-backed. Confirm whether the bundle ships authentication and authorisation or whether securing the routes is entirely your responsibility, then put them behind an authenticated firewall with a role check before any non-local deployment. Review and sanitise rendered translation content as part of that work.
- What happens to my existing YAML or XLIFF translation files?
- If translations live in a Doctrine table while the application still ships YAML or XLIFF catalogues, you now have two sources of truth and a reconciliation problem that is a product decision, not just a technical one. Decide explicitly which store is canonical, import the files once, and document that the other is frozen. Check whether Symfony's native translation:extract and lint:translations tooling still behaves as expected alongside the database loader rather than being silently bypassed.
- Is the package actively maintained and safe for production?
- The health signals are weak: zero stars, zero dependents, a likely single maintainer and no observable production usage, which means little community pressure to fix defects and no evident CVE-response process. Commit recency, tagged releases and issue responsiveness should be checked directly rather than assumed. The MIT licence is the one clean positive, because it makes fork-and-own legally straightforward, so frame the decision as whether you want to own this code rather than whether you are allowed to.
- How big is the codebase, and should we fork it?
- Measure it before deciding: a fork is cheap if the code is small and well tested, and a quarterly liability if it is not. Check whether there is CI and meaningful test coverage, since you would be inheriting whatever exists. If you fork, pin the version, assign an explicit owner and treat security review of the admin surface as part of the onboarding work rather than a later ticket.
- Can we run it as a standalone translation tool against a shared database?
- That is one of the few genuine fits: a standalone Symfony service used purely as a translation-authoring tool against a database other applications read from. The cost is that schema drift becomes a shared ownership problem, so agree early on who owns the table schema and how changes are rolled out to consumers. For a Laravel stack, the cheaper option is usually to decline the dependency and build a small database-backed loader natively, keeping the entity schema idea and dropping the bundle.