Nova Ckeditor4 Field Laravel Package

Product Decisions This Supports

• Internationalization roadmap sequencing. Release 0.2.0 adds support for dimsav/laravel-translatable, meaning the package can now operate against localized model attributes rather than a single-language schema. This moves "multi-language support" from a bespoke engineering project to a configuration-and-content task — a materially cheaper path to launching a second locale.
• Market expansion business case. If entering non-English markets is on the roadmap, this release is the technical precondition. It lets you scope localization as content translation + QA rather than as a re-architecture of how the package reads and writes data.
• Build vs. buy. Adopting the dimsav/laravel-translatable convention instead of a homegrown translation layer is now viable without losing this package's functionality. That is one fewer integration to design, build, and maintain — worth quantifying against the cost of a custom solution in the next planning cycle.
• Use cases unlocked: multi-locale SaaS tenants, content/CMS-style products with per-locale records, regional storefronts, and any product where the same entity needs different values per language (titles, slugs, labels, metadata).
• Dependency risk to track. dimsav/laravel-translatable is community-maintained and has been effectively superseded by the astrotomic/laravel-translatable fork in the wider ecosystem. Committing to it is a product-level decision about long-term maintenance, not just a technical one — flag it in your dependency review before it becomes load-bearing.
• Maturity signal. Version 0.2.0 means pre-1.0: expect API churn. Do not build a customer-facing commitment on this package without pinning versions and budgeting for upgrade work.

When to Consider This Package

Consider it when:

• You are on Laravel and already use — or are willing to adopt — dimsav/laravel-translatable for model translations.
• Localization is a genuine near-term requirement, not a hypothetical. The value of this release is entirely contingent on having (or planning) translated content.
• You want the package's core behavior to be locale-aware without forking it or maintaining a private patch.
• Your team is small enough that adopting a convention beats building one, and you can absorb pre-1.0 upgrade churn.

Look elsewhere when:

• You have no multi-language requirement — this release adds nothing for a single-locale product.
• You need a full translation management workflow (TMS integration, translator roles, review/approval states). This is a model-layer convenience, not a localization platform.
• You require long-term vendor stability. A pre-1.0 package depending on a superseded translation library is a maintenance liability for a multi-year commitment; evaluate the actively maintained fork instead.
• Your translation needs are string-level (UI copy) rather than record-level (translated domain data). Standard Laravel localization covers that without new dependencies.

How to Pitch It (Stakeholders)

For executives: This release makes the product capable of serving localized content with a configuration change instead of a rebuild. If international expansion is on the roadmap, it lowers the cost and shortens the timeline of that initiative. It is a small, additive release — no breaking changes, no migration required for current users — but it does introduce a third-party dependency, and the package is still pre-1.0, so treat it as an enabler to validate in a spike rather than a commitment to announce.

For engineering: 0.2.0 is a purely additive feature: optional support for dimsav/laravel-translatable models. Existing behavior is unchanged for anyone not using that library. Two points to weigh before adoption — the translation dependency is community-maintained and largely superseded by the astrotomic fork, and the package itself is at 0.2.0, so pin versions and expect API movement. Suggest a short proof-of-concept against a translated model before we plan any work on top of it.