Multilingual Nova Laravel Package

Technical Evaluation

Architecture fit. This is a single-purpose Laravel Nova field package that renders locale-keyed JSON translation attributes as a tabbed/collapsible editor inside a Nova resource form. Responsibility is cleanly split: digitalcloud/multilingual owns storage and locale-fallback semantics; this package owns only the admin presentation layer. From a TPM standpoint that is the ideal shape for an internal tooling dependency — it touches no public request path, no API surface, and defines no data model of its own. The scope boundary to hold firm on is that this is editorial admin UX for internal operators, not a localization strategy, a translation delivery engine, or a workflow/TMS capability. Adoption is only coherent if the product already runs Nova as its admin layer and already stores translations as locale-keyed JSON on Eloquent models. If either precondition is missing, this package is not the right lever, and introducing Nova or the parent package purely to justify this field is a negative-ROI move.

Integration feasibility. Mechanically low-complexity: Composer install, publish config/assets, add the field to a resource, ensure the JSON column is cast appropriately. Realistic effort is hours to a first working field and a few days to a validated, regression-tested rollout. Three surfaces must be explicitly inspected before committing budget: the published config (locale list, fallback behavior), the field service provider (v3.0.0 reworked field registration in PR #56, so field names/aliases may have shifted from v2.x), and compiled assets under public/vendor (locale switcher plus the new custom-CSS hook). The custom-CSS and translated-tool-title additions are genuine editor-experience wins worth citing when justifying the work, but they also widen the surface area to test.

Technical risk. The dominant risk is maintenance and ecosystem validation, not code correctness. Evidence: 65 stars, zero dependents, last release 2021-12-21, no published compatibility matrix for current Nova/Laravel/PHP, and a major version (v3.0.0) whose notes are dominated by Dependabot frontend bumps and community patches with no enumerated breaking changes or migration guide. The dependency list (node-sass, websocket-extensions, elliptic, ini, y18n, lodash) signals a legacy asset pipeline predating current Node/bundler norms; those bumps are historical CVE remediation, not proof of a current build chain. Compounding this: Nova itself is a paid first-party dependency, so we would be layering an unmaintained community wrapper on a commercial platform whose own upgrade cadence can break us. Budget this as a risk-accepted internal tool, not as a free capability.

Key questions.

• Which Nova, Laravel, and PHP versions does v3.0.0 actually support, and has anyone verified it against our current versions?
• What are the breaking changes from v2.0.4, and is there a migration path for existing translation data shapes?
• Are field APIs, service-provider registration, config keys, and published asset paths backward compatible, or did v3.0.0 reshuffle them?
• What test coverage and CI compatibility matrix exist upstream — is there any automated signal?
• Who owns this upstream, and is there a stated maintainer commitment or sunset plan after four-plus years without a release?
• How does underlying digitalcloud/multilingual handle locale fallback and partial translations, and does that match editorial expectations?
• If we adopt and the package dies, what is our exit cost (custom field replacement effort, data portability — likely yes, since translations are plain JSON — confirm)?

Integration Approach

Stack fit. Adopt only into a codebase already on Nova for internal administration and already storing translations as locale-keyed JSON. Do not pull in Nova, or digitalcloud/multilingual itself, merely to justify this field. Where the team is on a different admin framework, a custom field or a plain JSON textarea is a cheaper and more durable bet than taking on an unmaintained dependency. Frame the spend as admin productivity for editors, not a customer-facing localization capability — it should never appear in a platform roadmap narrative.

Migration path. Two scenarios that must not be conflated:

1. New adoption — no data migration. Start pinned exactly on v3.0.0, validate in staging against a representative resource (a short title plus one longer translatable body field), verify the JSON round-trip in the raw DB row across two locales, and confirm index/detail views render the active locale rather than the raw blob.
2. Upgrade from v2.x — pin and freeze the current version in the lockfile first, review the full diff and each PR referenced in the v3.0.0 notes (especially the field service provider change in PR #56), diff any published views/config/assets we have locally modified, then upgrade in a branch, republish and rebuild assets, and regression-test create/update/delete, locale fallback, tool titles, and the new CSS hooks against real multilingual resources before promoting.

Compatibility. Treat compatibility as an open item until proven, not an assumption. Build a minimal matrix of our current Nova major, Laravel major, PHP version, and Node/build toolchain, and empirically confirm the field registers, the locale switcher renders, assets resolve from the correct published path, and the JSON column cast round-trips. Capture the result as an internal compatibility note so the next upgrade does not re-derive it. If any of those four surfaces fails, stop and reassess rather than patching upstream in a fork we would then own indefinitely.

Sequencing. (a) Confirm Nova + locale-keyed JSON preconditions and name an internal owner. (b) Spike the field on a scratch branch in staging with the exact pinned version. (c) Verify config keys, service-provider registration, and published asset paths, including the custom-CSS hook. (d) Run an editor-facing usability pass with real locale count and field volume — validate that tabbed locale panels actually improve throughput at our scale. (e) Document the exit path and data portability before the first production resource ships. (f) Only then roll out to additional resources, in small batches, with a rollback pin ready.

Operational Impact

Maintenance. Expect to own this. With no release since December 2021 and no vendor support, the plan must include pinned exact versions in the lockfile, an assigned internal owner with Laravel/Nova fluency, a scheduled review of upstream security advisories on transitive frontend dependencies, and a documented procedure for rebuilding and republishing assets (the legacy node-sass-era pipeline is the most likely thing to rot first). Budget a small recurring maintenance allowance rather than a one-time install cost; without a named owner this dependency quietly becomes unowned and pinned forever.

Support. Community-only. There is no SLA, no compatibility statement, and no evident test/CI signal upstream, so internal engineering is the escalation path for every issue. That is acceptable for an internal admin tool used by a handful of editors; it is not acceptable anywhere near a customer-facing surface. Set that expectation explicitly with stakeholders so nobody interprets "works in staging" as "supported."

Scaling. The meaningful scaling dimension here is not traffic but editorial surface area: locale count × translatable field count × resources. Each added locale multiplies form controls and JSON payload width; with many locales and many translated fields the form can become heavy and the tabbed UI can stop being a productivity win. Watch Nova form render time, page weight on the locale switcher, and the practical editor experience on the largest resource. Database-side risk is low — translations are plain JSON columns — but validate that index/detail views resolve the active locale efficiently and that no view accidentally renders the raw blob. This package is not on any public request path, so it poses no scaling risk to end-user traffic.

Failure modes. Ranked by likelihood and blast radius: (1) Nova/Laravel/PHP upgrade silently breaks field registration or the service provider after the v3.0.0 rework — mitigated by a staging matrix and pinned versions; (2) published asset path or build chain fails after a republish, leaving an unstyled or broken locale switcher — mitigated by checking public/vendor explicitly in the rollout checklist; (3) locale fallback behaves differently than editors expect, producing partial or wrong-locale content that looks correct in the admin — mitigated by testing partial-translation cases with real editors; (4) config drift between environments (locale list, fallback) causing inconsistent editing behavior — mitigated by treating config as reviewed application code; (5) validation gaps on non-default locales allowing incomplete saves — mitigated by exercising per-locale required-field rules in QA; (6) custom CSS hooks colliding with existing admin styles — mitigated by scoping the new class hooks. Exit risk is manageable: translations are plain JSON, so data remains portable even if the package is abandoned; the cost of exit is replacing the admin UI, not recovering content.

Ramp-up. Low technical ramp-up, moderate organizational ramp-up. Engineers need hours to a working field; editors need a short walkthrough of the locale switcher, fallback display, and per-locale validation, plus a documented escalation path when a translation does not appear as expected. The real ramp-up cost is institutional: writing down the compatibility matrix, the pinning policy, the asset rebuild procedure, and the exit plan so the dependency is not tribal knowledge. Deliver those as part of the rollout, not after.