Translations Bundle Laravel Package

Product Decisions This Supports

• Where the source of truth for copy lives. The package's core loop — extract translation tokens from source files → dump to a database → let translators work → compile back to physical files — is a concrete answer to "are translations code or content?" It supports keeping files as the deploy artifact while making the database the working surface: the pragmatic middle ground most teams land on.
• Build vs. buy for localization tooling. Evaluating this bundle forces the right conversation, because the extract/import/export pipeline it implements is exactly the integration surface a TMS (Crowdin, Lokalise, Phrase, Weblate, translation.io) sells. Seeing the whole pipeline implemented in a small PHP codebase is a useful sanity check on whether a vendor contract is justified or whether an in-house admin screen plus a CI job covers 80% of the need.
• Copy hotfix capability on the roadmap. A database-backed translation layer enables shipping a wording, legal, or compliance fix without a deploy. That's a recurring ask from marketing and legal, and the pattern here (DB value wins over file value, files remain the fallback) is the standard way to deliver it.
• Cost of adding a locale. Once extraction is automated, the marginal engineering cost of locale N+1 collapses to "translator time + QA," turning localization from an engineering project into an operational line item. That changes how you forecast and sequence market expansion.
• Fits: legacy Symfony/PHP applications with thousands of hardcoded strings and no existing translation workflow; internal tooling where a non-engineer translator needs a UI rather than a Git checkout; teams migrating off hand-edited YAML/XLIFF files.
• Does not fit: greenfield products, anything with heavy ICU/pluralization/context requirements, or anything needing vendor-managed translation memory and review workflows.
• A decision it should force, not defer: this is a Symfony bundle, not a Laravel package. If our stack decision is "Laravel," this artifact informs the design but is not an adoptable dependency. The PM takeaway is to separate "pattern we want" from "package we install," and to record that as an explicit scope boundary rather than letting engineering quietly attempt an integration.

When to Consider This Package

Consider it (as a reference design, not a dependency) when:

• Your stack is Symfony, not Laravel. This is a Symfony bundle registered through a Bundle class and DI container config — no service provider, no facade, no config/ publish step. Adapting it to Laravel is a rewrite, not an install.
• You already hold a large corpus of translations in files and want an admin surface on top without replacing the file-based deploy path.
• You have in-house PHP capacity and are comfortable owning a hard fork: the repo is read-only, last released 2016-06-10, one star, zero dependents — no maintainer response path, no security patch cadence, no modern-framework or PHP 8 compatibility guarantee.
• You want to read the extraction implementation before commissioning your own. This is the highest-value use of the package today, and it's a one-afternoon exercise a senior engineer can turn into a build estimate.

Look elsewhere when:

• You're on Laravel. Use lang/ files plus a PHP/JSON translation loader; if you need a DB override layer, a small custom resolver is a far smaller commitment than porting a decade-old Symfony bundle. Laravel's loader also won't read the Symfony-format resources this tool dumps, so strings can silently fail to render.
• You need active maintenance, security review, or a support contract. Zero dependents plus an eight-year-old release is a hard stop for anything customer-facing.
• You need pluralization, ICU MessageFormat, gender/context variants, or per-key translator comments. Modern TMS platforms and symfony/translation's own tooling handle these; a 2016 extractor will not.
• Your volume is small enough that a spreadsheet plus a CI check for missing keys suffices — below roughly a few hundred keys the pipeline is more overhead than it saves.
• You want vendor-managed translation memory, reviewer workflows, or per-locale invoicing. That's a buy.

How to Pitch It (Stakeholders)

For executives: This is a 2016 Symfony bundle with one star, zero dependents, and no maintainer — so we should not take a dependency on it, and it isn't even a Laravel package. What it does give us is a cheap, well-understood architecture for localization: pull strings out of code automatically, let translators work in a database-backed admin UI, and compile back to files at deploy time. Adopting that pattern — not the package — would let us add a language without an engineering project and ship copy fixes without a release. The recommendation is to scope it as a contained internal build (roughly one to two sprints) or fold it into a TMS evaluation, and explicitly not adopt the bundle. Opportunity here is real; the vehicle is not.

For engineering: The valuable artifact is the extract → persist → translate → dump-back loop, and it should be treated as a spec rather than a dependency. The repo is read-only, unmaintained since 2016, has no dependents, and produces Symfony-format resources that Laravel's FileLoader will ignore — so any integration is bespoke and permanent. If we build the pattern natively, the pieces are contained: an translations:extract command that walks views, app code, and routes for __(), @lang, and trans_choice; a translations table with a "DB value overrides file value" resolution order; an admin CRUD surface (Filament/Nova); a deterministic translations:dump back to lang/{locale}/{group}.php and lang/{locale}.json; and a CI gate that fails the build on missing keys or un-dumped DB state so the two never drift. Make the dump a single-owner job on main to keep diffs reviewable. Budget one sprint for a locale/key inventory first — retrofitting extraction rules across an unknown key surface is the most common way these projects overrun.