Zora Laravel Package

Product Decisions This Supports

• Where translations live (single source of truth). The core decision this package informs: do we keep all copy in Laravel's lang/ files and push it into the frontend build, or do we let the JS layer own its own message catalogues? Zora bets on the former — one authority, two consumers. That is a structural choice with long tail consequences for who edits copy and when it ships.
• Build vs. build-it-yourself. Almost every Laravel+SPA team eventually writes a small artisan command or Vite plugin that dumps lang/** to JSON. Zora is a pre-built version of that ~100-line script. The real decision is dependency vs. internal utility, not package vs. no solution.
• Scope of an i18n roadmap item. It cleanly separates "make strings available in JS" (this package, days of work) from "run a localization program" (TMS, translation QA, locale routing, formatting). Useful for estimating the cheap 20% before committing to the expensive 80%.
• Deploy model for copy changes. Asset-pipeline bundling means copy changes ride with code releases. This directly answers: can marketing change a button label without an engineer? Usually no — and the PM should decide that explicitly rather than discover it.
• Which UI surfaces need JS-side strings. Client-side validation messages, toasts, empty states, modal copy, and any string rendered after hydration. These are the concrete use cases that justify adoption; static Blade copy does not.
• Not a driver for: pricing/localization strategy, market entry sequencing, or TMS procurement. Those decisions are upstream and unaffected.

When to Consider This Package

Adopt when:

• You run Laravel with a Vue/React/Inertia frontend and __() already works server-side, so lang/ is an established convention your team understands.
• Locale count is small (roughly ≤10) and copy ships alongside code; there is no dedicated localization owner demanding independent publishing.
• Vite or Mix is already in the build; you want static, CDN-cacheable JSON per locale rather than a translations API route with its own auth, caching, and payload concerns.
• The team can read and patch the source. At 14 stars, a single-maintainer history, and a last release of March 2024, treat this as vendored code you happen to install rather than a supported product. Pin the version and wrap it behind a thin adapter.
• You want to delete an existing bespoke dump script and standardise the format.

Look elsewhere when:

• You need ICU message format, gender/plural rules beyond Laravel's | syntax, or per-locale number and date formatting — pair vue-i18n, next-intl, or FormatJS with your own extraction instead.
• Translators or copywriters must publish without an engineering deploy. That points to a TMS plus runtime delivery, or a DB-backed loader such as spatie/laravel-translation-loader.
• The locale matrix is large (20+ locales or many regional variants). Build-time bundling inflates output unless you split per-locale chunks — you will end up building that yourself, at which point the package is a small part of your own tooling.
• You need instant runtime locale switching, per-tenant translation overrides, or A/B-tested copy variants.
• Procurement requires vendor support, an SLA, a security review, or a maintenance guarantee.
• The app is Blade-only. Use @lang and skip this entirely.
• A middle path fits better: pass translations through Inertia shared props or a /api/translations endpoint. Simpler to reason about, at the cost of payload size and cache-busting work.

How to Pitch It (Stakeholders)

For executives: this is translation plumbing, not a localization platform. It lets us reuse the copy we already maintain in the Laravel backend inside the JavaScript frontend, so the same string isn't written, translated, and maintained twice. The cost is an afternoon spike and effectively zero infrastructure; the return is eliminating a class of drift bugs where the server says one thing and the UI says another. It does not give us translation management, translator workflows, or locale-aware formatting — those remain separate roadmap items if we pursue multi-language seriously.

For engineering: a small, MIT-licensed Laravel package that moves lang/ files into the Vite/Mix asset pipeline as JSON consumable by Vue or React. It replaces the hand-rolled export script most teams write. Caveats are real: 14 stars, one maintainer, last release March 2024. Recommend pinning the version, isolating it behind a single adapter module, and keeping a ~30-line artisan fallback that dumps lang/ to JSON so we can drop the dependency in an hour if needed.

Recommendation: run a timeboxed spike on one low-risk surface — client-side validation messages and toast copy — and measure whether it removes duplicate string maintenance. Decide on the broader i18n direction (bundled vs. TMS-driven) only after that, because the two paths have very different cost profiles and this package only serves the first.