Translation Bundle Laravel Package

Product Decisions This Supports

• Localization go/no-go gating. The core workflow — enumerate missing translation keys across locales and export them for handoff — is exactly the data you need to answer "is this locale actually shippable?" A missing-key report per locale turns i18n from a vibe into a release criterion.
• Build vs. buy on translation management. This package represents the low end of the spectrum: an in-repo CLI that exports missing strings to a file and reimports the translated result. Comparing it against a TMS (Crowdin, Phrase, Lokalise) gives you a concrete cost/benefit line: if your translation volume fits in "export a file, email it to a translator, import it back," you don't need TMS spend yet.
• Translator/vendor scoping. Export format decisions (XLIFF vs. CSV) determine whether you can use an LSP, a freelancer, or machine translation. This tool forces that decision early, which is usually the right time.
• Roadmap de-prioritization evidence. The 1.0.0 release is a genuine signal of life — the maintainer is still tagging versions and the project has reached a semver-stable 1.0 — but the direction of that release matters more than the fact of it: Symfony 5.4 is the ceiling, and support for Symfony < 5 was dropped. That is a project converging on a legacy LTS, not tracking modern Symfony (6.4/7.x). Treat this as a reference implementation for a workflow, not a dependency to adopt. The PM decision it supports is still "extract the pattern, skip the package."
• Important caveat: despite the "Laravel/PHP package" framing, this is a Symfony bundle — no Laravel service provider, no config publishing, no Laravel conventions. A Symfony 5.4 compatibility bump does not move this needle at all. Any Laravel-side decision here is a "no," not a "maybe."

When to Consider This Package

Consider the workflow (not necessarily the code) when:

• You run a small Symfony app on 5.4 with 2–3 locales and no TMS budget, and someone is manually grepping templates for trans() keys right now.
• You need a one-off export of missing strings for a translator, then an import of the result.
• You want an audit trail of translation coverage before committing to a new market.

Look elsewhere when:

• You're on Laravel. Different framework entirely, and the 1.0.0 release does nothing for this. Use Laravel's lang/ publishing, laravel-lang for locale packs, or a TMS SDK.
• You're on Symfony 6.4 or 7.x. 1.0.0 added Symfony 5.4 compatibility and explicitly dropped Symfony < 5 — it says nothing about 6.x/7.x. Verify before assuming this runs on a current Symfony app; the package's stated compatibility ceiling is a concern for any app on a supported Symfony LTS.
• Symfony already covers you. translation:extract and debug:translation ship in the framework and handle key extraction and missing-key reporting. Wrapping those is lower risk than adding a single-maintainer bundle.
• You need real i18n operations: ICU/pluralization correctness, per-key review state, translator comments, context screenshots, CI integration, >3 locales, or multiple concurrent translators. That's TMS territory.
• You need a support contract or security posture. One release does not create an ecosystem. Re-check dependent and download counts before treating adoption risk as resolved — one commit does not change the bus-factor math.

How to Pitch It (Stakeholders)

To executives: "There's a free Symfony tool that finds untranslated strings and exports them so a translator can fill them in. It just hit version 1.0, which is a good sign the maintainer is still active, but the release only modernizes it to Symfony 5.4 — a legacy version — and it isn't built for our Laravel stack. So the dependency is still off the table. What I do recommend is adopting the idea: an automated missing-translations report that runs in CI and blocks a release if a target locale is incomplete. That's roughly a day of engineering and gives us a defensible answer to 'can we launch in this market?'"

To engineering: "1.0.0 is a maintenance signal, not a capability signal: Symfony 5.4 support added, Symfony < 5 dropped — a breaking change, but one that confirms the compatibility ceiling is an older LTS rather than 6.4/7.x. Nothing here addresses Laravel. Don't add the dependency. Take the pattern: wrap Symfony's built-in translation:extract / debug:translation in a CI job that fails on missing keys and emits an XLIFF artifact for translators. If we ever need the import/export round-trip, vendor or fork the relevant command rather than depending on a single-maintainer bundle. Revisit a real TMS only when we exceed ~3 locales or need per-key review state."

Bottom line: 1.0.0 is a mild positive for project health and a negligible positive for us — the framework mismatch and the compatibility ceiling still dominate. Score it as a workflow reference, not a procurement.