- Is shchedrakov/translation-bundle a Laravel package?
- No. It is a Symfony2 bundle, a fork of the abandoned JMSTranslationBundle, and its architecture assumes the Symfony full-stack runtime: a Bundle class registered in AppKernel, DependencyInjection extensions that load service definitions at container compile time, annotation-driven routing for a translator UI, and Symfony console commands. Laravel has no bundle, compiler-pass, or kernel-bundle lifecycle, and the package ships no service provider, facade, or config stub. For Laravel you should use native lang files or a package such as spatie/laravel-translation-loader instead.
- What does shchedrakov/translation-bundle actually do?
- It moves application translations out of static YAML or XLIFF files and into database-backed storage so messages can be edited per locale without redeploying. It stores translation keys, messages, and locales, provides a management layer and browser-based translator UI, performs locale-aware lookups with fallback behaviour, and offers import and export to keep existing resource files in sync. The translator service still resolves keys through the familiar Symfony translator interface.
- Can I install shchedrakov/translation-bundle in Laravel 10 or 11 with Composer?
- No. The bundle's composer.json targets Symfony 2.x components plus doctrine/annotations and Twig of that era, while Laravel 10 and 11 pin Symfony 6 and 7 components transitively, so Composer refuses to resolve the dependency graph. Forcing it with --ignore-platform-reqs and an aliasing hack leaves you on an unsupported, unresolvable set of dependencies that will break on the next install or update. There is no supported install path into a modern Laravel application.
- Does it extract Laravel translation strings like __() and @lang?
- No. The extractors are written to recognise Symfony and Twig idioms such as the trans filter, $translator->trans('key'), and transChoice(). Laravel's __(), @lang, trans() with :placeholder interpolation, and pipe-delimited pluralisation would be silently missed. The resulting catalogs would be incomplete in a way that is expensive to detect, because missing keys simply fall back rather than throwing errors.
- What is a good Laravel alternative for database-backed translations?
- Start with Laravel's native lang/ files and the __() and @lang helpers, which already handle pluralisation and :placeholder replacement with zero added risk. If you genuinely need translations stored in the database and editable at runtime, spatie/laravel-translation-loader provides DB-backed catalogs, a translation model, and a loader that plugs into Laravel's translator. Both options avoid the framework mismatch entirely and are actively maintained.
- Is shchedrakov/translation-bundle still maintained?
- No. The last release was 2018-03-15, and the repository shows zero stars and zero dependents, with no community, no upstream fixes, and no security policy. The code targets Symfony 2.x and PHP 5.6/7.0-era idioms that are long past end of life. Adopting it means permanent internal maintenance rather than consuming a supported dependency.
- How do you install and configure it in a Symfony application?
- You add the package with Composer, register the bundle in AppKernel, and configure your entity manager and Doctrine mapping so the translation entities are persisted. Import and export console commands then let you seed the database from existing YAML or XLIFF resources and write changes back out. None of these steps have a Laravel equivalent, which is why the bundle cannot be dropped into a Laravel app.
- Are there security or licensing concerns with running it in production?
- Yes. The bundle ships an annotation-routed web UI that writes translation catalogs to disk, which is an additional attack surface, and the unmaintained codebase receives no security fixes. Because it is a fork of JMSTranslationBundle, the fork's license terms must be verified against the upstream JMS terms before you vendor or redistribute it. Treat any production use as an accepted, unmitigated risk.
- How do I migrate away from this bundle if a legacy Symfony 2 app already uses it?
- Treat the bundle as an extraction-only utility during the migration rather than a system of record. Dump the catalogs out via the export command, then move storage and lookup onto Laravel's native lang files or a TMS-backed workflow in the target application. Keep the Symfony app running read-only for translations until the new pipeline is verified, then retire the bundle.
- Should we build our own extraction tooling or buy a translation management system?
- Decompose the bundle's value: storage and lookup are solved natively in Laravel, so the only real gap is extraction and translator workflow. A thin internal extractor using nikic/php-parser for PHP string literals plus a Blade-aware pass for @lang and __() is roughly one to two engineer-weeks and will be far more accurate on Laravel code than the Symfony extractor. For the translator workflow itself, buy rather than build: a TMS such as Lokalise, Crowdin, Phrase, or Weblate with a Laravel push/pull command replaces the bundle's UI at a fraction of the ownership cost.