Weave Code
Entity Translation Bundle Laravel Package
hostnet/entity-translation-bundle
A Symfony bundle for translating Doctrine entity fields per locale. Store and retrieve localized entity content with minimal setup, making multilingual applications easier to build and maintain.
Hostnet Entity Translation Bundle adds transparent, locale-aware translations to Doctrine entities in Symfony applications. It keeps translated fields alongside your entity while exposing the correct value for the active request locale—without duplicating your domain model or scattering translation logic.
- Translate entity fields per locale with a simple mapping
- Automatic locale resolution with configurable fallbacks
- Works with Doctrine ORM and Symfony’s service container
- Keeps original entities clean and easy to query
- Supports forms and CRUD workflows for managing translations
Frequently asked questions about Entity Translation Bundle
- Can I use hostnet/entity-translation-bundle in a Laravel application?
- Not directly. The package is a Symfony bundle whose value is delivered through a DependencyInjection extension, service definitions, a symfony/translation translator, and a Twig extension, and Laravel has none of that wiring. If the label resolver is plain PHP you can vendor that one class, but in most cases you are reimplementing the convention rather than integrating the package. Treat it as a reference implementation and specification, not a Composer dependency.
- How do I install hostnet/entity-translation-bundle?
- In Symfony you would run composer require hostnet/entity-translation-bundle, register the bundle in config/bundles.php, and add any required configuration under config/packages. There is no supported Laravel installation path, and no service provider is shipped. Before relying on it, verify the release history on Packagist and GitHub, because the stated last release date looks anomalous.
- Does the bundle support PHP 8.1 backed enums or only class constants?
- This is unconfirmed and should be the first thing you check in a spike. The description says enum-like classes, which historically means class constants such as OrderStatus::PENDING rather than native backed enums. If the package predates or ignores PHP 8.1 enums, adopting its convention would put you behind your language baseline, so you would be better off writing a native enum label resolver yourself.
- What translation key convention does the bundle use for enum labels?
- The bundle maps a class constant to a translation key and then to a human label, but whether that key pattern is configurable or hardcoded is not documented in the overview. A typical shape is entity.field.value, for example order_status.pending. For a Laravel port, a cleaner convention is enums.{snake_case_class}.{value}, which is a naming decision you control rather than something the package must provide.
- What happens when a translation key is missing?
- The blurb promises graceful fallback so content stays readable, but the exact behavior, whether it throws, returns the raw value, or returns the key, is not confirmed. This matters because missing keys are common during rollout and a thrown exception will break admin tables and exports. Write an explicit test for the missing-key path before you depend on this behavior in production.
- Does it work with Laravel's __() helper and Illuminate\Translation?
- No. The bundle is built around symfony/translation contracts such as TranslatorInterface, and Laravel uses Illuminate\Translation with its own __() helper and :name placeholder syntax. Symfony-style %name% placeholders will not be replaced by Laravel's translator, so an adapter or a rewrite is required. If the resolver sits behind Symfony interfaces, you are porting the logic, not integrating it.
- Is there a Blade directive equivalent to the bundle's Twig helper?
- The package ships a Twig extension, not a Blade directive, so nothing renders out of the box in Laravel. You would add a small Blade directive or a view helper that calls your own label resolver and then passes the result through __(). That helper is roughly ten lines and is the only UI-facing piece you actually need from the bundle's design.
- Is hostnet/entity-translation-bundle actively maintained and which Laravel versions does it support?
- Adoption signals are near zero: roughly 5 stars, 0 dependents, and a single vendor publishing a broad portfolio of bundles, so maintenance attention is hard to infer. The recorded last release date appears to be in the future, which should be verified against Packagist tags before any decision record claims active maintenance. Laravel version support is not applicable because the package targets Symfony, and PHP 8.1 enum support is unconfirmed. The MIT license is the real mitigant, since fork-and-own is always available.
- What are the alternatives for translating enum labels in Laravel?
- Laravel already provides lang files, the __() helper, locale switching, and pluralization, so the only missing piece is a convention mapping a domain value to a key. A small EnumLabel service with a label(BackedEnum|string $value): string method covers the same ground in under a hundred lines. Community enum packages that ship label and description methods are another option, and they avoid the Symfony coupling entirely.
- How should I test enum label rendering in a Laravel app?
- Write a unit test that iterates over every enum case, asserts the resolved translation key, and asserts the rendered label for each configured locale. Add explicit cases for a missing key to lock down fallback behavior, and a feature test asserting the rendered Blade output so regressions in the directive are caught. Because the bundle brings no Laravel test harness, those tests are entirely yours to own and maintain.
Weaver
How can I help you explore Laravel packages today?