Weave Code
Languages Bundle Laravel Package
modera/languages-bundle
A Symfony bundle from Modera for managing application languages and locales. It helps define available languages, centralize localization configuration, and integrate language management into Modera-based admin and content workflows.
[READ-ONLY] Low level utilities for managing languages.
Frequently asked questions about Languages Bundle
- Is modera/languages-bundle compatible with Laravel?
- No. Despite appearing in Composer catalogs alongside Laravel libraries, modera/languages-bundle is a legacy Symfony bundle from the Modera CMS platform that assumes a Symfony kernel, dependency-injection container, compiler passes, and Doctrine ORM entity mapping. It ships no Laravel service provider, facade, publishable config, or migrations, so nothing would work after a composer require in a Laravel application. Treat it as a reference implementation of a language domain model, not a runtime dependency.
- How do I install modera/languages-bundle in a Laravel project?
- You effectively cannot install it cleanly. The package is a read-only subtree split of an internal Modera monorepo with mid-2016 Symfony 2.x/3.0-era constraints, while Laravel 10 and 11 pull Symfony 6/7 components transitively, so Composer will almost certainly fail to resolve dependencies. Forcing it with --ignore-platform-reqs, excluding transitive packages, or rewriting constraints in a fork all produce an unverified or unmaintained runtime rather than a working integration.
- What does modera/languages-bundle actually do?
- It provides a lightweight domain model and service layer for managing the languages available in a Symfony application. You register languages with ISO codes and display names, define a default locale, and expose language data to other bundles and application services. The underlying business problem is small: store roughly 200 rows of static reference data with an enabled flag behind a simple lookup API and a default-language fallback.
- Which Laravel and PHP versions does modera/languages-bundle support?
- None officially. The last release dates to mid-2016 and declares PHP and Symfony 2.x/3.0-era constraints, long before Laravel 10 or 11 existed. Modern Laravel releases require Symfony 6 and 7 components, so the declared constraints are incompatible out of the box. There is no CI matrix, no documented Laravel testing story, and no verified support for PHP 8.2 or 8.3.
- Why does composer require modera/languages-bundle fail with dependency conflicts?
- Because the bundle pins Symfony packages from the 2.x/3.0 era while a Laravel 10 or 11 install already requires Symfony 6/7 components such as console, http-foundation, and process. Composer's solver correctly refuses to satisfy both constraint sets. The three workarounds, --ignore-platform-reqs, a constraint-rewriting fork, or excluding transitive dependencies, each trade a red build for undefined runtime behavior and unpatched security exposure.
- Is modera/languages-bundle safe to use in production?
- No, it carries high and concentrated risk. The code is an abandoned, read-only mirror with possible unpatched advisories in its abandoned transitive dependencies, which can also block release pipelines that enforce vulnerability scans. It also has two stars and zero dependents on Packagist, meaning there is no field evidence it works anywhere and no community review. For a 200-row language lookup table, the risk-to-value ratio is not defensible.
- Is modera/languages-bundle still maintained?
- It is not actively maintained in any meaningful sense. The repository is a read-only subtree split of an internal Modera monorepo with no upstream destination for issues or pull requests, and the last release is from mid-2016. There are no security-patch commitments, no response channel, and no published roadmap. Any bug you hit becomes your own to fix in a private fork.
- Can I fork modera/languages-bundle and maintain it myself?
- You can, but you would be taking ownership of a Symfony bundle you then have to bridge into Laravel. That means rewriting Composer constraints, standing up Doctrine alongside Eloquent, reconciling entity mappings with Laravel's hydration model, and committing to security patches for abandoned dependencies. Verify the license permits a private fork and check whether the Modera platform upstream still tracks this code before considering it. In practice the bridge would be larger and riskier than the domain problem it solves.
- What is a good Laravel alternative for managing languages and locales?
- Build it natively. A languages table with iso_code, locale, display_name, enabled, and is_default columns plus an Eloquent model covers the entire requirement, and symfony/intl (Languages::getNames()) or PHP's Intl extension with CLDR data supplies the display names at zero marginal cost. Wrap lookups in a cached LanguageRepository and add a SetLocale middleware that negotiates against the Accept-Language header. That is a one-to-two-day build with no external dependency risk.
- How do I implement default locale and Accept-Language negotiation in Laravel?
- Read the Modera bundle as a specification rather than a dependency: note its columns, indexes, uniqueness constraints, ordering, enabled-state filtering, and default-language fallback semantics. Then reimplement with a migration, an Eloquent Language model, a cached repository, and a middleware that parses Accept-Language, matches the best enabled language, and calls App::setLocale. Deliberately skip the Doctrine entities, Symfony forms, and bundle DI configuration, which carry all the integration cost and none of the business value.
Weaver
How can I help you explore Laravel packages today?