Translation Editor Bundle Laravel Package

Product Decisions This Supports

• Localization strategy: in-repo files vs. external TMS. This bundle is a data point for the "keep translations in git, let developers fix copy inline" model. If we choose that model, tooling like this is what makes it tolerable; if we choose Crowdin/Lokalise/Phrase, this package becomes irrelevant. The decision is really "who owns translation edits: engineers in the repo, or a TMS with translators."
• Build vs. buy for internal DX tooling. As described, it adds an editor panel to the Symfony profiler so a missing or wrong string can be corrected while looking at the page, without hunting through YAML/XLIKE files. That is a small, cheap internal-tooling capability — useful as a benchmark when someone proposes we build our own admin translation UI.
• Translation-debt prioritization. Every locale we ship multiplies the manual cost of adding a key, fixing a typo, or chasing a missing-string bug. A profiler-level editor shortens that loop, so it informs whether we can afford to add locale #4–#8 this quarter without adding headcount or process.
• Who can touch copy. It enables non-engineers (PM, marketing, support) to fix strings in a dev environment without a code-editing workflow — a meaningful constraint on whether we promise "marketing can edit copy directly" in a roadmap.
• Scope of the i18n investment. If a one-composer-require, dev-only tool covers 80% of our friction, we can defer a TMS contract and the associated procurement/SSO/integration work to a later phase. That's a roadmap sequencing decision, not just a dev convenience.
• Not a production feature decision. It's a developer-environment tool with no production runtime surface; it should never appear in a customer-facing roadmap or a reliability commitment.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony (5/6/7-style) with the Symfony Profiler / web debug toolbar already enabled in dev. This is a Symfony bundle — it is not a Laravel package and is not drop-in for a Laravel app. For a Laravel codebase, the equivalent evaluation set is barryvdh/laravel-translation-manager or a TMS integration; do not put this on a Laravel roadmap.
• We have a modest locale count and translation files committed to the repo, and engineers are the primary editors.
• We want zero vendor cost, zero external service, zero lock-in (MIT), and a dev-only footprint.
• We are willing to treat it as an experiment rather than a platform dependency.

Look elsewhere when:

• Framework mismatch — Laravel, or any non-Symfony stack. This is disqualifying for our primary app if it's Laravel.
• Maturity risk is unacceptable. Still 8 stars, 0 dependents, and a single-maintainer profile, which remains a signal of low real-world validation. Note that v1.2.2 is a maintenance release (console-command fix, added PHPUnit tests, PHPStan cleanup) — the tests and static analysis are a genuine positive quality signal and make a "fork it ourselves" fallback cheaper, but they don't change the adoption footprint. Fine for a local dev convenience, not fine if a team comes to depend on it.
• Translators are non-technical at scale, or we need roles/permissions, review-and-approve, translation memory, machine translation, or per-string audit history. Those are TMS requirements; a profiler panel cannot carry them.
• We need edits outside a developer's local machine. A profiler-based editor is inherently dev-environment and request-scoped; staging edits by non-engineers, CI validation of missing keys, and translation:extract-style linting are separate concerns this does not replace.
• We need vendor support or an SLA. MIT with a tiny community means fork-it-yourself is the escalation path.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed developer convenience for Symfony apps that lets engineers fix and add translations directly from the debug toolbar instead of editing files by hand. No license cost, no vendor contract, no production footprint, no data leaving the machine. It is a candidate to defer a paid translation-management platform by one or two quarters. Two caveats up front: it is Symfony-only, so it does not apply to our Laravel services, and it is a very small project (single-digit stars, no downstream dependents). The latest release is maintenance-only — a console-command fix plus added PHPUnit tests and PHPStan checks — which is encouraging housekeeping but not a functional change, so I still recommend a time-boxed trial on one team, not a standard.

To engineering: One dev dependency, auto-wired via the bundle, active only where the profiler is active. It shortens the edit-verify loop for translation work and keeps strings in version control. v1.2.2's addition of PHPUnit coverage and PHPStan analysis makes the codebase more comfortable to audit and fork if needed, but the project is still small and MIT, so isolate it behind a dev-only require and be prepared to fork or drop it; budget half a day for the spike and a clear abandon criterion (e.g., "if it doesn't save us measurable time in two sprints, remove it").