Translation Bundle Laravel Package

Technical Evaluation

Architecture fit — still poor, unchanged by this release. kilik/translation-bundle remains a Symfony bundle. Version 1.0.0 adds a Symfony version floor; it does not add a Laravel service provider, does not register Artisan commands, and does not expose the diff logic as a framework-agnostic library. The evaluation from the previous cycle stands: the useful part is a few hundred lines of key-diffing and stub-generation, wrapped in Symfony bundle registration, DI extension classes, and Console command plumbing that our application never instantiates. The new release does not move that boundary by even one line.

Integration feasibility — low, and arguably narrower than before. The release note is short but its implication is material: symfony 5.4 compatibility added combined with not compatible with symfony < 5 reads as a ^5.4 constraint, not ^5.4 || ^6. That matters because modern Laravel requires Symfony 6 components — Laravel 9 and 10 pin symfony/console, symfony/http-kernel, symfony/routing, symfony/process and others to ^6.0. A bundle that caps at Symfony 5.4 cannot co-resolve with those. So the release that looks like a compatibility improvement is, for our likely stack, a compatibility regression: it aligns with Laravel 8 (Symfony 5.4) and actively conflicts with Laravel 9+. Even if it resolves, symfony/framework-bundle is still outside Laravel's Symfony subset and nothing would register the bundle. The forking path is unchanged.

Technical risk — high, and the abandonment signal is unmoved. The 1.0.0 tag is a semver statement, not an activity signal: single maintainer, no dependents, no issue traffic to evidence production use. Tagging 1.0.0 after a period of silence usually means the maintainer cut a release for their own needs, not that a support commitment was made. Two new risks specific to this release: (a) the major-version bump carries a breaking constraint change we would have to track if we forked, and (b) the release note is the entire changelog — no migration notes, no test evidence for the Symfony 5.4 path, no indication of what else changed between the prior tag and 1.0.0. We cannot tell whether Symfony 5.4 support was tested or merely declared. Runtime attack surface remains small (developer-machine file I/O against lang/), so this stays a maintenance risk rather than a security blocker.

Key questions for the spike (revised):

• What is the exact symfony/* constraint string in composer.json? ^5.4 versus ^5.4 || ^6.0 is the single fastest kill test for our stack.
• Does the import/export logic handle PHP array and JSON lang files, or only Symfony's XLIFF/YAML? Unchanged question, still decisive.
• Is the key-diffing code separable from the Console command, or entangled with ContainerInterface and bundle config?
• What changed between the previous tag and 1.0.0 beyond the constraint? Diff the tags; the release note does not tell us.
• Are there tests covering round-trip behaviour (read → write → re-read) on partially translated locales, and do they exercise the Symfony 5.4 path?
• License and attribution obligations if we fork.

Integration Approach

Stack fit — none out of the box, and the target narrowed. Laravel's translation layer is lang/{locale}/*.php, lang/{locale}.json, __(), the translator binding, and pluralization rules. This package is still not aware of any of it. The 1.0.0 constraint change does not create a bridge; it removes the possibility of installing the bundle cleanly on Laravel 9/10.

Migration path — still no incremental adoption. Developer-workflow tool, not a runtime dependency. There is nothing to phase in. The experiment remains cheap (one engineer, one branch, one spike) and the payoff remains nil beyond a reference implementation.

Compatibility — the deciding factor, now with a faster answer. Two independent blockers persist: no bundle registration in Laravel, and a dependency graph that now additionally caps Symfony at 5.4. For a Laravel 9/10 codebase that is a hard composer require failure, discoverable in minutes rather than days. If we are on Laravel 8, resolution may succeed and the framework blocker alone decides it.

Recommended sequencing:

1. Hour 1, constraint check. Read composer.json on the 1.0.0 tag. If the Symfony constraint excludes ^6, close the evaluation for any Laravel 9+ target and record the result. No spike required.
2. Day 1–2, spike (Laravel 8 only, or if constraints permit). Attempt composer require on a throwaway branch; record resolution outcome. Read the command source to judge extractability. Success criterion is a clear yes/no on whether the diff logic is reusable, not whether the package runs.
3. Day 3, decision gate. Clean logic plus format compatibility → fork and reimplement as a single Artisan command, pinning to the 1.0.0 tag as the reference. Either condition fails — the likely outcome — stop.
4. Fallback path. Write a purpose-built translations:missing Artisan command: enumerate locales, load via Laravel's FileLoader, compute key deltas, emit stubs. Native format handling, native pluralization awareness, no third-party support burden, no Symfony version coupling.
5. If the goal is broader translation management (editing UI, DB-backed strings, TMS sync), evaluate Laravel-native options such as barryvdh/laravel-translation-manager or spatie/laravel-translation-loader.

Operational Impact

Maintenance — we would own it on day one, and now with a version floor to track. A 1.0.0 tag does not create an upstream support obligation. One maintainer, no dependents, no visible issue history. Any fork becomes an internal, unowned dependency unless explicitly assigned. The 1.0.0 breaking constraint change is exactly the kind of upstream event a fork owner must notice and chase manually.

Support — still no community to lean on. No Stack Overflow corpus, no peer validation, no issue archaeology. Every problem is a first-principles problem. A major-version tag does not change this; participation does, and there is none.

Scaling — not a runtime concern; unchanged. The tool never executes in production. The scaling question is translation volume and contributor count: does it behave predictably when ten engineers add keys across twenty locales concurrently? Any non-atomic write behaviour produces lang/ merge conflicts that erase the time saved. Verify write atomicity and deterministic key ordering before trusting it in CI.

Failure modes to watch:

• Silent key loss on round-trip. Highest severity: a developer believes translations are synced while keys are dropped or reordered. Test round-trip fidelity hardest.
• Format coercion. XLIFF/YAML-only output would produce files Laravel's loader ignores — translations appear to exist and silently fall back to the source string.
• Constraint-driven install failure mistaken for a code problem. On Laravel 9+, composer require fails on Symfony 6 vs ^5.4. Do not spend spike time debugging a code incompatibility when the real answer is "wrong major version, permanently."
• Dependency drift. A forked copy of Symfony-coupled code rots against our Symfony upgrades on every Laravel major — and the 1.0.0 constraint bump is the first instance of that drift, arriving before adoption.
• CI false green. The tool running against a stale branch and reporting "no missing keys."

Ramp-up — trivial technically, disproportionate conceptually. Any Laravel engineer can read the command source in an hour. The real cost is teaching the team a Symfony-shaped tool for a Laravel-shaped problem, then explaining why the repo carries a vendored fork of an abandoned bundle pinned to Symfony 5.4.

Recommendation: do not adopt — unchanged. The 1.0.0 release adds Symfony 5.4 support and drops Symfony <5. It does not add Laravel integration, does not add maintainer activity, does not add dependents, and for a Laravel 9/10 codebase it narrows compatibility rather than widening it. Spend one hour confirming the Symfony constraint string, then build the translations:missing Artisan command in-house and skip the fork entirely.