Locale Laravel Package

Product Decisions This Supports

• Locale expansion sequencing. Because every supported language is a versioned artifact in one canonical catalog, a PM can treat "which markets do we ship next?" as a data-and-release decision rather than a code project. Adding a locale is a content change plus a package bump — not a sprint of scattered edits across frontend strings, plugin files, and framework-native resource formats.
• Whether localization is a platform capability or a feature. This package's architecture (source locales → canonical JSON → ecosystem packages → merged with repo-local overrides at app boot) is the shape of an internal platform decision. Choosing it signals "translations are infrastructure we version and govern," which changes how roadmap items for i18n get scoped and staffed.
• Build vs. buy for translation operations. It directly frames the TMS question (Crowdin, Lokalise, Phrase, Weblate). This package solves distribution and consistency, not authoring workflow. A PM can adopt it as the delivery layer underneath a bought authoring layer, or as a full in-house substitute — a materially different cost and headcount story.
• Plugin/ecosystem coherence as a product promise. The package explicitly consolidates catalogs from the Vue frontend and every backend plugin into one source of truth. If the product surface includes plugins or multiple framework targets, this buys the promise "the app and all its extensions speak the same language"—which is otherwise a per-release QA tax.
• Release and versioning policy. Translations ship as a semver package to Packagist and peers. That makes translation drift auditable, gives you rollback of a bad locale, and lets a PM answer "which string set is in production?" without archaeology.
• Localization quality and drift reduction. The merge-at-boot model with repo-local overrides means product repos can carry context-specific strings without forking the catalog — useful when deciding how much localization ownership to decentralize to feature teams.
• Use cases worth prototyping: multi-market launch readiness, white-label or reseller deployments needing per-tenant overrides, and CI pipelines that fail on missing translation keys.

When to Consider This Package

Consider it when most of the following hold:

• You ship more than one framework target or more than one repo. The value proposition is cross-ecosystem fan-out (Composer, npm, RubyGems, Maven, NuGet, Hex). A pure Laravel application with a single lang/ directory gets little from it.
• You already have, or are willing to build, a source-of-truth repo. The package is a publisher and a merge mechanism, not an extraction tool. Adoption presumes a canonical locales/{locale}.json set exists.
• You want versioned, rollback-able translations. The release cadence and semver distribution are real operational wins over ad-hoc string edits.
• Your runtime cost budget is near zero. For Laravel the Composer artifact is essentially a data payload plus a boot-time merge with repo-local overrides — no runtime service, no network call, no SDK to instrument.
• You're inside or closely modeling the Escalated ecosystem. This is a first-party, internally-scoped package; that is the primary reason it exists at all.

Look elsewhere when:

• You need an authoring and review workflow. No translator UI, no comment threads, no screenshot context, no approval gates described. If your localization manager is a human who needs a tool, pair this with a TMS or choose one.
• You need mature ICU/CLDR handling. Pluralization, gender, and interpolation semantics per framework (Rails YAML, Django/WP gettext, Symfony artifacts are mentioned) are a hard problem, and nothing in the README excerpt claims parity across them. Verify before committing a roadmap to it.
• You rely on community support. Two stars, zero dependents, and a single project scope mean no ecosystem safety net, no Stack Overflow corpus, no third-party tutorials. Bus factor is the practical risk.
• You are Laravel-only. Laravel's native lang/*.php and __() helper, optionally with a translation package from the broader community, cover most single-repo needs with far more documentation.
• You need runtime language switching of content, per-user dynamic strings, or database-backed translations. This is a build-time catalog, not a translation service.
• You require a vendor-neutral or independently governed solution. This is a component of one product's architecture; adopting it imports that product's release rhythm and directory conventions.

How to Pitch It (Stakeholders)

For executives (one minute). We can ship a new language or market by changing content and bumping a version, not by scheduling engineering work across the app and every plugin. That shortens the path from "we should enter market X" to "market X is live," and it makes translation state auditable — we can always say exactly which strings are in production and roll them back if a launch goes wrong. The cost is low: for our Laravel services it is a Composer dependency carrying data, merged at boot, with no runtime service and no per-request overhead. The honest caveat is maturity: this is a small, single-project package with negligible independent adoption, so we should treat it as an internal-style dependency we are prepared to own, fork, or replace, not as a de-risked third-party standard. Recommended framing: adopt the architecture — one canonical catalog, versioned fan-out, repo-local overrides — and treat the package itself as an implementation we can swap.

For engineering leads (the technical summary). The Composer package delivers framework-native locale artifacts plus canonical JSON, merged with repo-local overrides at application boot. That means: no runtime dependency, no network calls, deterministic startup cost, and overrides stay local to each repo instead of forking the catalog. Translations become a versioned release artifact with a diffable history, so translation drift shows up in review rather than in a support ticket. Where we should push back or plan work: the package is a publisher, not an authoring tool — extraction, review, and translator workflow are ours to supply; pluralization and interpolation parity across ecosystems is unproven and needs a test matrix before we promise quality; and there is no community fallback, so we should budget for ownership. Practical recommendation: prototype on one secondary market, measure the authoring workflow gap, then decide between this distribution model and a TMS-owned one before generalizing.