- Is netbull/translation-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle. The vendor name, the Bundle suffix, and the 7.0.x versioning line that tracks the Symfony major release train all point to Symfony 7 rather than Laravel. There is no Laravel service provider or facade, and the project's own evaluation treats Laravel compatibility as effectively non-existent. Plan for it as a Symfony 7 / PHP 8.2+ component only.
- Can I install netbull/translation-bundle in a Laravel application?
- There is no supported integration path. A standard Laravel app has no Symfony bundle registration, no Symfony dependency injection container wiring for this bundle, and no Doctrine ORM by default, so the bundle's services and persistence layer would not boot. You could force the Composer dependency in, but you would be wiring everything by hand with no upstream support. For Laravel, treat this package as a design reference rather than a dependency.
- What Symfony and PHP versions does netbull/translation-bundle require?
- The 7.0.x release line tracks Symfony 7, which implies PHP 8.2 or newer as a practical floor. The exact Composer require constraints should be checked before any planning decision, because they tighten the constraint beyond what the version number alone implies. If your host application runs Symfony 6 or PHP 8.1, expect this line to be out of reach.
- What does netbull/translation-bundle actually do — entity translation or message catalogs?
- The documented scope is locale-aware message catalog management integrated with Symfony's Translation component, with database-backed storage and tooling to edit, organize, and serve multilingual content. It is not confirmed to handle Doctrine entity-field translation, locale route negotiation, or an admin UI. This remains the biggest open question, so verify against the source before committing to it.
- What license does netbull/translation-bundle use, and is it safe for SaaS?
- The package is AGPL-3.0, which is the headline risk in any evaluation. For SaaS and other network-delivered products, most legal teams refuse AGPL outright because serving the software over a network can trigger source disclosure obligations. No dual license or commercial option has been confirmed, so this alone frequently ends the evaluation regardless of code quality.
- Is netbull/translation-bundle actively maintained?
- Yes, but narrowly. A patch release dated 2025-12-27 with a conventional-commits style 'fix: deprecations' message shows the maintainer is still shipping and still tracking upstream Symfony and PHP deprecations. That reduces, but does not eliminate, abandonment and framework-drift risk. It also implies you must track a low but non-zero patch cadence to keep the package installable.
- Does netbull/translation-bundle have tests, CI, or a changelog?
- A changelog exists and appears to be generated from conventional commit messages, which is a mild positive for release hygiene. Test coverage and CI configuration are unverified. With zero stars, no dependents, and no forks, one patch release is not meaningful battle-testing, so audit the repository directly if coverage matters to your team.
- Will netbull/translation-bundle migrations collide with my existing translations table?
- The schema and migration footprint is undocumented and should be treated as unknown. Because the bundle stores translations in the database, it will ship its own tables, and there is a real chance of a name or index collision with an existing translations table in your application. Inspect the migrations and plan a schema review before installing anywhere near production data.
- What should Laravel developers use instead of netbull/translation-bundle?
- Build natively with Laravel's own translation and validation tooling, or pick an MIT-licensed Laravel package that already supports database-backed translations. The recommended use of this bundle in a Laravel context is as a reference implementation: study its schema shape, locale fallback logic, and caching approach, then reimplement those ideas in your own side table. That gets you the design insight without the AGPL exposure or the integration work.
- Is it worth porting netbull/translation-bundle to Laravel?
- Generally no. A hard port carries both engineering cost and AGPL-derived-work exposure, since a close translation of AGPL code is likely to be treated as a derivative work. The Symfony coupling means you would be rewriting the container wiring, persistence, and configuration layer anyway. Reimplementing the pattern from scratch in a small in-house package is usually cheaper and legally cleaner.