Translation Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and mismatched at the framework level. Despite the framing of this review, shchedrakov/translation-bundle is not a Laravel package. It is a Symfony2 bundle (a fork of the long-abandoned JMSTranslationBundle), and its entire architecture assumes the Symfony full-stack runtime: a Bundle class registered in AppKernel, a DependencyInjection/*Extension that loads XML/YAML service definitions at container compile time, annotation-driven routing for a browser-based translator UI, and console commands wired through symfony/console and the Symfony Application. Laravel has no equivalent bundle/compiler-pass/kernel-bundle lifecycle. There is no service provider, no facade, no config stub — nothing that would let composer require resolve into a working Laravel application.

Integration feasibility — effectively blocked at dependency resolution. The bundle's composer.json targets Symfony 2.x components (symfony/framework-bundle, symfony/http-kernel, doctrine/annotations, twig/twig of that era). Laravel 10/11 pin Symfony 6/7 components transitively. Composer will refuse to install due to hard constraint conflicts; forcing it requires --ignore-platform-reqs plus an aliasing hack, which lands us in an unsupported, unresolvable dependency graph. Even if installed, the extractors are written to recognise Symfony/Twig translation idioms — {{ 'key'|trans }}, $translator->trans('key'), transChoice() — and would silently miss Laravel's __(), @lang, trans() with :placeholder interpolation, and |-delimited pluralisation. The extracted catalogs would be wrong in a way that is expensive to detect.

Technical risk — high and unmitigated.

Key questions for the requester:

1. What problem are we actually solving — extraction of translatable strings, workflow for translators, or storage/lookup at runtime? The bundle's value is concentrated in extraction + a translator UI; Laravel already solves storage and lookup natively.
2. Do we already have a TMS (Lokalise, Crowdin, Phrase, Weblate) or is the intent to build one in-house? If we have one, this package is redundant.
3. What is the locale footprint and translator headcount? A translator UI only pays for itself at meaningful scale.
4. Is there a specific fork behaviour (e.g., a custom extractor) we need, or is this a "looks close enough" find?
5. Who owns the fork if we adopt it? Adoption here means permanent internal maintenance, not consumption of a dependency.

Integration Approach

Stack fit: do not integrate the bundle. Decompose its value. The bundle bundles three concerns; each has a better-fit answer in a Laravel stack:

• Storage & lookup → Laravel's native lang/ files (__(), @lang, pluralisation, :placeholder replacement) or spatie/laravel-translation-loader if DB-backed catalogs are required. Native, zero risk.
• Extraction → build a thin internal extractor: nikic/php-parser for PHP string-literal discovery plus a Blade-aware regex/parser pass for @lang/__() in templates. Roughly 1–2 engineer-weeks, and it will be more accurate on Laravel code than the Symfony extractor ever could be.
• Translator workflow → buy, don't build. A TMS with an API and a Laravel push/pull command replaces the bundle's web UI at a fraction of the ownership cost.

Migration path (if the org already runs this bundle on a legacy Symfony 2 app): treat it as an extraction-only utility during migration. Run one final jms:translation:extract against the legacy codebase, export the catalogs as XLIFF/PO, and import them into the Laravel lang/ tree or the TMS. Then retire the bundle with the Symfony app. Do not carry it forward.

Compatibility: any attempt to keep the bundle alive requires vendoring classes into app/Support/ or a private internal/translation-extractor repo, stripping the DI/console/routing integration, and pinning symfony/translation to a modern version. That is a rewrite, not an integration — budget it as such.

Sequencing:

1. Spike (3–5 days): attempt composer require in a throwaway Laravel skeleton to produce a concrete, citable conflict report. Cheap, removes ambiguity, and gives the requester evidence rather than opinion.
2. Value-mapping workshop (1 day): confirm which of the three concerns is actually needed.
3. Decision gate: almost certainly "build extractor + buy TMS" or "native lang/ only."
4. Implementation: extractor + TMS connector behind php artisan translations:pull|push, with tests asserting extraction parity against a fixture corpus.
5. Legacy run-off: one-off export from the old Symfony app; decommission.

Operational Impact

Maintenance. Upstream maintenance is zero — 0 stars and 0 dependents is the quantitative signal that nobody is watching this repository. Adopting it means we inherit the entire maintenance burden: PHP version bumps, Symfony component churn, security patches, and any bug in the extraction or UI layers. Realistically that is 0.1–0.2 FTE of standing ownership for a capability we can otherwise buy or build once.

Support. No vendor, no maintainer responsiveness, no issue triage. Internal escalation path is "the one engineer who read the Symfony 2 source." Documentation is limited to legacy JMS docs from the early 2010s, which describe behaviour this fork may or may not match. Onboarding cost is high relative to the small surface area of the problem.

Scaling. Translation volume is rarely a bottleneck, so throughput is not the concern. The concerns are: (a) the extraction command is a full-codebase parse — on a large app it must be chunked or it becomes a memory and CI-time problem; (b) the translator UI writes catalog files to the filesystem, which does not survive horizontal scaling or containerised deploys without shared storage; (c) it will interact badly with Laravel's config/route/event caches, since it assumes Symfony's container-compile model. None of these are fatal in isolation; together they mean a bespoke operational runbook for a non-core capability.

Failure modes to watch. Silent under-extraction is the dangerous one — strings simply never appear in the catalog, ship untranslated, and are discovered by users rather than by CI. Second is catalog overwrite: the UI writes files that may also be edited in-repo, producing merge conflicts and lost translator work. Third is encoding corruption on non-UTF-8 source files. Mitigation for all three is the same: never adopt this; if a legacy app depends on it, wrap the final export in a diff-and-review step before import.

Ramp-up. For a team without Symfony 2 exposure, expect 2–4 weeks before an engineer is productive in the bundle's internals — disproportionate for a translation tooling need, and sunk cost if we later move to a TMS anyway.

Recommendation: reject. The package fails the dependency-conflict test, the framework-fit test, and the maintainability test independently. Capture the requirement it was sourced against, confirm whether the need is extraction, workflow, or storage, and address that need with Laravel-native translation plus a purchased TMS and a purpose-built extractor. If a legacy Symfony 2 application still runs it, schedule a one-time catalog export and decommission.