Lingua Laravel Package

Product Decisions This Supports

• Localization architecture (single source of truth): Lingua lets the Laravel lang/ directory remain the canonical store for all copy and pushes it into the frontend asset pipeline. This decides a recurring architectural question — do JS frontends read translations from an API, or from a build artifact? — in favor of the build artifact, eliminating a runtime translations endpoint and the cache/versioning work that comes with it.
• Build vs. buy for the export layer: The scope is narrow (a config file plus an artisan generation command that emits JSON/JS consumed by Vite or Mix). Buying is cheap; building in-house is also cheap. The decision should be framed as "do we want to own a ~100-line exporter, or take an MIT dependency?" — not as a strategic platform choice.
• Frontend migration roadmap: Directly enables the Blade → Inertia/Vue/React migration path without a parallel i18n migration project. Strings move with the components; the backend keeps rendering server-side pages with the same keys during the transition.
• Feature work it unblocks: Shipping a localized SPA without a /api/translations round trip — fewer requests on first paint, translations available before hydration, and locale bundles that can be cached and fingerprinted alongside other assets.
• Translator workflow decisions: Whether copy changes require a developer/CI step (generate + deploy) or can be edited live. Lingua implies the former; that is a product-process decision about who owns copy and how fast it ships.
• Use cases to scope against: Laravel + Inertia apps, hybrid Blade/SPA apps, products with a handful of locales and moderate key counts, and teams that already run a build step and want i18n to be a build concern rather than a runtime service.

When to Consider This Package

Adopt when:

• You have a Laravel backend whose lang/ files are already the source of truth, and a JS frontend (Vue, React, Inertia) that needs the same strings — the alternative is duplicating translations, which decays immediately.
• The frontend has a real build pipeline (Vite or Laravel Mix) where an extra generation step is trivial, and dev-mode regeneration can be wired into the watcher.
• Locale count and key volume are modest enough that shipping all strings in the bundle is acceptable, and translation updates shipping with a normal deploy is an acceptable SLA.
• You are comfortable pinning a small, MIT-licensed dependency and reviewing its output. The generated artifact is plain JSON, so the blast radius of removal is one build step.

Look elsewhere when:

• Non-developers must edit copy at runtime. Strings baked at build time mean every copy change is a deploy. That is the single biggest product constraint here. If marketing or translators need live edits, use a DB-backed translation loader, or a TMS with over-the-air delivery (Lokalise, Phrase, Crowdin).
• Many locales or a large catalog. Shipping every locale to every user inflates bundles; a per-locale fetch or split chunks is the better shape.
• You need pluralization/ICU semantics richer than the consuming JS library provides — Lingua transports strings, it does not solve message formatting.
• Adoption risk is unacceptable. 26 stars and 0 dependents means effectively a bus factor of one. For a risk-averse org or a long-lived product, prefer a better-adopted equivalent (e.g., the PHP-side export in laravel-vue-i18n) or own the exporter internally.
• Backend is not Laravel, or the frontend is a separate deployable with its own release cadence.

If adopted, de-risk it: wrap the generated output behind your own i18n module so the source can be swapped without touching component code, pin the version, and add a CI check that the generated file is current.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost piece of plumbing that lets our Laravel backend and our JavaScript frontend share one set of translations instead of maintaining two. It removes a network request per page load, keeps copy consistent across server-rendered and interactive pages, and costs roughly a day of engineering to integrate. It is MIT-licensed with a narrow surface area, so the switching cost is low — the generated output is plain JSON and can be produced another way if we ever need to. The honest caveat: the project is young (26 GitHub stars, no dependents), so we should treat it as a convenience we can replace, not a foundation.

For engineering: Add the package, publish the config, and generate translations as part of the asset build, with regeneration in the dev watcher. The frontend consumes the emitted JSON through the standard i18n library. Because there is no runtime API, caching and cache-busting are inherited from the asset pipeline. Two guardrails: (1) wrap the generated files in a thin internal adapter so the dependency is replaceable; (2) add a CI assertion that generated translations are in sync with lang/ so we never ship stale copy.

Decision requested: Approve adoption as a reversible, tactical dependency for the current frontend localization work, with a review trigger if the frontend moves to runtime-editable translations or scales past a handful of locales.