Localization Core Api Laravel Package

Product Decisions This Supports

• API contract for localization as a first-class surface. Decides whether locales, translation catalogs, currency/formatting metadata get a dedicated, versioned read API instead of being duplicated as hardcoded strings inside each product surface.
• Build vs. buy vs. borrow. This is a borrow candidate: a thin presentation adapter over a localization domain module. The decision it informs is "write controllers/resources per app" vs. "standardize on an adapter layer."
• Architecture decomposition. Adopting it is a vote for modular monolith with domain/presentation separation (localization-core holds state; this package holds the HTTP/serialization contract). That choice outlives the package.
• Market-entry roadmap. Multi-locale launch, per-tenant locale configuration, and RTL/currency expansion all need a stable locale-discovery and catalog endpoint. This package is a candidate implementation of that endpoint.
• Portfolio reuse. If several Laravel products in the portfolio need the same /locales, /translations, /currencies shape, one adapter reduces repeated work — but only if governance (license, fork ownership) is settled first.
• Evaluation gate, not procurement. With 0 stars, 0 dependents, and a NOASSERTION license, the realistic decision is "read it, fork it, or copy the pattern" — treat it as a reference implementation until proven otherwise.

Representative use cases: multi-tenant SaaS with per-tenant locale settings; marketplaces with multilingual catalog content; admin consoles for managing translation keys; mobile/web clients that need to discover supported locales and formatting rules at runtime.

When to Consider This Package

Consider adoption when:

• You are already inside the Liberu module ecosystem — localization-core is present, conventions match, and the Laravel version band is compatible.
• You need a conventional read API for locales and translations and want to avoid re-implementing serialization, pagination, and resource shaping in every app.
• Your team is prepared to own the dependency: vendor it, pin the version, read the source, and patch it locally.
• You want a worked example of presentation-adapter layering in Laravel as an internal architectural reference.

Look elsewhere when:

• License is unresolved. NOASSERTION is a red flag; default to "all rights reserved" until counsel clears it. Do not ship in a commercial product on assumption.
• Signal is thin. Zero stars, zero dependents, single-vendor provenance — no community support, no security triage, no upgrade guarantees, no maintainer SLA. The release date (2026-10-26) is ahead of observed consumption; maturity is unproven.
• You need hardened i18n. Laravel's native lang files, spatie/laravel-translatable, mcamara/laravel-localization, or a managed TMS (Crowdin, Lokalise, Phrase) cover pluralization, ICU edge cases, and translator workflows with real support.
• You need delivery at scale. CDN-backed translation delivery, cache invalidation, and fallback chains are typically outside a presentation adapter's scope — confirm before assuming coverage.

Diligence checklist before any commitment: confirmed OSI license, upstream CI/tests, ≥1 external dependent, documented API versioning, and a named internal owner for the fork.

How to Pitch It (Stakeholders)

For executives. A small, unproven Laravel component that exposes localization data as an API. Its standalone strategic value is low; its value is as a reusable pattern and as a shortcut if we standardize on the Liberu modular stack. Adoption cost is low, but the cost of dependence is real: unclear license status, no user base, and a single maintainer. Recommendation: time-boxed spike only — no production dependency until legal clearance and a fork-and-own plan are in place.

For engineering. It is a presentation adapter: a thin HTTP layer over a localization domain module. The value is separation of concerns — the domain owns locale and translation state; the adapter owns serialization, versioning, and contract stability. If we adopt it, we own it: vendor the code, pin the version, add contract tests, and keep transport concerns (auth, rate limiting, cache headers, pagination policy) in our layer. If we don't adopt it, copy the layering and skip the dependency.

What would change the recommendation: a clear OSI-approved license, upstream tests and CI, evidence of external dependents, and a documented maintenance commitment. Absent those, the package is a design reference, not a component.