Product Decisions This Supports
- Admin content-authoring UX for localized content. This package addresses a real, recurring need: editing rich text per locale inside Laravel Nova. That decision shows up in any product with marketing pages, product descriptions, legal/policy copy, help-center articles, or email templates that ship in more than one language — the editor experience in the admin directly affects how fast content ships and how many formatting bugs reach production.
- Build vs. buy vs. borrow. This is a "borrow from a micro-repo" option rather than a buy. It informs the classic trade: adopt a small open-source field, vendor/fork it, or spend 1–3 days building an equivalent Nova field in-house around a maintained editor. Given the packaging (no Packagist presence, no stars, no dependents), the realistic decision is fork-and-own, not "adopt and depend."
- Roadmap sequencing on legacy admin. If the product is on Nova 3/4 and a Nova 5 or Filament migration is 2–4 quarters out, a small vendored field can unblock localized rich-text editing now without committing the roadmap to a bigger admin rewrite.
- Editor standardization. Choosing CKEditor 4 is a product decision, not just a technical one: it sets authoring conventions, paste-from-Word behavior, HTML output shape, and the sanitization policy downstream. This package effectively locks that choice in, so it should be evaluated alongside "what editor do we standardize on across the product."
- Where it should not drive decisions. Greenfield builds, regulated/security-reviewed environments, customer-facing multi-tenant SaaS, and any product with a multi-year support horizon should not take a dependency on an unmaintained field wrapping an end-of-life editor. The "opportunity" signal (niche demand for translatable rich-text fields in Nova) is worth noting in a backlog; the package itself is not the artifact to bet on.
When to Consider This Package
Consider it when:
- You are already on Laravel Nova and already standardized on CKEditor 4 for other fields, so this adds locale support without introducing a second editor.
- Your translatable fields follow a pattern the package matches (per-locale attribute storage, e.g. JSON columns or a translations table), and you can verify that in the source before committing.
- The team is willing to vendor the code into the repo (or pin a commit via a Composer
vcs repository entry, since there's no Packagist release to depend on), assign an owner, and read the ~few hundred lines it likely contains.
- The admin is internal-facing, the user count is small, and a broken editor is an inconvenience rather than a revenue or compliance event.
- You need a short-term unblock measured in weeks, not years.
Look elsewhere when:
- CKEditor 4's end-of-life matters to you. CKEditor 4 passed its official end-of-life in mid-2023; ongoing security fixes are a paid extended-support arrangement. Building new localized authoring on it means inheriting an editor with no free upstream patch path.
- You need maintained dependencies. Zero stars, zero dependents, and a self-hosted Framagit origin mean no community triage, no security review, no issue tracker signal, and no guarantee the maintainer is still active. There is no bus factor to speak of.
- Nova 5 compatibility is unverified — a field package is tightly coupled to Nova's field lifecycle and Vue component build, and a stale Nova field can break silently on upgrade.
- You have a security or procurement review: an unreviewed third-party package rendering user-authored HTML into an admin panel is exactly the kind of dependency that review exists to catch.
- You want a maintained editor going forward: Nova's native textarea/Markdown fields, a maintained Tiptap/ProseMirror-based Nova field, or CKEditor 5 field packages all offer a supportable path — typically combined with
spatie/nova-translatable for the locale UX.
- You need accessibility guarantees, RTL support, or collaborative editing on a roadmap.
How to Pitch It (Stakeholders)
One-liner for executives: There's a small open-source add-on that lets editors write rich text in multiple languages inside our Laravel admin. It solves a genuine workflow gap, but it's an unmaintained wrapper around an editor that's past end-of-life — so the recommendation is a short, time-boxed spike and, if it works, adopting it as our own vendored code rather than as a dependency we rely on someone else to keep alive.
For engineering: Treat this as source code to review and own, not a library to install. There's no Packagist release, no stars, no dependents, and the upstream is a self-hosted GitLab — so pin a commit, vendor it into the repo, add it to the upgrade checklist, and confirm Nova version and translation-storage compatibility before wiring it into any field used by real content. Budget roughly a day for the spike and another for hardening.
Recommendation: Run a 1-day spike. If the localized editing UX is materially better than the status quo, fork it with a named owner and a documented exit plan to a maintained editor. If the spike shows friction, skip it and spend the same effort building a thin translatable wrapper around a maintained editor — the field itself is not the hard part, and the editor's support horizon is.