Translation Bundle Laravel Package

Product Decisions This Supports

This bundle is best understood as evidence about a problem space, not a component to ship. It informs these decisions:

• Localization / market-expansion roadmap. Whether to localize catalog, checkout, emails, and admin — and in what order. An i18n bundle exposes the seams: which entities are translatable, where fallbacks happen, how much of the storefront is copy-driven vs. code-driven.
• Build vs. buy vs. borrow for translation management. The real decision is rarely "which bundle" — it's in-app admin editing vs. file-based catalogs vs. an external TMS (Crowdin, Phrase, Lokalise). Reading this bundle's approach to storing and loading per-locale entity data clarifies what you'd be signing up to maintain if you built it yourself.
• Who owns translation content. A translation layer implies a workflow: do merchandisers edit copy in the admin, or do developers ship YAML? That's a staffing and tooling decision with recurring cost, not a one-time engineering task.
• Data-model and search implications. Per-locale rows, JSON columns, and fallback chains change how search indexing, reporting, and exports behave. Product-visible: does a missing German translation silently fall back to English or render blank?
• SEO and compliance scope. Localized slugs, hreflang, and locale-complete legal pages are launch gates in many EU markets. This determines whether i18n is a "platform capability" epic or a per-feature tax.
• Packaging/pricing for locale support. Which locales are included in which tier, and whether translation is a paid add-on.
• Acceptance criteria for a vendor or OSS evaluation. The bundle is a useful checklist source: fallback strategy, per-locale validation, admin bulk-edit, import/export formats.

The score split is the headline: opportunity 7.38 vs. overall 0.19. That is the signature of a high-value problem with a low-value artifact. Do not let the opportunity score be read as an adoption signal.

When to Consider This Package

As a runtime dependency: effectively never. The disqualifying facts are structural, not stylistic:

• Archived / read-only. No security patches, no CVE response, no compatibility work for current PHP or Symfony LTS releases. It will fail any dependency policy, SBOM review, or vendor questionnaire your security team runs.
• 6 stars, 0 dependents. No community to answer questions, no downstream projects proving the upgrade path, no signal that anyone has run this against a modern stack.
• Fork liability. Adopting means owning a fork permanently, including every future PHP/Symfony bump, for functionality that is largely table stakes.

Legitimate uses:

1. Architecture reference. When writing an ADR/RFC for your translation layer, read it to see how Sylius modeled translatable resources before that capability consolidated into the platform core. Extract patterns, not code.
2. Legacy archaeology. If you inherit a Sylius application already pinned to a version where this appears as a transitive dependency, treat it as a removal backlog item, not a feature to build on.
3. Evaluation checklist. Turn its scope into questions for the alternatives below.

Look elsewhere when: you are greenfield; you need supported PHP/Symfony versions; you need TMS integration, an admin editing UI, or locale-scoped search; you need a maintainer who will respond.

Alternatives to evaluate instead (verify current maturity before committing): translation/translatable support in Sylius core itself; Symfony Translation plus Doctrine Extensions (Gedmo) Translatable or KnpLabs/DoctrineBehaviors; or a dedicated TMS for the content workflow layer. For catalog-heavy localization, a PIM with native multi-locale support may beat a custom in-app solution outright.

Re-adoption triggers to watch: repository unarchived, a named maintainer with release cadence, dependents > 0, CI green on current PHP/Symfony.

How to Pitch It (Stakeholders)

For executives (one paragraph): "We evaluated sylius/translation-bundle for our localization work. Recommendation: do not adopt. It is archived and read-only, with 6 GitHub stars and zero dependent projects — meaning no security patching, no compatibility with current PHP/Symfony, and no community support. The high opportunity score you may see reflects the value of localization as a problem, not the quality of this code. Adopting it would mean owning a permanent internal fork. Localization is still a real priority; we should fund it via supported platform features or a translation-management vendor, and we should size it as a multi-quarter capability with an ongoing content-ops cost — not a one-off library install."

For engineering (summary):

• Treat as a reference implementation only. Do not add it to composer.json. If it is already present transitively, open a removal ticket with a target date.
• Timebox a 1–2 day spike to mine it for design input: how translatable resources are registered, fallback resolution order, admin vs. file-based editing, and import/export formats. Capture findings in an ADR.
• Use those findings to write acceptance criteria for the real solution: locale fallback behavior, per-locale validation, bulk-edit UX, and search-index locale handling.
• Guardrail to state explicitly in the ADR: no archived dependencies in the localization path, because i18n touches customer-facing copy and legal pages — the blast radius of an unpatched dependency there is disproportionate.

Framing that lands with both audiences: the deliverable from this evaluation is a decision document and a criteria set, not a dependency. That is a good outcome — we avoided a fork and still de-risked the roadmap.