Lingua Laravel Package

Product Decisions This Supports

• Build vs. buy on localization tooling. Lingua turns "do we buy Lokalise/Crowdin/Weblate/SimpleLocalize seats or build in-house?" into a third option: self-host a package inside the existing Laravel app. This is a direct input to any localization vendor renewal or procurement decision — model seat costs and content-manager headcount against an internal admin surface with no per-seat, per-string, or per-locale pricing.
• Localization ownership model (engineer vs. non-engineer). Because translations are editable via a Livewire admin UI against a database driver, copy changes can be handed to content, marketing, or support staff without a deploy. That unlocks roadmap decisions like "can we ship a landing page in five markets next quarter without adding engineering capacity?" and reduces release-coupling for copy-only changes.
• Release process and environment strategy. Database-backed strings mean translation edits no longer require a code review, CI run, and deploy. This supports decisions about decoupling content releases from product releases — and, conversely, forces a decision on how those DB edits propagate to staging/production (import/export is the answer: CSV, JSON, XLSX, ODS with a mandatory dry-run preview).
• Locale expansion sequencing. Bundled dataset of 26 locales × 7 groups (5,902 strings) aligned to Laravel 13, plus per-language coverage bars, group breakdown, and missing-key drill-down. That is a prioritization instrument: a PM can look at coverage percentage per market and decide which locale to fund to completion next, rather than guessing.
• Scope of "translated" as a product requirement. First-class RTL support, rich text (HTML/Markdown) in translations, and vendor/package translation management let you commit to Arabic/Hebrew markets and to marketing-style rich copy without a separate content system.
• AI translation strategy. The Lingua Pro add-on (AI translation, translation memory, glossary, usage analytics) is an explicit buy-up path. That is an "invest in AI-assisted localization or not" call with a known integration cost instead of a new vendor evaluation.
• Multi-tenancy and access-control decisions. Configurable route prefix/extra parameters, gate-based authorization, and a headless language selector mean the "who can edit translations, and in which tenant/brand context?" question has an answer without custom work — relevant for agency, white-label, or per-brand product lines.
• Migration/off-ramp planning. lingua:uninstall exports translations before dropping tables, and file/database drivers are switchable via a single config value. This supports low-regret decisions: adopting it does not constitute a one-way door.
• Use cases it opens: multi-market SaaS launches, regional e-commerce, internal admin tools needing a language switcher, agencies shipping white-label Laravel apps per client, and any team currently hand-editing lang/ files in pull requests.

When to Consider This Package

Adopt when most of the following are true:

• The product is a Laravel 11–13 application, and you are comfortable with PHP 8.3+ — these are hard requirements, not preferences.
• The TALL stack is already in play, specifically Livewire 4.1+ and Flux UI 2.12+. Note that Flux is a commercial, paid Livewire product — the package depends on it for its admin UI. Budget and license review should happen before the technical evaluation, not after.
• Translators or marketers — not just engineers — will be editing copy. That is the whole value proposition of the admin UI.
• You want to stay inside your own infrastructure: no third-party data processor, no content leaving your VPC, no DPA negotiation, no per-seat invoicing. Relevant for regulated, healthcare, public sector, or data-residency-sensitive contexts.
• The translation volume is moderate and single-product: a handful of locales, thousands (not hundreds of thousands) of strings. The bundled dataset and DB/file drivers suit this well; the workflow is not designed for large distributed translator teams.
• Budget discipline matters more than features. MIT license, no seats, no usage tiers.
• You already use or would realistically replace spatie/laravel-translation-loader or laravel-lang/common and want the UI and import/export layer those libraries lack.
• You need CSV/XLSX exchange with external translators, not just programmatic keys. The dry-run preview on import is a genuinely useful governance control for content teams.
• Team continuity risk is acceptable. This is a zero-star, zero-dependent, single-maintainer-adjacent package with a 2026-10-29 release date. You should have a named engineer who can fork and maintain it if it goes dormant.

Look elsewhere when:

• Maturity and ecosystem signal are gating criteria. 0 stars and 0 dependents are not vanity metrics — they mean no community has battle-tested upgrade paths across Laravel major versions, no StackOverflow corpus exists, and hiring or contractor handover is harder. If your org requires a "three production references" bar, this package does not clear it yet.
• You are not on Laravel (Symfony, Rails, Next.js, Django) — nothing here transfers.
• You need professional translator tooling: string context/screenshots, translator assignment workflows, review-and-approve states, translation memory at scale, or comment threads between developer and translator. Lokalise, Crowdin, and Weblate are mature on exactly these and Lingua's README does not claim them.
• You need continuous localization: CLI tooling in CI, GitHub/GitLab sync bots, branch-based translation PRs. Lingua's Artisan commands and bi-directional sync are a thinner version of that pipeline.
• You cannot or will not license Flux UI. That dependency is a real cost, and it is not optional for the admin experience.
• You are on Livewire 3 or earlier. The 4.1+ floor is current-only and may force a framework upgrade to evaluate the package at all.
• Translation content is very high volume or highly dynamic (AI-generated per-user content, UGC localization at runtime). That is a different architecture — a dedicated TMS or a translation API integrated at the service layer, not an admin CRUD UI.
• You need vendor-backed SLAs or enterprise support contracts.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: "Lingua is an MIT-licensed, self-hosted translation manager that turns localization from an engineering task into a content operation. It lets non-technical staff add a language and edit copy through an admin screen inside our existing app, with no per-seat or per-string vendor fees and no translation content leaving our infrastructure. It ships with 26 pre-built locales, spreadsheet import/export so our translators can work in Excel or Google Sheets, and right-to-left support for Arabic and Hebrew markets. It is an open-source dependency, not a subscription — and it exports everything and can be uninstalled cleanly, so it is a reversible decision."

For engineering — the honest technical summary:

• Composer package; installs via composer require rivalex/lingua and an interactive lingua:install Artisan command. Publishes config/lingua.php, driver-aware migrations, seeds the default locale.
• Storage is a single config switch: database (recommended, enables live editing without deploys) or file (writes directly to lang/ PHP and JSON, no DB required). lingua:uninstall exports first, then drops tables and published files.
• Database-agnostic across SQLite, MySQL, PostgreSQL, SQL Server. Translations cached per (locale, group) pair with a configurable store and prefix.
• Ships a fluent Lingua facade for programmatic read/write/language management, so existing code paths can migrate incrementally.
• Handles vendor/package translations safely — a real source of friction with hand-rolled solutions.
• Import/export across CSV, JSON, XLSX, ODS with a mandatory dry-run preview. XLSX/ODS require the optional openspout/openspout dependency.
• Authorization via Laravel Gates, configurable route prefix/extra parameters, optional wire:navigate support, layout override. Headless selector mode gives zero-CSS semantic HTML if we want our own styling.
• Test suite is claimed at 780+ Pest tests with CI and Codecov badges — better hygiene signal than the star count suggests.

For finance and legal:

• License is MIT — no fees, no usage caps, no procurement cycle, no data processing agreement.
• Two cost items to flag clearly: (1) Livewire Flux UI is a commercial license and is required for the admin UI; (2) Lingua Pro (AI translation, translation memory, glossary, analytics) is a separate paid add-on and entirely optional.
• Compare against current spend: Lokalise/Crowdin/Weblate plans are typically per-seat and per-word. Even with Flux and Pro licenses, the recurring cost profile is materially different for a team of five or more content editors.

For the product roadmap — the case for a time-boxed pilot: Recommend a two-week, one-locale spike rather than a platform commitment. Success criteria should be concrete: (a) a non-engineer adds a Spanish locale and edits ten strings without engineering help; (b) an export/import round-trip through XLSX preserves every string including HTML-formatted ones; (c) we confirm Flux licensing cost; (d) we have a named internal owner and a fork-and-maintain plan. Given zero dependents and a new maintainer history, the pilot should explicitly answer "what happens if this package stops being maintained?" before we put a customer-facing market launch on top of it. If the pilot passes, the upside is a localization workflow we own outright, with a clean export path out if we ever change our minds.