Translation Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is whitedigital-eu/translation-bundle at 0.2.0 (up from 0.1.2). The -bundle suffix and the release content indicate a Symfony bundle, not a Laravel package: no evidence of a ServiceProvider, config/*.php merge, facade, or package auto-discovery. This is the single largest fit question against our stated Laravel/PHP framing.
• 0.2.0 adds Lexik integration (feat: lexik, PR #4). The Lexik ecosystem reference is LexikTranslationBundle, which persists translations via Doctrine ORM and ships an editing UI. The likely architectural shape is: this bundle wraps/decorates Lexik's translator or loader to add its own translation workflow. That means a Doctrine dependency and a coupling to Lexik's internal service IDs and entity schema.
• Net: viable for a Symfony-first PHP service; not drop-in for a Laravel codebase. In a Laravel context this is at best a reference implementation for translation management patterns, not a dependency.

Integration feasibility

• Composer-installable and low-ceremony for Symfony: register in config/bundles.php, configure, clear cache.
• Now requires a second bundle (Lexik) plus Doctrine, a DB migration for the translation table, and locale configuration in both bundles. Install surface roughly triples versus 0.1.2.
• No published migration notes, config reference, or upgrade guide accompanies the release — one PR title is the entire signal.

Technical risk

• Pre-1.0 semver: the project reserves the right to break in any 0.x minor. 0.1.2 → 0.2.0 introduced a whole integration; assume 0.3.0 can too.
• Transitive coupling risk: pinning to Lexik means inheriting Lexik's release cadence and breaking changes. A Lexik major bump can strand us on an unmaintained wrapper.
• Bus-factor / provenance: the release is a single community PR merged by one maintainer. No CI signal, test coverage claim, or security review is visible in the notes.
• Configuration drift: two bundles owning locale/fallback configuration is a classic source of silent misconfiguration (translations resolve in dev, miss in prod).
• Unverified: whether the Lexik integration is opt-in or always-on. If the bundle now hard-requires Lexik, 0.2.0 is effectively breaking despite the minor version bump.

Key questions

1. Is this a Symfony bundle only, or is there any Laravel/illuminate/support compatibility layer we missed?
2. Is the Lexik dependency required or a suggested/optional integration? (Determines whether 0.2.0 is breaking.)
3. Which Lexik major versions are supported — is there a conflict constraint, or an open-ended ^ that will silently break?
4. Test coverage and CI status on the 0.2.0 tag; is the Lexik path covered by tests at all?
5. Maintenance commitment: is there a funded maintainer, or is this PR-driven volunteer work?
6. Does the integration introduce any schema migration we must run against a production translation table?

Integration Approach

Stack fit

• If our target is Symfony: good fit, provided we are already on Doctrine and comfortable adopting Lexik as the translation store.
• If our target is Laravel: treat 0.2.0 as not directly consumable. Options are (a) reject, (b) fork and port the Lexik-facing logic onto a Laravel translation loader + spatie/laravel-translation-loader-style DB store, or (c) use it only as design reference.

Migration path

• From 0.1.2: verify the Lexik requirement first. If required, this is a two-step migration — install and configure Lexik, run its schema migration, backfill existing translations into the Lexik table, then bump this bundle. Do not bump and configure in one release.
• From nothing: scaffold in a non-production Symfony service, exercise the full locale matrix, then promote.

Compatibility

• Pin exactly (0.2.0), not a caret range, until the Lexik constraint is confirmed. Add an explicit Composer conflict entry for Lexik majors we have not tested.
• Confirm PHP version support and Doctrine DBAL/ORM version alignment against our platform image before committing.

Sequencing

1. Spike (≈1–2 days): confirm Symfony-only, confirm Lexik is optional vs required, read the merged diff of PR #4.
2. Compatibility matrix: PHP × Symfony × Doctrine × Lexik, on our actual runtime.
3. Non-production integration including translation backfill and a locale fallback test.
4. Production rollout behind a feature flag on a low-traffic service; keep 0.1.2 as the rollback target.
5. Only then evaluate whether porting to Laravel is worth the fork cost.

Operational Impact

Maintenance

• Two dependencies to track instead of one, plus a Doctrine schema this bundle owns indirectly. Budget recurring upgrade work each Lexik release.
• No changelog discipline beyond GitHub auto-generated notes; expect to read diffs, not release notes, before each bump.
• Pin-and-review cadence is mandatory; unattended composer update on a 0.x package with an open-ended Lexik constraint is an outage waiting to happen.

Support

• Community-only, small maintainer set, no visible SLA or security disclosure process. Escalation path is "open an issue."
• Internal mitigation: designate one engineer as the owner and be prepared to fork. The code volume is likely small enough that a fork is cheap — verify this during the spike.

Scaling

• Lexik-backed translations are read from the database, so translation lookups can hit the DB on cache miss. Confirm there is a caching layer in front of the loader (Lexik provides one) and that cache warmup runs in the deploy pipeline.
• Under horizontal scaling this is fine once warmed; the risk is cold-cache thundering herd after deploys, and cache staleness after an editor changes a string.
• The editing/management surface is typically admin-only and low-traffic — not a scaling concern.

Failure modes

• Silent misconfiguration: conflicting locale/fallback settings between the two bundles → untranslated strings in production with no error.
• Missing migration: Lexik table absent → hard failure on first translation read or on cache warmup, depending on where the loader is invoked.
• Lexik major upgrade: service ID or entity changes break the wrapper at boot, not at runtime — fails loudly, which is preferable.
• Upstream abandonment: no security patches; we inherit whatever CVEs land in the pinned Lexik version.
• Cache poisoning after backfill: stale compiled translation cache serving pre-migration content.

Ramp-up

• Low for a Symfony team already on Doctrine: roughly 3–5 engineer-days including backfill and validation.
• High for a Laravel team: the Lexik/Doctrine concepts do not transfer, and the realistic path is a 2–4 week port. Recommend a go/no-go decision on porting before any team starts learning this bundle.
• Documentation is thin enough that the spike should include reading the actual source rather than the README.