Craftable Translatable Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. The package covers the model-layer half of i18n (translated attributes on Eloquent models, locale enumeration, per-locale form validation). That lets you commit to "launch in N locales" as a content/DB decision rather than a re-architecture project — decide the locale list and rollout order first, and the storage/validation plumbing is largely already solved.
• Build vs. buy. Translation storage, locale fallback, and validating localized form input are undifferentiated plumbing on every multilingual product. Adopting this package avoids a bespoke translations table + validation layer that your team would own forever.
• Schema choice: JSON columns vs. per-locale tables. HasTranslations implies translated attributes stored alongside the model, which favors the simpler schema: one row per entity, no joins for reads, no whereHas gymnastics. Good trade if you query by entity and render all locales; a worse trade if you need per-locale filtering, sorting, or search at scale — worth validating against your actual query patterns before committing.
• Validation as a product-quality lever. TranslatableFormRequest means localized fields get first-class validation rules instead of hand-rolled loops in controllers. This is what keeps a partially-translated record from shipping to users — a directly user-visible defect class in multilingual products.
• Infrastructure de-risking. The 2.0.1 CI matrix now runs over PostgreSQL and MariaDB (with healthchecked docker-compose). That's evidence the maintainers test against the databases you're likely to run, which lowers the risk of adopting this on a Postgres-backed stack rather than defaulting to MySQL for compatibility reasons.
• Release cadence as a health signal. 2.0.1 is an explicitly non-breaking maintenance patch ("nothing to do when upgrading") with added test coverage. That is the profile of a package you can pin and upgrade on a routine cadence without budgeting migration work.

When to Consider This Package

Consider it when:

• You have multilingual content modeled as Eloquent entities and want translated attributes without a parallel translation table and join-heavy reads.
• Your localized input arrives through Laravel Form Requests and you want per-locale validation rules expressed declaratively rather than in controller code.
• You're on a supported Laravel version and a mainstream relational DB (MySQL/MariaDB/PostgreSQL) — the CI matrix now covers the latter two explicitly.
• Your locale set is modest and relatively stable (a handful of languages), edited by the same team that ships the product.
• You want a small, single-purpose dependency rather than a full i18n framework.

Look elsewhere when:

• You need an editorial/translation workflow: review states, per-locale publishing, translator handoff, or TMS (Crowdin, Lokalise, Phrase) integration. This package stores and validates translations; it does not manage the translation process.
• You need to query, filter, sort, or full-text search within translations at scale. JSON-style translated attributes are the wrong shape for that; per-locale translation tables (or locale-specific search indexes) serve you better.
• You need localized routing, URL segments, hreflang generation, or locale-aware middleware — adjacent concerns that belong to dedicated packages.
• You already run a competing translatable implementation (e.g. a JSON-translation package) — migrating for parity is churn without user-facing benefit.
• You need per-locale access control or compliance-driven data residency for translated content.

How to Pitch It (Stakeholders)

To executives: This is a small, mature Laravel dependency that handles the mechanical half of launching in new languages — storing translated fields and validating localized form input. The 2.0.1 release is a maintenance patch: no breaking changes, no migration, nothing to schedule. Two things matter commercially. First, it converts "expand into new markets" from an engineering project into a content-and-configuration exercise, which shortens time-to-market for each additional locale. Second, the maintainers added database coverage for PostgreSQL and MariaDB, so adopting it doesn't force a database decision for compatibility reasons. Ongoing cost is near zero: pin the version, upgrade on a routine cadence.

To engineering: Patch release, upgrade is a no-op. Relevant changes: closures in TranslatableFormRequest, HasTranslations::toArray(), and Translatable::getLocales() are now parameter-typed; TranslatableFormRequest::rules() guards the is_array($rule) branch before array_search(), fixing a path that previously ran against string rules too — a real correctness fix in rule matching, and it now has test coverage; and HasTranslations::getLocale() resolves from the container rather than the app() helper, which is the better behavior for testing and for non-default container bindings. Scope check before wide adoption: verify our query patterns don't need per-locale filtering or sorting, since translated attributes stored inline favor read-by-entity over search-within-translation. If that holds, the integration surface is small: a trait on the models, a base form request, and a locale source.