Translations Bundle Laravel Package

Technical Evaluation

Architecture fit — poor

• The brief says "Laravel/PHP package," but this is a Symfony bundle: the *Bundle suffix and Modera\TranslationsBundle namespace mean it registers through bundles.php / the Symfony DI container. It will not auto-discover in Laravel, ships no service provider, no facade, and no publishable config.
• Even discounting the framework mismatch, its role is a workflow tool, not a runtime library. It does not provide a translation resolver, so it does not replace Laravel's __() / trans(), and it does not plug into Laravel's FileLoader chain.
• Where it would land in Laravel — lang/{locale}/*.php plus lang/{locale}.json — is not where this bundle writes. It emits Symfony-format resources (XLIFF/YAML under Resources/translations/), which Laravel silently ignores.

Integration feasibility — low

• The persistence layer is Doctrine-oriented, and Laravel ships Eloquent with no Doctrine dependency. Pulling Doctrine in solely to run a translation CLI is a large, unjustified dependency surface.
• Extraction targets Symfony conventions (trans, transChoice, Twig filters). Laravel's surface is @lang, {{ __('...') }}, and trans_choice, so the extractor will not match our templates.
• The [READ-ONLY] prefix marks a subtree split of a larger Modera monorepo — no issues, no PRs, no CI live here. Any fix we need is a permanent fork.

Technical risk — high

• Abandonment is the headline. Last release 2016-06-10, 1 star, 0 dependents, package score 0.035. There is no security patch cadence, no PHP 8 guarantee, and no evidence of Symfony 4+ compatibility — a 2016 bundle likely predates the modern directory restructure and will not boot on a current kernel.
• Bus factor of one, upstream, with no commercial support path.
• Zero community signal — no Stack Overflow corpus, no tutorials, no third-party integrations. Every issue becomes a source-reading exercise on a decade-old codebase.
• The opportunity score of 25.49 confirms the problem is real; the package is just not the vehicle for solving it.

Key questions

1. Is the actual requirement "translate our UI strings" (a localization/vendor problem) or "keep a database as the source of truth for translations" (a bespoke pipeline problem)? Different answers, different solutions.
2. Do we already have, or intend to buy, a TMS (Crowdin, Lokalise, Phrase, Weblate, translation.io)? If yes, this bundle is redundant.
3. What is our current lang/ footprint — key count, file count, locale count, JSON vs. PHP arrays?
4. Who owns translation content — engineers or a non-technical translator? The DB-backed model only pays off if non-engineers edit strings.
5. What Laravel/PHP versions must we support? If the answer is Laravel 10/11 on PHP 8.2, this package is out before we start.

Integration Approach

Stack fit — none as-is

• There is no supported path to install this in a Laravel app. Do not shim the Symfony kernel or register the bundle alongside Laravel's container; the coupling is permanent and unmaintainable.
• Recommendation: do not adopt the code. Adopt the pattern. The extract → persist → translate → dump-back loop is the genuinely valuable artifact here.

Migration path

• If we already have legacy Symfony/Modera output, write a one-time converter (Symfony XLIFF/YAML → Laravel PHP arrays) rather than keeping the bundle in the loop. Keep the old files on a branch until the new pipeline is green.
• If we are greenfield-on-Laravel (likely), there is nothing to migrate from — we are building a small internal capability, not porting this package.
• Any fork of the bundle is a hard fork with no upstream merge path; budget for permanent ownership before choosing it.

Compatibility and build shape (if we build natively)

1. translations:extract — scan resources/views, app, routes for __(), @lang, trans_choice; emit a key manifest.
2. translations:sync — diff the manifest against a translations table (locale, group, key, value, status); flag missing and orphaned keys.
3. Translation surface — a Filament/Nova CRUD or minimal admin screen over that table.
4. translations:dump — write back to lang/{locale}/{group}.php and lang/{locale}.json, deterministically sorted to keep diffs reviewable.
5. CI gate — fail the build on missing keys or on undumped DB state, so the DB and files never drift.

Sequencing

1. Discovery (1 sprint). Inventory lang/ files, key duplication, orphans, and locale coverage. Confirm whether the real pain is extraction, translation handoff, or file/DB drift.
2. Build vs. buy decision. If translators are external or volume is >~2k keys, buy — Crowdin/Lokalise/Phrase all have Laravel-native CLI and CI integrations. If the constraint is a self-hosted DB source of truth, build the small Artisan command set.
3. Build and gate in CI before any translator touches it.

• Do not start the pipeline before the locale/key inventory is done; retrofitting extraction rules across an unknown key surface is the classic way these projects overrun.

Operational Impact

Maintenance

• Adopting upstream: effectively zero available maintenance from the maintainer — no releases since 2016, no dependency updates, no CVE response. We own it 100% from day one.
• Building internally: roughly 1–2 sprints of initial engineering, then low steady state. The only volatile piece is the extraction rules, and those change only when we change templating conventions. On a 12-month horizon, building is the cheaper option.

Support

• No vendor, no SLA, no community. Debugging is source archaeology on a 2016 Symfony codebase, and internal Slack will not help.
• Translator-facing support is a real cost either way — whoever owns the DB becomes the help desk for "why didn't my string show up."

Scaling

• The DB-as-source-of-truth model scales fine to tens of thousands of keys.
• The bottleneck is the dump-to-files step: it produces noisy diffs and merge conflicts if multiple branches regenerate concurrently. Mitigate by making the dump a single-owner CI job on main, never a developer-local command.
• Extraction cost is linear in source files; irrelevant at our size.

Failure modes

• Silent drift — DB and files diverge, translators edit a stale surface, strings ship untranslated. Highest-probability failure; the CI gate is the mitigation.
• Key collisions — auto-derived keys from source text shift when copy changes, orphaning translations. Prefer explicit, stable keys.
• Loader mismatch — dumping Symfony-format resources that Laravel silently ignores, producing "translations exist but nothing renders." Caught only by a smoke test asserting a known key resolves per locale.
• Runtime breakage from a dependency bump — a risk only if we adopt the bundle directly; eliminated by building native.
• Bus factor — for any fork, a single internal owner with no documentation.

Ramp-up

• For a new engineer, the bundle demands Symfony 2/3-era familiarity plus Doctrine — days, not hours, and the knowledge is not transferable to the rest of our stack.
• A native Laravel pipeline uses only existing team skills — hours. This asymmetry is, on its own, the strongest argument for treating modera/translations-bundle as a reference design, not a dependency.