Multilingual Nova Laravel Package

Product Decisions This Supports

• Build vs. buy for admin localization UI: If the product already runs Laravel Nova and editors manage translations stored as locale-keyed JSON on Eloquent models, this package replaces a bespoke multilingual Nova field with a drop-in tabbed locale editor. The decision is narrow: is a small, pinned community dependency cheaper than building and maintaining custom admin UI? It is not a decision to invest in a localization platform.
• Where localization effort lives: It supports the call that internal editorial translation work happens inside the admin tool rather than in a dedicated TMS or custom translation screens. The package covers inline per-locale editing, a locale switcher, fallback handling, and per-locale validation on top of digitalcloud/multilingual. It does not cover translation memory, review/approval queues, machine translation, vendor integrations, or public content delivery — keep those out of the business case.
• Roadmap gating and upgrade timing: v3.0.0 is a major release and therefore a dependency gate for any roadmap item that depends on Nova admin localization. The notes add custom-CSS hooks, translated tool titles, delete-flow improvements, and a reworked field service provider (PR #56), but do not enumerate breaking changes or a migration path. Plan it as a controlled upgrade with staging regression tests, not a routine patch.
• Editor throughput and multi-brand admin: Custom CSS hooks and translatable tool titles support decisions about branding a multi-language or multi-brand Nova admin and reducing editor friction. Justify this only where editorial throughput is a measured bottleneck, not as a general UX investment.
• Maintenance ownership and risk budgeting: With ~65 stars, zero dependents, and a last release of 2021-12-21, adoption implies assigning an internal owner to pin versions, audit published assets, and absorb future upgrades without vendor support. The v3.0.0 changelog is dominated by Dependabot frontend security bumps and legacy tooling (node-sass) — a hygiene signal, but also a legacy-toolchain signal.
• Exit-ramp confidence: Because translations remain plain JSON in existing columns, the data is portable even if the package is abandoned. That lowers the switching cost and makes a bounded, time-boxed pilot a defensible product decision rather than a platform commitment.
• Scope discipline: This is internal content-operations tooling. It should not drive core product strategy or be pitched as a customer-facing localization capability unless multilingual admin editing is a genuine operational bottleneck.

When to Consider This Package

Consider adoption when:

• The product already uses Laravel Nova for internal administration and already stores translations as locale-keyed JSON on Eloquent models. This is a hard prerequisite — do not introduce Nova or digitalcloud/multilingual just to use this field.
• The need is internal editorial/admin UX — tabbed locale editing, fallback display, per-locale validation — not public translation delivery, machine translation, or enterprise translation management.
• The team wants Nova-native translation editing instead of custom admin screens, and the existing workflow already matches the parent package's storage and fallback semantics.
• Engineering can pin exact versions, run staging regression tests, and absorb a major-version upgrade without vendor support, with a named owner fluent in Laravel/Nova.
• Custom CSS hooks or translated tool titles matter for a multi-brand admin, or delete-flow usability is a known friction point addressed by v3.0.0.
• Locale count and field volume are modest enough that collapsing locale panels improve the form rather than make it unwieldy.

Look elsewhere or defer when:

• The product does not use Nova, or is planning to migrate off it.
• You require first-party support, an SLA, a formal security review, or a published compatibility matrix for current Nova/Laravel/PHP versions. None is evident, and v3.0.0 does not enumerate breaking changes.
• You need translation memory, review/approval workflows, vendor integrations, or machine-translation orchestration.
• The upgrade cannot be validated against your stack — particularly field registration, service-provider behavior, config keys, and published asset paths after the v3.0.0 field service provider rework.
• Admin localization is low-value or already solved more cheaply by a simple JSON field or an existing platform capability.
• Many locales and many translated fields make the form heavy; validate that the package actually improves editor throughput at your scale before committing.

How to Pitch It (Stakeholders)

For executives: This is a focused Laravel Nova admin extension that lets internal editors manage multilingual content — translated fields in collapsible locale tabs, locale fallback, and per-locale validation — without us building custom admin UI. The v3.0.0 release is a major version: it adds usability and branding improvements (custom CSS hooks, translated tool titles, delete-flow fixes) alongside routine dependency security updates, but it does not clearly document breaking changes. Treat adoption or upgrade as a controlled maintenance decision, not a free patch. It only makes sense if Nova-based multilingual editing is operationally important; otherwise defer and avoid the dependency. It is internal productivity tooling, not a product differentiator, and carries a small but real ownership cost because the project is community-maintained with low adoption and no release since December 2021.

For engineering: Confirm which Nova, Laravel, and PHP versions v3.0.0 actually supports before committing — there is no published compatibility statement and the last release was December 2021. If we already depend on it, pin the current version in the lockfile, review the full v3.0.0 diff (especially PR #56's field service provider change), upgrade in a branch, republish and rebuild assets, then regression-test create/update/delete flows, locale fallback, tool titles, and the new CSS hooks against real multilingual resources in staging. If we do not depend on it, adopt only where it clearly replaces custom Nova localization UI, pin the exact version, and document an internal owner plus an exit path — translation data is plain JSON, so the data stays portable even if the package does not.