Jms Translation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow on localization tooling. The package's differentiated value is extraction: it statically scans Twig templates, PHP, Symfony forms (including choice/entity labels, repeated sub-fields, and — as of 1.6 — form constraints and invalid_message options) and builds a catalogue of every translation key in the codebase. That is genuinely expensive to build in-house and brittle to maintain. The bundled WebUI for editing translations is the part you would more plausibly build or buy elsewhere.
• Localization strategy / TMS gap analysis. This bundle is an extraction + editorial layer, not a translation management system. It supports the decision "do we need a TMS yet?" — if your needs are string inventory, XLIFF/YAML handoff to a translation agency, and a lightweight internal editing screen, this covers it. If you need review workflows, per-locale roles, translation memory, MT, or vendor portals, it does not, and that's a buy decision.
• Translation debt audits before a release or market entry. Running translation:extract against a bundle and diffing the output against committed catalogues gives a concrete "N keys missing for locale X" number — useful input for scope/schedule decisions on a localization push. The --bundle scoping, --domain filtering, --keep-old/keep-empty-strings options, and the "don't overwrite existing translations" behaviour map directly onto a CI gate or a one-off audit.
• Format standardization (ICU). Version 1.6 added dumping to ICU message format. That's a roadmap-relevant fork in the road: ICU changes how plurals/gender/select are authored and has downstream implications for translators, tooling, and any runtime formatting library. Decide deliberately, not by default.
• Platform/vendor risk decisions. This is an Ibexa fork of schmittjoh/JMSTranslationBundle. Zero stars and zero dependents on the fork means community signal lives upstream, not here. The decision this informs is "how much do we invest in a vendor-maintained utility we don't control," which is a maintain-vs-replace call, not a feature call.
• Architecture fit. The package is a Symfony bundle (service container, DI, commands, Twig) targeting the Symfony 2→5 / Twig 3 era with PHP 8 support added in 1.6. For a Laravel codebase this is not a drop-in: you would be reimplementing the extractors. That's a meaningful "don't adopt" signal for a large share of PHP product teams.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony (or Ibexa/eZ Platform) and are comfortable with bundles, DI configuration, and console commands.
• You have a real key-extraction problem: translation strings scattered across Twig, PHP, and form definitions, with recurring "we shipped a screen with untranslated labels" incidents or manual key audits.
• You want XLIFF (or YAML) as the handoff artifact to translators/agencies, and the XLIFF round-trip matters (the changelog shows meaningful work here: CDATA support, stable SHA1-based ids to avoid merge conflicts, preserving translation state across extract/update cycles).
• You need form-level extraction specifically — constraint messages, translation_domain options, choice/entity labels. This is the hardest part to replicate and the strongest reason to borrow rather than build.
• You are willing to pin and vendor a fork, and accept that you may need to carry patches yourself. Treat it as internal tooling with a named owner, not as a strategic dependency.
• You'd like an optional internal editing UI for PMs/translators rather than a full TMS seat cost at low locale volume.

Look elsewhere when:

• You are on Laravel (or any non-Symfony framework). The bundle is container- and Twig-coupled; you would get the extraction ideas, not reusable code. Use framework-native lang files plus a key-scanning script or an existing static-analysis tool.
• You need current-framework support you can rely on. Verify the composer constraints against your Symfony/PHP versions before anything else; the changelog's most recent framework work tops out around Symfony 5 / Twig 3 / PHP 8. Do not assume Symfony 6/7 readiness.
• You need a supported, SLA-backed dependency. Zero dependents and a fork-only presence means no ecosystem pressure to fix your bug. If you require vendor support, a maintained TMS integration is the answer.
• You need translation management — review states, translator accounts, MT, TM, analytics. This is the wrong category of tool.
• You need the WebUI to be a primary product surface. The issue history is dominated by WebUI configuration and update failures; the CLI extraction path is the mature part. If the editing UI is load-bearing for your ops team, budget for it or buy.
• You need runtime translation behaviour — this package does not do that; Symfony's Translation component does. Don't let the "on steroids" tagline create that misunderstanding in scoping.

How to Pitch It (Stakeholders)

One-liner: A developer-and-ops tool that finds every translatable string in a Symfony codebase and produces translator-ready files — it does not translate anything at runtime, and it is not a translation management platform.

For executives (cost/risk framing):

• The value is avoided engineering and avoided rework, not new user-facing capability. It automates the two chores that reliably eat time on every localization push: finding strings that were never extracted, and regenerating catalogue files without clobbering existing translations.
• The cost is maintenance exposure. This is a vendor fork with no visible independent adoption. Recommend it as internal tooling with a pinned version and an owner, and explicitly not as a platform commitment. A cheap exit plan (it produces standard XLIFF, which is portable) keeps the downside small.
• Decision requested: fund a time-boxed spike (2–3 days) rather than a program. Success criteria: extraction runs clean against one representative bundle, produces a defensible missing-key count, and round-trips through XLIFF without losing existing translations.

For engineering:

• What you get: a scriptable translation:extract command that parses Twig/PHP/forms, respects translation_domain and @Ignore annotations, supports domain and bundle scoping, and dumps to XLIFF/YAML/ICU with stable ids for clean diffs. That's a non-trivial static analysis problem — it's the reason to consider borrowing instead of building.
• What you don't get: runtime translation, review workflows, and a WebUI you should trust as a production surface. Assume the CLI path is the product.
• Integration reality: native cost on Symfony, near-zero reuse on Laravel. Verify framework and PHP constraints against our stack on day one of the spike; that's the most likely reason to stop.
• Ask: adopt behind a pinned composer constraint, wire extraction into CI as a report-only check first (missing-key count, no failure), and promote it to a failing gate only after we've seen the false-positive rate on our own templates and forms.