Ui Translations Laravel Package

Product Decisions This Supports

• Market expansion sequencing. Back-office localization is a hard prerequisite for operating in non-English markets (DACH, LATAM, SEA, CEE). This package determines which admin locales we can ship without commissioning a translation layer, so it gates the answer to "which market can support, CS, and merchandising teams actually operate in next quarter."
• Build vs. buy for admin i18n — with the stack caveat resolved first. The honest "buy" option only exists inside the Sylius/Symfony ecosystem. If our codebase is Laravel, the decision collapses to "build a thin admin CRUD over message catalogs ourselves, using this as a design reference" — a 1–2 sprint task, not a dependency adoption. The PM's first job is to settle which of these two worlds we are in before committing any roadmap slot.
• Platform evaluation of Sylius as a candidate. When comparing Sylius against Shopify Plus, Adobe Commerce, or a headless build, back-office localization coverage per locale is a concrete, scoreable row in the comparison matrix. This package is the evidence artifact for that row — but only within Sylius; it tells us nothing about any other platform.
• Launch readiness gates. Translation coverage of admin strings becomes a go/no-go checklist item per locale: "order, catalog, and promotion admin flows fully translated; terminology glossary signed off by local ops." That converts a vague "is it localized?" question into a measurable release criterion with an owner.
• Support and onboarding cost model. Native-language admin reduces training time and error rates for local ops, CS, and merchandising staff. That is a defensible labor-cost line in the expansion business case — and it is the number that justifies the spending, not the package itself.
• Contribution vs. fork vs. override strategy. This is a read-only subtree slice, not an independently maintained product. "We'll just send a PR here" is not a valid plan. The decision is: override translations in our own app, contribute upstream to the Sylius monorepo, or maintain a private fork. Each carries a different long-term ownership cost, and the PM must pick one explicitly.
• Roadmap positioning — and honest scoping of what it is. Note the two credible readings of this artifact: it is either (a) a shipped corpus of ready-made UI translations, or (b) an admin plugin for browsing and editing translation strings. Those are different features with different risks (a corpus vs. a write path into production strings). Confirm which one we are actually adopting before it appears on a roadmap as a single line item.
• Ownership assignment. It clarifies whether localization is a Q3 engineering epic, a vendor/agency deliverable, or a content-ops runbook task — three very different budget owners and three different success metrics.

When to Consider This Package

Consider it when:

• You are already on Sylius (or actively evaluating it as a platform). The value is inseparable from the platform; it is not independently adoptable, and there is no meaningful use for it in Laravel or framework-agnostic PHP beyond borrowing patterns.
• You need admin/back-office strings — labels, form fields, validation messages, grid headers, menus — not storefront customer-facing copy. Storefront copy is a separate concern with a separate owner.
• Your localization need is broad and generic (orders, catalog, promotions, customers) and coverage exists for your target locale. In that case you inherit a large string corpus for free under MIT.
• You want a zero-cost, zero-vendor-lock starting point before investing in a commercial translation management system.
• You can consume it through the platform (i.e., via sylius/sylius) rather than as a direct Composer dependency, and can follow Sylius's release cadence.

Look elsewhere / proceed with caution when:

• You are not on Sylius. Do not evaluate this as a standalone i18n library. Reject, or treat as reference only.
• You read the repository's own signals literally. Zero stars, zero dependents, and a read-only flag mean no independent adoption, no downstream validation, and no issue tracker of its own. Treat it as a published slice of a larger monorepo, not a supported product. If procurement requires evidence of community usage, this artifact will not satisfy it — evaluate Sylius's overall adoption instead.
• You need translation workflow — review queues, translator assignment, screenshot context, in-context editing, per-string status. That is a TMS (Crowdin, Lokalise, Phrase, Weblate) and a separate line item. Scope it before, not after, a multi-market commitment.
• You need locales not covered, or must guarantee terminology. You will maintain overrides in your own app and re-audit them on every Sylius upgrade. Budget that explicitly — assume a fraction of an engineer per quarter.
• You need RTL correctness, pluralization edge cases, or locale-specific formatting beyond Symfony's Intl integration. Verify per locale before committing a launch date.
• You are adopting the editing-UI reading of this package. That version exposes a write path into production translation strings — a stored-XSS and privilege-escalation surface if validation, RBAC, and audit trails are thin. It also creates a source-of-truth conflict with translations managed in VCS and deployed through CI. Only adopt it with an explicit security review and a documented policy for where the canonical strings live.
• You were planning to submit fixes here. Contributions belong upstream in the Sylius monorepo, or the work will be lost.

How to Pitch It (Stakeholders)

For executives — one paragraph: Admin localization is a gate on entering non-English markets: without it, our local operations, customer service, and merchandising teams work in a second language, which slows them down and increases error rates exactly when we can least afford errors. This artifact is a free, MIT-licensed piece of the Sylius platform — either a corpus of ready-made back-office translations or an admin tool for editing them. Adopting it costs essentially no licensing spend; the real costs are a short QA cycle per locale, a terminology review owner, and, if we take the editing-UI reading, an explicit decision about where canonical translation strings live. The recommendation is to treat it as inherited platform capability, not a new vendor, and to make "admin flows fully translated and glossary-approved for locale X" a launch gate for each new market. If we are not on Sylius, the recommendation flips: use it as a reference design and build a small in-house equivalent — do not adopt the dependency.

For engineering — the honest version: This is not a Laravel package. It is a Sylius/Symfony component published as a read-only subtree split of the Sylius monorepo. Consume it via sylius/sylius, never as a direct Composer dependency. Zero stars and zero dependents reflect the split-repo pattern, not code quality — but they also mean no separate release cadence, no dedicated issue queue, and no community vetting to lean on. Upgrades are coupled to Sylius upgrades. Any gaps, terminology corrections, or locale additions must be handled as application-level translation overrides through Symfony's translation layer, with a documented process for re-checking those overrides after every Sylius bump. If we adopt the editing-UI reading, we own the security review of the write path and a CI job that exercises it against our actual Sylius/Symfony/PHP version matrix — an unmaintained admin plugin drifts out of compatibility quickly, and the failure mode is silent (the plugin loads, then routes or grids break). Genuine upstream defects go to the Sylius monorepo, not here.

What we are explicitly not buying: A translation management system, a translator review workflow, storefront customer-facing copy, or a supported standalone product with an SLA. If we later need per-string status tracking and reviewer queues, that is a separate vendor decision and a separate budget line — and it should be scoped before, not after, we commit to a multi-market rollout.