Laravel Translatable Laravel Package

Product Decisions This Supports

• Market expansion and localization roadmap. This package is the enabling primitive behind "do we ship locale #2?" decisions. It gives every Eloquent model a side-table of per-locale attribute values with locale fallback and a translate() accessor, so the question shifts from "how many sprints to rebuild the content layer?" to "which markets, in what order?" That is a roadmap decision, not an engineering one. The new Locales helper class (v10.0.0) modestly lowers the cost of the "add a market" step by centralizing locale registry/negotiation instead of hand-rolling it in config and middleware.
• Build vs. buy for i18n plumbing. The architecture it implements — one *_translations table per translatable model, locale-keyed rows, fallback chain — is the thing your team would otherwise hand-roll. Use it to size the alternative: days of integration versus weeks of custom migrations, accessors, admin form work, and eager-loading optimization. This is now a genuine three-way comparison rather than a two-way one: this repo (revived), its maintained fork, or a JSON-column approach.
• Data model choice with downstream product consequences. Side-table-per-model (this package) versus a single JSON translations column (the Spatie approach) is a product decision disguised as a schema decision. Side tables make locale-scoped queries, sorting, uniqueness constraints, and full-text search on translated fields straightforward; JSON columns make writes simpler but push search and reporting into generated columns or external indexes. This affects whether "search products in German" is a SQL query or a search-infra project.
• Admin and content-operations design. The package's model (all locales edited on one record) versus separate localized content entities determines CMS UX, editor headcount, and whether translations go through a review workflow. Worth deciding explicitly before the CMS backlog is written.
• SEO and market-entry specifics. Per-locale rows make hreflang, locale-prefixed routes, and per-market metadata cheap to implement, which directly gates organic acquisition in new markets.
• Dependency lifecycle and upgrade risk. The risk profile has changed shape, not disappeared. The headline objection in the prior assessment — archived repo, 2019-era last release, "you'd be the maintainer on day one" — no longer holds literally: v10.0.0 is a real, versioned release with a new helper class and two fixes. What replaces it is a thinner but still real risk: single-maintainer cadence, no published support matrix in the release notes, and a track record we cannot yet call steady. The v10.0.0 major bump is itself a mildly positive signal — they versioned a save-semantics change as breaking rather than shipping it silently.

When to Consider This Package

Consider it:

• You are evaluating i18n architecture and want a compact, readable implementation of the translations-side-table pattern. Source and docs remain a better specification than most internal design docs.
• A small, fixed locale set (2–5), modest content volume, no requirement to full-text search translated fields at scale, and no dedicated i18n budget.
• You want the side-table architecture with a canonical, MIT-licensed upstream rather than a fork-of-a-fork, and you have verified — in code, not from release notes — that it runs on your Laravel/PHP versions. Do this before committing: the v10.0.0 notes announce features and fixes but say nothing about the supported framework/PHP matrix, and that is the single fact that decides adoption.
• You have an existing install on this package. v10.0.0 is a major bump that drops the custom save() method in favor of a saved event listener — a write-ordering and transactional-semantics change. Audit any code that relied on the old save path, then upgrade deliberately rather than opportunistically.

Look elsewhere:

• The release notes do not establish Laravel 8+/PHP 8+ support, an upgrade path across future framework majors, or anything about the repo's long-term stewardship. If your answer to "who patches this in 18 months?" is "unclear," default to astrotomic/laravel-translatable (near-identical API, so the decision stays reversible) and revisit when a support matrix and a release cadence exist.
• You need a dependency with a demonstrated multi-year maintenance record and a supported-version policy you can put in a procurement form.
• Translated content must be searched, faceted, sorted, or reported on at scale — evaluate a JSON column with generated columns, or a dedicated search index, rather than multiplying joins per locale.
• High locale count (10+) or high row churn, where side tables inflate table count and join cost.
• You need translation workflow features the package has never had: review states, TMS/Phrase/Lokalise sync, per-locale publishing, or permissions. v10.0.0 does not change this gap.

How to Pitch It (Stakeholders)

To executives: "This isn't a purchase — it's a well-understood pattern we can adopt in days instead of building from scratch. It's the cheapest path to shipping our second and third market, and it makes per-market SEO and content operations straightforward. The project was dormant and has just published a new major version, so the 'abandoned dependency' objection is weaker than it was — but one release is not a maintenance track record. We'd adopt the same architecture either way; the only open question is whether we take it from this repo or from its maintained fork. Either choice is reversible at the model layer, and we can decide inside a week."

To engineering: "v10.0.0 is a real release: a new Locales helper class, a getRelationKey() fix, and the custom save() method dropped in favor of a saved event listener. Treat the last item as the important one — it changes when translations get written and how they interact with transactions and other save-time listeners, which is why it's a major bump. Existing installs need an audit of anything that depended on the old save path before upgrading. Note the release notes tell us what changed but not what it supports — confirm Laravel/PHP compatibility from composer.json and CI before anyone plans around this. If the matrix is current and we're comfortable with single-maintainer risk, this is back on the table as a first-class option. If not, astrotomic/laravel-translatable remains the default for this architecture, with spatie/laravel-translatable as the JSON-column alternative. Same data shape, so this stays a reversible decision — but only if we decide now."