Localisation Laravel Package

Technical Evaluation

Architecture fit. laravel-enso/localisation is not a general-purpose i18n library; it is a domain module inside the Laravel Enso ecosystem. It provides the locale/content-translation layer that sits on top of enso/core (locale records, translation tables, locale-resolution middleware, and the Enso UI bindings). Its architecture is opinionated by design: models are expected to be Enso models, and content is stored in relational translation tables rather than lang/ files. For a team already standardising on Enso, this is a coherent fit. For a conventional Laravel application, the fit is poor — adopting it effectively means adopting Enso's model conventions and core package.

Integration feasibility. Feasible but conditional. Installation is Composer-based with a required enso/core dependency, published config, and migrations. The real cost is not the install — it is the prerequisite adoption of Enso's core, database conventions, and (if the UI is used) its Vue front-end. A standalone Laravel app cannot adopt this package in isolation without pulling in that substrate.

Technical risk. High relative to alternatives:

• Staleness: last release 2020-11-12; the package has effectively not tracked Laravel's 9/10/11 cycles. Assume a version ceiling on Laravel and PHP until verified in composer.json.
• Coupling: hard dependency on enso/core with a narrow version matrix; upgrading one forces upgrading the other.
• Adoption signal: 13 stars is a very thin community. Expect limited peer support, few battle-tested edge cases, and no external security review.
• Single-maintainer ecosystem: continuity risk sits with the Enso project, not this package alone.
• Licensing is clean (MIT), which at least makes forking and internal maintenance viable.

Key questions to resolve before commitment:

1. Is Enso already (or imminently) our application framework? If no, this package is off the table.
2. What Laravel/PHP versions does the current release actually support, and does our target version fall inside that window?
3. Does the package require Enso's front-end components, or is the backend usable headless?
4. Are translations stored per-model in relational tables (Enso style) or file-based? This determines the content-migration effort.
5. Who owns the fork if upstream goes quiet?

Integration Approach

Stack fit. Only recommended for Laravel applications already on Enso, or teams willing to adopt it for admin-panel workloads. On that stack it fits well: multi-locale content, fallback handling, and per-record translations come from the framework rather than custom code. On a standard Laravel app, prefer spatie/laravel-translation-loader, astrotomic/laravel-translatable, and mcamara/laravel-localization, which deliver comparable capability without the Enso dependency.

Migration path. Do not migrate existing content as the first step. Sequence it as:

1. Confirm Enso adoption at the platform level (this is the gate).
2. Pin enso/core and laravel-enso/localisation to exact versions; commit composer.lock.
3. Install, publish config, run migrations in a staging database and diff the schema.
4. Seed the locale set and validate fallback behaviour end-to-end.
5. Move a single low-risk content module (e.g. static pages or categories) to translated storage before touching high-traffic tables.
6. Backfill historical content with a scripted, idempotent importer; keep the source data until parity is verified.

Compatibility. Verify the Composer constraints first — a 2020 release likely targets Laravel 6–8 and PHP 7.3/7.4. Treat PHP 8.1+ and Laravel 10+ as unsupported until proven otherwise; a framework upgrade forced by security patching will likely strand this package.

Sequencing. Front-load a two-day spike: install on a throwaway branch, translate one model, exercise a locale switch, and confirm the UI (if applicable) renders translated content. Fund the rest of the work only if the spike passes cleanly.

Operational Impact

Maintenance. Low upstream activity means planned internal ownership: fork to an internal mirror, apply compatibility patches, and track Laravel upgrades yourself. MIT licensing permits this; the budget line item is engineering time, not licence fees. Assign a named maintainer before adoption, not after.

Support. Community-only via GitHub issues, with a very small user base. No SLA, no vendor. Escalation path is reading the source.

Scaling. Translation tables grow linearly with content × locales; index the locale/foreign-key columns and add a translation cache (e.g. Redis or request-level memoisation) for hot paths. Locale-resolution middleware is cheap; the risk is N+1 queries when eager-loading translations is forgotten on listing screens.

Failure modes to plan for:

• Missing translation falls through to the wrong locale or empty string — enforce fallback locale config and surface gaps in QA.
• Schema drift between this package's migrations and enso/core.
• Upgrade deadlock: security patch for Laravel requires a package version that does not exist.
• Silent breakage on PHP version bumps.

Ramp-up. One to two days for a developer already fluent in Laravel and Enso; one to two weeks for a team new to Enso, because the package cannot be understood in isolation. Documentation is thin, so onboarding means reading source. Mitigate with an internal README covering the schema, locale flow, and fallback rules written during the spike.

Recommendation. Conditional go, restricted to Enso-based applications, with an explicit fork-and-own decision, a pinned version policy, and a spike-gated rollout. For any other Laravel application, the equivalent capability is better served by actively maintained, standalone libraries.