Backend Translations Tool Bundle Laravel Package

Product Decisions This Supports

• Localization / i18n roadmap scoping. This package does not solve the problem, but it names the real product problem well: getting translated copy into production without an engineer, a branch, and a deploy. Any roadmap item framed as "launch locale #N without engineering involvement" or "cut copy-change cycle time" is the decision space it nominally addresses — and the decision it actually supports is build vs. buy, not install this.
• Requirements checklist for a first-party translation admin. Read the bundle's screens as a spec, not as a dependency. The feature set it demonstrates is a genuinely useful backlog seed: a grid keyed by (domain, bundle, locale, key), filter by locale/namespace, per-locale coverage and missing-key reports, inline edit with dirty-state tracking, bulk import/export of catalogs, and a clear-cache/publish step on save.
• Build vs. buy vs. borrow. This package is only ever borrow (mine it for UX ideas). It is emphatically not buy in a modern stack — the "free" dependency is a nine-year-old Symfony bundle with zero users, zero dependents, and a read-only mirror, which is the most expensive form of free.
• Framework-fit correction that changes the decision. Despite being surfaced in a Laravel/PHP package evaluation, this is a Symfony bundle with an MJR/ExtJS admin UI. It cannot be dropped into a Laravel app. That single fact removes it from consideration for any Laravel-based product decision and reclassifies this evaluation as "prior art reviewed, no-go."
• Tech-debt / deferred-decision register. Logs a deliberate gap — "translation editing is a known, unaddressed need" — so it is owned rather than rediscovered every two quarters.
• Cost-of-ownership signal for dependency policy. A useful concrete example when arguing for a written rule: no dependency without a maintainer, a release in the last 24 months, and at least one downstream consumer.

When to Consider This Package

Adopt (or rather, keep in place) only if all of the following hold:

• You own a legacy Symfony 2.x/3.x application already running the Modera/MJR admin stack, and this bundle is already installed and working.
• You are in read-only maintenance mode — preserving existing behavior, not adding capability.
• Your PHP runtime is pinned to the era (PHP 5.6 / early 7.x) with no near-term path to PHP 8.
• You have in-house engineers fluent in MJR conventions and ExtJS who accept permanent ownership of a local fork (last release 2016-06-17; 0 stars, 0 dependents; repository is a read-only split, so defects cannot be reported upstream).

Look elsewhere if any of these are true — which is the default case:

• You are on Laravel or any modern Symfony (5/6/7). There is no realistic compatibility path: no service provider, no Blade/Livewire/Vue views, no publishable config, no Eloquent models, and an ExtJS asset pipeline that does not exist in your app.
• You need maintained code — security patches, PHP 8.x support, active triage. An authenticated admin screen that writes to your translation catalog is an attack surface, and vendor abandonment means you will not even get an advisory when something breaks.
• Your editors need a modern, mobile-tolerant, easily themed UI. ExtJS-era tooling is hard to hire for and hostile to responsive admin experiences.
• You need TMS integration (Crowdin, Lokalise, Phrase), pluralization rules, translation memory, review/approval flows, or per-locale ownership. None of that is here.
• You have a modest catalog — under roughly 50 locales or a few thousand keys — where a thin CRUD screen over your translations source of truth is a one-to-two-sprint build and vastly more maintainable.
• Your translation catalog is file-based YAML/PHP. Editing files from a web UI needs careful write-back and cache invalidation; the 2016-era approach assumes Symfony's cache warmer and does not translate to Laravel's compiled cache at all.

Verdict: prior art only. Do not add as a dependency, do not plan a migration onto it, do not let it gate an in-house build.

How to Pitch It (Stakeholders)

To executives (one paragraph): Translation management is worth solving — it directly shortens time-to-market for new regions and takes engineering out of routine copy changes. The specific open-source package we evaluated is not the way to do it: it is an abandoned 2016 Symfony component with no users, no maintenance, and no compatibility with our Laravel stack. Adopting it would mean owning a permanent fork of code nobody else uses, in a UI technology we cannot hire for. I recommend we close this as no-go and treat it as reference material, then fund either a small internal admin screen over our translation files (one to two sprints) or a paid translation platform if locale count and external translators justify it. Either option costs less over three years than carrying an unmaintained authenticated write surface.

To engineering (three lines): Don't install it — it's Symfony 2/3 + MJR + ExtJS, PHP 5.6-era, last shipped June 2016, read-only mirror, zero dependents, a supply-chain and hiring liability. Skim the grid/edit/import/export screens for the required field set and workflow, then build a thin admin CRUD over our source of truth: a translations table via spatie/laravel-translation-loader, or a careful write-back layer over lang/ files with explicit cache-busting on save. If you explore at all, timebox a one-day container spike to confirm the dependency graph won't even resolve — treat failure as expected and run that spike in parallel with, not ahead of, the in-house build.

Recommended alternatives to evaluate in its place: a first-party admin screen over lang/ files or a translations table; spatie/laravel-translation-loader for DB-backed translations with file fallback and caching; or a hosted TMS (Crowdin / Lokalise / Phrase) once locales or external translators exceed what an internal screen should handle.

Ask: close this evaluation as "no-go — prior art only," and approve a scoping spike for the internal translation admin if localization is on the roadmap for the next two quarters.