Nova Translation Editor Laravel Package

Product Decisions This Supports

• Localization workflow ownership: Decide whether translation edits should live in Laravel Nova — where content owners, support, or ops can change strings without a deploy — or stay with engineering as a code-reviewed file change. This package lets you prototype that workflow before committing to a custom build or a paid TMS.
• Build vs. buy vs. borrow for i18n tooling: With 13 stars, zero dependents, an archived repo, and a last release in March 2023, this is a borrow-the-pattern option, not a strategic dependency. It informs the decision to (a) fork and own a small Nova tool, (b) build a thin custom Nova resource, or (c) buy a maintained localization platform.
• Roadmap scoping for a self-service translation editor: Use it to size and validate the smallest useful version of the feature — browse locales, search keys, edit PHP/JSON values, save — so you can compare against the scope of a custom build (roughly 3–5 dev-days for a basic Nova resource) and against SaaS pricing.
• Ticket-deflection business case: Frame success criteria up front: reduction in small localization tickets, fewer engineering handoffs, faster time-to-edit for content owners. A timeboxed pilot on this package produces the evidence needed to justify (or kill) further investment.
• Risk and maintenance budgeting: Make the ownership cost explicit and visible to stakeholders — compatibility checks at every Laravel/Nova major, a named fork owner, backup and rollback plan, access gating, audit trail, cache invalidation. This is the number that makes the build-vs-buy call honest.
• Access and governance policy: Because Nova’s default authorization is “can access the panel,” adopting this tool forces a decision on who may rewrite customer-facing copy — a policy question PMs should own, not inherit from an unmaintained package.
• Exit-plan definition: Decide the trigger and the destination before the first non-spike commit: keep the fork alive with a per-major maintenance budget, or replace it with a thin custom Nova resource or a TMS. This prevents the decision from being made under upgrade pressure.

When to Consider This Package

Consider it when:

• You already run Laravel Nova and use file-based (PHP/JSON) Laravel translations. This is an add-on, never a reason to adopt Nova.
• The need is an internal, low-volume editor for a small team, not a mission-critical localization platform or multi-tenant translation workflow.
• You can fork or vendor-copy on day one and assign a named engineer to own compatibility — “pin upstream and hope” is not a plan for an archived repo.
• You want a half-day spike to test whether in-admin translation editing actually reduces friction, before funding a build or a purchase.
• The blast radius is containment-friendly: the tool renders behind Nova’s authenticated /nova route and nothing in the request path depends on it.
• You have confirmed the write path: whether it mutates lang/ files directly or writes to a database-backed store, and whether backup, authorization, audit history, and cache invalidation meet your bar.

Look elsewhere when you need active maintenance, vendor support or security guarantees, translation memory, approval workflows, TMS/CI integrations, granular per-locale permissions, audit history, or compatibility with current and future Laravel/Nova releases. Also look elsewhere if your translation volume is large (hundreds of locales × thousands of keys) and pagination/server-side filtering is unproven — or if the strings are customer-facing in a regulated context where an unaudited write path is unacceptable.

How to Pitch It (Stakeholders)

To executives: This package is a cheap way to test whether letting non-engineers edit Laravel translations inside Nova removes small localization tickets and speeds up content changes. It is not a platform bet: the repository is archived, has very low adoption, and has not shipped since March 2023. Recommendation: fund a short internal pilot with clear success metrics, use it as a UX and scope reference, and only commit budget to a build or a maintained/paid solution if the workflow proves valuable. The real decision on the table is not “adopt this package” — it is “is in-admin translation editing worth owning, and who owns it.”

To engineering: Treat bernhardh/nova-translation-editor as an unmaintained Nova utility, not a runtime dependency. Gate one: does it resolve against our current laravel/framework and laravel/nova constraints? Gate two: confirm the write path — file mutation of lang/ versus a database-backed translation store. If it writes to production localization data, it needs a policy gate, backups, and an audit trail we supply ourselves; if it rewrites files, the lang directory must be git-tracked and saves must flow through normal review. Fork or vendor it before the first non-spike commit, run nova:publish after any Nova bump, verify cache invalidation on save, and test long and RTL strings against the March 2023 front end. Budget roughly half a day per Nova/Laravel major for upkeep, with replacement by a thin custom Nova resource as the standing alternative.

To content and support leads: The promise is real — one screen to browse locales, search keys, and fix strings without a ticket to engineering — but access will be narrower than “anyone with Nova,” changes need a review step, and the tool has no built-in history. Pilot with a small, explicit set of locales and a single owner, and measure time-to-edit and ticket volume before we widen access.