I18N Laravel Package

Product Decisions This Supports

• Localization delivery model (build vs. buy): Informs whether your team builds its own translation pipeline or outsources to a TMS (Crowdin, Lokalise, Phrase). Ibexa's choice here — translators work in Crowdin, a bot pushes to an l10n_main branch, a PR lands in the repo — is a template you can copy conceptually without adopting the code.
• Content vs. code separation: Confirms translation strings belong in a dedicated, frequently-updated artifact separate from application releases, gated behind a feature flag (ibexa.ui.translations.enabled). Useful precedent when arguing for decoupling locale updates from your deploy train.
• Ecosystem/vendor commitment: This package only has value if you are on Ibexa DXP. It's a signal for roadmap decisions about platform lock-in and whether your i18n strategy should depend on a vendor's translation cadence.
• Release cadence planning: Translations ship on Crowdin's rhythm, not semver. If you mirror this pattern, your release notes and QA cycles need to absorb "translation-only" PRs as a distinct, low-risk change class.
• Coverage/scoping conversations: Supports decisions about which locales are "product-supported" vs. "community-contributed" (the Crowdin project is open for contributions), which affects support burden and marketing claims.

When to Consider This Package

Consider it only if:

• You run Ibexa DXP (formerly eZ Platform Enterprise) with a valid commercial subscription, and you need the shipped UI translations enabled.
• You want translated product strings without commissioning your own translation vendor for the Ibexa admin/studio UI.
• You are studying translation workflow architecture — the automated GitHub ↔ Crowdin sync with squashed-commit PRs is a genuinely reusable pattern.

Look elsewhere if:

• You are building a Laravel application that is not Ibexa. This is a meta repository of translation content, not a runtime i18n library. It provides no Laravel service provider, no loader, no locale negotiation. Use laravel-lang/*, spatie/laravel-translation-loader, or your TMS's SDK instead.
• License compatibility matters. The license resolves as NOASSERTION; the README states it is available under the Ibexa Business Use License (BUL) v2.3+, granted only with a valid Ibexa DXP subscription. That is not an OSI license — a legal review is mandatory before any use, and it is a hard blocker for redistribution or non-Ibexa products.
• You need community validation. 3 stars, 0 dependents, no third-party usage. There is no signal of external production adoption and no ecosystem to lean on for support.
• You need stable versioning. The listed release date (2026-08-20) indicates machine-driven publishing; treat version numbers as translation snapshots, not API contracts.

How to Pitch It (Stakeholders)

Executives: This is not a software dependency we would adopt — it is a translation content repository for a specific commercial CMS (Ibexa DXP), published under a commercial license that requires an active Ibexa subscription. For our stack it delivers no product capability and carries licensing risk. The one thing worth taking is the process: an automated translator-tool → pull-request pipeline that decouples localization from our release cycle. Recommendation: do not adopt; optionally reuse the workflow pattern with our chosen TMS at near-zero cost.

Engineering: No integration work exists to do here — no package to install, no API, no hooks. It is a content mirror with a YAML toggle (ibexa.ui.translations.enabled). Reading it is worthwhile for one reason: it shows a clean, low-friction pattern for inbound translation updates (branch-per-sync, bot-authored PRs, squash-merge, tag when needed). If we build in-house localization sync, this is a reasonable reference architecture. Do not add it to composer.json; do not assume it is open source.

Risk summary: Commercial/non-OSI license (blocker for most uses), 3 stars and zero dependents (no external validation), vendor-tied scope (zero utility off Ibexa), and automated release cadence that does not follow semver. Cost of adoption for a non-Ibexa team: not worth evaluating further beyond the workflow pattern.