Laravel Inline Translation Laravel Package

Product Decisions This Supports

• Localization/i18n roadmap framing. This package is a useful reference point in the build-vs-buy conversation for multi-language support. It demonstrates the minimum viable "edit copy in the browser" capability, which makes the gap against a real translation management system concrete rather than abstract.
• Build vs. buy for translation workflows. The critical distinction: this package does in-context editing, not translation management. There is no translation memory, glossary, ICU/pluralization handling, review-and-approval workflow, or translator collaboration. Most stakeholders asking for "inline translation" actually want the latter, so this package is valuable for drawing that boundary and grounding the buy decision.
• Admin/CMS feature scoping. Directly relevant when content ops or marketing asks, "can we fix copy without a deploy?" This supports sizing that as a small, bounded internal feature — roughly a one-to-two-week build — rather than a platform investment.
• MVP and internal-tooling decisions. A reasonable pattern to borrow for a prototype or short-lived internal app where a quick editing affordance beats standing up a localization pipeline.
• Content-operations efficiency. It quantifies a real win: non-developers correcting copy without engineering involvement on small content or marketing sites, removing a recurring release-cycle cost.
• Risk and technical-debt assessment. Because it is archived (last release July 2018) with zero dependents, it forces an explicit maintain-vs-replace call. Any adoption is vendoring or forking source, not consuming a supported dependency — that framing belongs in the roadmap item, not buried in an appendix.

When to Consider This Package

Consider it as reference material, a reimplementation pattern, or a legacy stopgap — not as a live strategic dependency — when:

• You need a minimal inline-translation capability inside a Laravel admin surface and want a compact, readable implementation to study.
• You are supporting a legacy Laravel app pinned to the era the package targeted (Laravel 5.6–5.8, PHP 7.1/7.2), where migrating off costs more than keeping it.
• You are prototyping the inline-edit UX to show stakeholders the concept quickly.
• You want to validate demand before committing to an in-house build or a TMS purchase.

Look elsewhere, or build in-house, when:

• You need maintenance guarantees, security patching, or modern framework support — archived since July 2018, no PHP 8 / Laravel 9+ guarantee, so every future upgrade becomes your problem.
• You need translation memory, glossary, pluralization/ICU, review workflows, or translator collaboration — out of scope; this is not a TMS.
• The surface is customer-facing or multi-tenant with compliance, audit, accessibility, or data-isolation requirements around content changes.
• You need volume translation — you want a translation API or vendor, not a click-to-edit affordance.
• Your front end is JS-heavy, Inertia, or headless/API-first — the core mechanism (rewriting HTML responses) stops applying and the package delivers little.
• You cannot commit an owner and a small test suite to a fork.

Adoption criteria to apply: run a timeboxed compatibility spike to confirm framework/PHP support; treat the code as vendored source, not a composer dependency; require a security review before shipping; gate the editor behind auth and a non-production environment flag; define stable translation keys (never key on the English source string, or copy edits will orphan translations); pick one canonical translation store (lang/ files vs. database) and script a one-directional sync; add a CI guardrail asserting every wrapped key has a value for every supported locale.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel add-on that lets teams edit translations directly in the application interface, writing changes back to language files. It is not a strategic investment — the project is archived, unmaintained since 2018, and has zero downstream dependents. Treat it as a reference implementation of the inline-translation-editing pattern, not a roadmap dependency. The underlying need — non-developers correcting copy without a deploy — is real and worth serving. The realistic paths are a small in-house build (roughly one to two weeks) or a maintained TMS, both of which give us modern framework compatibility and a support story. Adopting the package directly would trade a modest build cost for open-ended maintenance and security risk.

To engineering: The package is compact — config, migration, service provider, Blade directive, and middleware — so the blast radius is narrow and forking is feasible. But treat it strictly as legacy source: verify Laravel/PHP compatibility with a one-to-two-day spike first, then decide between a vendored fork and a clean reimplementation (often cheaper once review, tests, and upgrade burden are counted). Hard rules if we proceed: never enable in production; gate on environment/config plus auth, remembering that config:cache freezes that flag; place the middleware last in its group to avoid conflicts with other response-rewriting middleware (minifiers, debugbars); resolve the ambiguity between the "no database changes" marketing claim and the translations migration during the spike, since it determines whether we have a second source of truth; seed the store from existing resources/lang/*.json so we are not retranslating from zero; define stable keys before translating en masse; enforce a one-directional database-to-files export with a committed artifact; and add CI checks for missing translations before anyone outside the core team touches it. If the requirement outgrows a prototype or internal tool, the safer product decision is a maintained internal feature or a TMS integration.