Laravel Translation Loader Laravel Package

Product Decisions This Supports

• Runtime-editable copy without a deploy. A database-backed translation loader moves strings out of lang/ files and into storage your team can change live — this directly supports decisions like "can marketing fix this typo on Friday afternoon without an engineer," and removes translation updates from the release train.
• Localization roadmap / market expansion. Adding a locale becomes a data operation rather than a code change plus PR. That changes the cost model for entering new markets and makes "ship 6 languages next quarter" a content-ops plan rather than an engineering epic.
• Build vs. buy for translation management. The realistic alternatives are (a) hand-rolled translations table + custom loader, (b) this package, (c) a full TMS (Lokalise, Crowdin, Phrase) with API sync. This package sits in the middle: it removes the build cost of the loader and caching layer without buying a translator workflow product. Choose it when you need runtime mutability, not when you need translator collaboration tooling.
• Multi-tenant and per-account overrides. DB-backed translation sources make it feasible to scope strings per tenant, per plan, or per white-label brand — a pattern that is awkward to express with file-based lang/ directories and usually forces a fork of Laravel's translator.
• Admin/back-office feature bets. If a CMS-lite "manage labels and copy" screen is on the roadmap, this package is the plumbing that makes that screen cheap instead of a multi-sprint project.
• Platform upgrade planning. Release 1.2.0 adds Laravel 13 support and widens PHP from ^8.3 to ^8.1, so adoption is no longer gated on a PHP 8.3 upgrade. That removes a real objection in a legacy-heavy estate and keeps this package viable on the current LTS-to-next framework window.

When to Consider This Package

Adopt when:

• Copy changes are frequent, editor-owned, and currently blocked on deploys.
• You have (or are planning) more than a couple of locales, or tenant-specific wording.
• You're on Laravel 10–13 and PHP 8.1+, which after 1.2.0 covers effectively your whole supported matrix.
• You want the loader + cache + fallback mechanics solved, and you're prepared to own the editorial layer yourself (admin UI, permissions, audit trail).
• You need a per-environment override (e.g. staging copy in DB, code defaults in files) and want Laravel's translation API unchanged — a good loader is a drop-in and doesn't leak into call sites.

Look elsewhere when:

• Translations are static and developer-owned. A DB round-trip and a cache to invalidate are pure overhead versus lang/ files.
• You actually need a translation management system: translator assignment, review workflows, glossary/terminology enforcement, string extraction from source, MT, per-key screenshots. That's a TMS purchase, not this package.
• You need heavy pluralization/ICU semantics beyond what Laravel's translator gives you — validate before committing.
• You cannot accept the operational surface: cache invalidation on write, a migration, a table that grows with locales × keys, and the risk of DB-sourced strings diverging from version-controlled defaults. If you have no story for seeding/restoring those rows, file-based translations are the safer default.
• Single-maintainer risk is unacceptable for a critical path. This is a small package by an individual maintainer — acceptable for most product teams, but it should be a conscious call. Pin the version and keep an exit path (the loader interface is small; swapping back to files is a contained change).
• Due diligence before adoption: confirm cache behaviour and invalidation hooks, confirm the fallback/locale-resolution story, and confirm query load under your key volume — a per-request hit on an uncached translations table is the classic failure mode here.

On 1.2.0 specifically: minor, non-breaking, additive. No deprecations, no migration work, no API changes. It also widens the PHP floor and extends the test matrix to cover the Laravel 13 / PHP 8.1–8.2 pairings it claims to support — a credible signal that compatibility is tested rather than asserted. Low-risk upgrade; worth taking if you're on Laravel 12 and eyeing 13.

How to Pitch It (Stakeholders)

For executives: We have two viable ways to manage product copy — in code, or in the database. Today, every wording change is an engineering ticket and a release. This package lets non-engineers change copy directly, which converts recurring engineering work into content operations and shortens the loop from "marketing wants to reword the checkout page" to "done." The cost is small: one dependency, no new vendor contract, no new system to run. It also de-risks our platform upgrade — the latest release supports Laravel 10 through 13 and PHP 8.1+, so it won't become the thing that blocks us next year. Recommendation: adopt for runtime-editable copy; keep a documented fallback to file-based translations.

For engineering: This is a Laravel translation loader — a DB-backed driver for the existing translator, not a parallel i18n system. Call sites don't change; __() keeps working. It absorbs the part we'd otherwise hand-roll: source resolution, caching, and fallback. Version 1.2.0 is additive and non-breaking — Laravel 13 support, PHP floor widened to 8.1, orchestra/testbench ^11.0 and Pest 4 constraints extended, CI matrix expanded with explicit exclusions for unsupported framework/PHP pairs. No migrations or API changes on upgrade. What we still own: schema/migrations, cache invalidation on write, seeding and drift control against version-controlled defaults, and the admin surface. Two things to verify in a spike before we commit: the cache invalidation path on translation writes, and query cost at our key volume with a cold cache. Exit cost if we change our mind: low — it's a loader behind Laravel's translator interface, so reverting to file-based sources is a contained change, not a rewrite.