Nova Translation Editor Laravel Package

Technical Evaluation

Architecture fit. This is an admin-plane Nova tool, not a runtime dependency. It renders behind the authenticated /nova route and gives authorized users one screen to browse locales, search keys, and edit PHP/JSON translation values. Nothing in the request path should reference it, which is what makes the blast radius containable: if it breaks, an internal editing workflow degrades, not the customer-facing app. Critically, it is an add-on to an existing Nova decision — it is not, on its own, a reason to adopt Nova.

The write path is the decision. Before any adoption conversation, a TPM needs a definitive answer to whether this tool (a) writes to a database-backed translation store the app resolves on every request, or (b) mutates lang/ PHP/JSON files directly. Case (a) is a privileged write path into production localization data — manageable with backups, a gate, and a reviewed deploy path. Case (b) risks overwriting developer-authored files with no diff, history, or rollback unless lang files are git-tracked and saves flow through normal review. This single unknown determines the risk posture, the audit design, and the rollback plan. It is answered by reading src/ and the published migration — an afternoon of work.

Integration feasibility. The gate is Composer resolution, not code. The repo is archived, the last release was 2023-03-01, there are 13 stars and zero dependents — that places it in the Laravel 9/10 + Nova 4 era. composer require followed by composer why-not answers viability in minutes. If it does not resolve cleanly against current laravel/framework and laravel/nova constraints, the package is not adoptable as-is; it is a fork candidate or a reference implementation. The codebase is a single-screen tool small enough to read end to end, which bounds both due diligence and fork cost.

Technical risk. Unmaintained plus low adoption is the core risk: the archived tag's illuminate/* and Nova upper bounds will eventually block a framework upgrade and force an unplanned fork-or-remove decision. Secondary risks are operational and quiet rather than loud: Nova tools ship pre-built JS, so a Nova minor bump can render a blank tool screen with no PHP error until nova:publish runs; the sole v2.0.4 fix was CSS-level (“avoid overflow”), signalling a hand-tuned front end sensitive to Nova layout changes; and any layout or string-length bug filed after March 2023 is yours. Assume no granular authorization, no audit trail, and unverified cache invalidation until proven otherwise in src/.

Key questions to close before a pilot:

• File-based or database-backed writes — and is that write path acceptable for production localization data?
• Do saves bust Laravel's compiled translation cache (and spatie/laravel-translation-loader's, if present)? Silent stale reads after a successful save erode editor trust faster than a hard error.
• Does it ship any authorization beyond “can access Nova,” and where do we add our own gate?
• Does it scan vendor/ translation groups? Writing there is destructive across composer install; scanning there is slow and misleading.
• Is there pagination and server-side filtering for the index screen?
• Who is the named owner of the fork, and what is the per-major compatibility budget?

Leverage. The highest-value use of this package is not adoption — it is de-risking a build decision. A half-day spike against it answers whether in-admin translation editing reduces localization friction, and produces a concrete UX reference for a thin custom Nova resource over a translations table (group, key, locale, text), which is roughly 3–5 dev-days and eliminates the fork obligation entirely.

Integration Approach

Stack fit. Requires an existing Laravel Nova installation and file- or DB-backed Laravel translations. It fits teams where localization tickets are currently fulfilled by engineers editing files — the value is shifting that work to content owners inside a panel they already have credentials for. It does not fit multi-tenant translation workflows, approval chains, translation memory, TMS integrations, or CI validation; those are different products.

Migration path. Three realistic endpoints, and the TPM should name the trigger for each up front:

1. Spike only — validate demand, discard. Lowest cost, no ownership.
2. Forked internal utility — vendor into a private Composer VCS under your own namespace on day one. “Pin upstream and hope” is not a strategy for an archived repo.
3. Replace — thin custom Nova resource or maintained Nova package or SaaS localization platform, at a documented trigger (next Laravel/Nova major, or the first requirement the fork cannot meet).

Compatibility. Sequence this work away from framework upgrades. Never evaluate this tool in parallel with a Nova or Laravel major bump — the failure modes are indistinguishable and you will burn days attributing blame. Pin the package, re-verify at every Nova/Laravel major, and run php artisan nova:publish plus a hard refresh after any Nova minor. Test with a realistically long value (200+ characters, RTL) on day one, since the overflow fix in v2.0.4 is the last one you will get.

Sequencing.

1. composer require + composer why-not — resolution is a hard stop gate.
2. Read src/ and the published migration end to end; confirm the exact class and namespace rather than trusting README snippets.
3. Register the tool in NovaServiceProvider::tools(); publish config; migrate only if a migration is published.
4. Timeboxed spike on a branch: edit one string end to end in staging, clear translation cache, confirm the front end reflects it.
5. If the spike passes, add an explicit gate (Gate::define('editTranslations', ...) or tool-level authorization), restrict the exposed locale set, and put lang/ under version control with diffs treated as the audit trail.
6. Small internal pilot with named editors; define success criteria before launch — reduced localization tickets, faster time-to-edit, fewer engineering handoffs.
7. Decision gate: keep the fork alive with a named owner and per-major budget, or replace. Write the exit plan down before the first non-spike commit.

Operational Impact

Maintenance. The package has no upstream maintenance; the cost transfers entirely to you. Budget roughly half a day per Nova/Laravel major for compatibility re-verification, plus a standing line item for security review when the fork is touched. The fork is small enough that this is bounded — but only if a named engineer owns it. Unowned forks degrade into broken admin screens discovered by an editor mid-task.

Support. There is no vendor support, no maintained documentation, and no issue triage. Self-support is the model: trust src/ over the README, keep a short internal runbook (install, publish, cache flush, rollback), and expect namespace drift between versions. Editors will escalate to the owning engineer, not to a community.

Scaling. The index screen is the constraint. Hundreds of locales by thousands of keys will make it unusable without server-side filtering and pagination — confirm both exist in src/ before putting a large translation set in front of editors. Scope the exposed locales deliberately to the ones content owners actually own; exposing everything in config/app.php slows the screen and widens the blame surface. If the tool scans the filesystem, verify it does not walk vendor/.

Failure modes to plan for.

• Composer conflict — the upgrade is blocked, forcing a rushed fork-or-remove decision. Mitigate by tracking the constraint and deciding at a known trigger, not under pressure.
• Blank or partial tool screen with no PHP error — stale compiled assets after a Nova bump; fix with nova:publish and a hard refresh.
• Save appears to succeed but nothing changes — permissions failure on lang/, unflushed translation cache, or editing a locale that is not the one app()->getLocale() resolves. Check git diff lang/ or the table first, then storage/logs/laravel.log.
• Overwrite of developer-authored files — the file-based case with no built-in history. Git is the only audit trail, and only if lang files are committed and deploys go through review.
• Destructive writes into vendor/ — wiped on the next composer install.

Ramp-up. Low for editors — it is a single search-and-edit screen, requiring minutes not days of training. Higher for the owning engineer: half a day to read the source end to end and run the spike, plus the standing compatibility budget. The asymmetric cost is the point: cheap to trial, cheap to teach, but not free to own. Frame the pilot accordingly — the deliverable is a validated workflow and a written build-or-buy recommendation, not a production dependency.