Ink Translatable Laravel Package

Product Decisions This Supports

• Localization data model (the real value here). ink-translatable embodies the "side table" translation pattern: one row per (model, locale, attribute) rather than a column-per-locale or a single JSON blob. Use it as a concrete reference when writing the ADR for how translated content is stored. That decision is expensive to reverse once content exists, so it's worth pinning down early.
• Cost-per-locale on the roadmap. If translations live in data rather than schema, adding Spanish/Japanese/German is a config + content-ops exercise, not a migration + release. This package's shape supports that framing; use it to argue for or against the pattern, not to argue for the dependency.
• Build vs. buy (really: build vs. copy). The capability is small — a trait, a relation, a locale resolver, a fallback. A PM can credibly scope this as 1–3 engineer-days in-house, which makes "add a third-party dependency" the harder case to justify for something this thin.
• Fallback behavior as a product rule. Whether untranslated content falls back to the default locale or is hidden/flagged is a product and SEO decision (hreflang, duplicate-content, partial-launch markets). Translating-model libraries force you to make that call explicitly; treat it as a decision this area surfaces, not one the package answers for you.
• Not a vendor-selection input. Zero stars, zero dependents, and a Laravel 4-only scope mean there is no market validation, no field-tested edge cases, and no community to inherit maintenance. Do not let it anchor a "we'll use the standard package for this" decision.

When to Consider This Package

Consider it only if:

• You are maintaining a Laravel 4.x application that cannot be upgraded in the current planning horizon, and you need translation storage for a small, bounded set of Eloquent models.
• You want a reference implementation to read, fork, or reimplement in your own codebase — the pattern is sound and portable; the code is old.
• You have an engineer who will own and patch it, and you've accepted that the dependency is effectively vendored source, not an upstream.
• Your translatable surface is small (a handful of CMS models), your locales are few, and you have no admin-UI or TMS integration requirement.

Look elsewhere if:

• You are on Laravel 5.5+ or later. Use spatie/laravel-translatable (JSON columns) or astrotomic/laravel-translatable (side table) — both actively maintained, tested, and widely deployed. The side-table/JSON choice should drive the pick, not this package.
• You need PHP 7.4/8.x compatibility, type declarations, or static analysis in CI. Laravel 4-era code predates all of it.
• You need search across locales, locale-aware routing, hreflang generation, or a translation management system (Crowdin, Lokalise, Phrase). This is a persistence helper, not a localization platform.
• Supply-chain or security review applies to your stack. An unmaintained dependency with zero dependents is a finding, not a footnote — no patches, no CVE visibility, no upgrade path.
• Content volume or locale count is large enough that the side table's row count and join cost become a query-performance concern you'd need to benchmark anyway.

How to Pitch It (Stakeholders)

For executives: We evaluated a community package for translating content in the Laravel app. It's a Laravel 4-era library with no adoption — zero dependent projects, no maintainer activity — which means we would be the only ones maintaining it. The underlying idea (store translations as data so adding a market doesn't require a database change) is the right one and is what other, actively maintained packages do. Recommendation: adopt the pattern, not the package. The capability is roughly 1–3 engineer-days to implement in-house or a one-line swap to a maintained alternative, both of which are cheaper than carrying an abandoned dependency through a security review and a future framework upgrade.

For engineering: Treat ink/ink-translatable as documentation, not a dependency. It shows a workable translatable-trait + translations-table shape, but it targets Laravel 4 and carries no test suite signal, no PHP 7/8 support, and no upgrade path. If we want the side-table model, use astrotomic/laravel-translatable; if we want JSON columns for simpler content, use spatie/laravel-translatable; if we want neither, write the ~50-line trait ourselves so we own the locale-resolution and fallback semantics. Whichever way we go, decide the fallback rule (fallback vs. hide vs. flag) before we seed real content, and define the migration path off any per-locale columns we already have.

Bottom line: High pattern value, zero adoption value. Score this as research input to an architecture decision, not as a candidate dependency.