Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap scoping. If your product is expanding into new locales but your admin tooling (Laravel Nova) has no translation story, this package is a candidate building block for letting content editors manage translated fields per resource without changing your database schema for every model.
• Build vs. buy for i18n admin UX. The core argument it embodies is a schema decision: translations in a dedicated polymorphic translatables table vs. JSON columns on the parent table. That choice drives query performance, indexing, migration complexity, and how you validate/version translated content — a decision worth making explicitly rather than inheriting by default.
• Choosing an i18n data model. Teams that have rejected JSON-based approaches (e.g., Spatie's laravel-translatable) because of query/reporting pain may use this package as the reference implementation for a normalized alternative.
• Feature-level prioritization. Useful input for deciding whether translated resource management is "table stakes" for your admin (ship now) or a differentiator (invest in a maintained solution or internal build).
• Vendor-risk triage. With 2 stars, 0 dependents, and a low opportunity score, this is best treated as a make-or-fork decision rather than an adopt dependency — it can inform an internal implementation without becoming a supply chain liability.

When to Consider This Package

Consider it only when all of the following hold:

• You are committed to Laravel Nova as your admin layer and need translated fields editable inside Nova resources.
• You specifically want a normalized translatables table (indexable, reportable, no JSON blobs) rather than JSON columns.
• Your localization scope is modest — a handful of locales, a handful of translatable resources — so the cost of maintaining a small package is acceptable.
• You are prepared to vendor/fork and own the code, including migrations, tests, and upgrades, rather than rely on upstream responsiveness.

Look elsewhere (or build internally) when:

• You are not on Nova — this package's value is entirely Nova UI integration.
• You need production-grade support: 2 stars and 0 dependents signals no community validation, no ecosystem pressure-testing, and likely single-maintainer risk.
• You need advanced i18n features (fallback locales, translation workflow/approval, bulk translation management, locale-aware routing) — this addresses resource-level storage, not the broader i18n program.
• Your team already standardized on a JSON-based approach (e.g., Spatie) and the migration cost outweighs the query-model benefits.
• You have high-traffic or reporting-heavy requirements where the join pattern of a polymorphic translations table needs careful benchmarking first.

How to Pitch It (Stakeholders)

To executives: Localization is a growth lever, but it usually stalls on admin tooling — editors can't manage translated content without engineering help. This package is a small, MIT-licensed building block that lets editors manage translations directly in our Nova admin, and it keeps translations in a clean, queryable table rather than buried in JSON. The tradeoff is maturity: it's a very early-stage package with minimal adoption, so I'd recommend it as a prototype or reference implementation, not a production dependency we adopt blind. It de-risks the "how" of localization cheaply while we decide how much to invest.

To engineering: The interesting part is the schema stance — a dedicated translatables table instead of JSON columns, which buys us real indexing and reporting at the cost of joins and migration overhead. Given the package's adoption profile (no dependents, near-zero stars), I'd frame the ask as: spike it in a branch, validate the data model against our reporting needs, and treat it as a fork candidate if it fits. It should not enter our dependency tree without an owner, tests, and an upgrade plan.