Weave Code
I18N Laravel Package
ibexa/i18n
The official translation meta-repository for Ibexa, centralizing locale files synced from Crowdin so translations ship with the product. Enable them via the ibexa.ui.translations.enabled configuration, and contribute new translations through the Ibexa project on Crowdin.
At a glance
Frequently asked questions about I18N
- Is ibexa/i18n a Laravel package?
- No. ibexa/i18n is a Composer-installable meta-repository that centralizes translation resource files for Ibexa DXP, a Symfony-based commercial CMS/DXP. It contains no service provider, no middleware, no publishable Laravel config, and no Laravel integration surface of any kind. Evaluating it as a Laravel package is a category error; the real question is whether you are adopting Ibexa DXP itself.
- How do I install ibexa/i18n and enable the translations?
- Run composer require ibexa/i18n inside an existing Ibexa DXP project, then set ibexa.ui.translations.enabled to true in your Ibexa YAML configuration. There are no migrations, schema changes, runtime services, or API surfaces to wire up. The entire integration is one Composer dependency plus one configuration flag.
- What license does ibexa/i18n use, and can I use it without an Ibexa subscription?
- GitHub reports the license as NOASSERTION because the source is offered separately under the Ibexa Business Use License Agreement (Ibexa BUL) v2.3 or later, which is granted by holding a valid Ibexa DXP subscription, and alternatively under GPL v2. The BUL path is proprietary and entitlement-gated, so the decision belongs to legal and procurement, not engineering. Using the package outside a valid Ibexa subscription is a compliance exposure, and the GPL v2 option carries copyleft obligations you must clear before shipping.
- Does ibexa/i18n work with Laravel's translation system, __() helpers, or lang files?
- No. The catalogs use Ibexa-specific message keys such as ibexa.ui.* that are only meaningful inside the Ibexa translation pipeline. Laravel's translator expects its own lang directory structure and key conventions, so these files would not resolve to anything useful. Copying locale files in as raw reference material just creates an unmaintained fork with no consuming code.
- Which Ibexa DXP versions is ibexa/i18n compatible with, and what happens on a version mismatch?
- Compatibility tracks Ibexa core releases rather than any PHP framework version, because the translation keys mirror product strings shipped in Ibexa core. A bundle that is ahead of or behind your installed core version produces missing-key fallbacks instead of hard failures, which is silent degradation and the worst failure mode for i18n. Pin your Ibexa core version and confirm the supported tag matrix before upgrading either side.
- How are translations updated in ibexa/i18n, and how often?
- An integration between Crowdin and GitHub pushes new translator messages to the l10n_main branch, opens or updates a pull request, and the PR is then squash-merged into main and tagged when needed. The cadence is driven by the vendor's translation workflow, not by your release cycle. If your organization requires a separate TMS or a formal localization sign-off process, that needs to be reconciled up front.
- How do I override or add project-specific translations on top of ibexa/i18n?
- Do not fork the meta-repository. Use your project's own translation domain and resource-path precedence so local overrides win over the packaged catalogs, keeping ibexa/i18n as an unmodified upstream dependency. Confirm which locales are fully covered upstream and which ones need project-level overrides before you plan a release.
- How can I detect missing translation keys in CI?
- The package ships no test suite, no CI badges, and no contributing guide, so translation regressions are caught by users rather than automated gates. Add your own check that compares the key set of each locale against the fallback locale and fails the build on gaps. Also verify the configured fallback locale behavior so untranslated keys degrade predictably rather than rendering raw key names.
- Is ibexa/i18n actively maintained, and what community support is available?
- Community signal is effectively zero: roughly 3 stars and 0 dependents, which is normal for a vendor-internal data repository and should not be read as a quality signal either way. There is no external documentation, no third-party issue history, and no community fallback if something goes wrong. Support comes through your Ibexa DXP subscription, and you should verify the actual current release tag and changelog because the published metadata date is anomalous.
- What are the alternatives to ibexa/i18n for managing Ibexa translations, or for Laravel projects needing i18n?
- On Ibexa DXP, the alternatives are taking the vendor bundle, maintaining your own project-level translation overrides, or running a separate TMS and exporting catalogs yourself. There is no meaningful cherry-pick path, because the keys have no consumers outside Ibexa. If your platform is Laravel rather than Ibexa, this package has no architectural fit at all and you should use Laravel's native lang files with a TMS such as Crowdin, Loco, or Phrase instead.
Weaver
How can I help you explore Laravel packages today?