Intl Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Whether multi-locale support ships in the next release or gets deferred. An i18n layer turns "can we localize?" from an open engineering question into a scoped, costable workstream — the input a PM needs to sequence market entry (e.g., UK/DE/FR expansion) against competing roadmap items.
• Build vs. buy vs. reuse for internationalization. i18n is "boring but deep": pluralization rules, locale negotiation, date/number/currency formatting, RTL. This package is one candidate answer; the decision it informs is whether the team writes its own formatting layer, adopts an established incumbent (symfony/translation, symfony/intl, Laravel's Lang/Number/Carbon stack, native ext-intl), or leans on a framework-sibling component.
• Stack standardization. If Tempest is under evaluation as a PHP framework, the component ecosystem is part of that evaluation. A read-only Composer split signals a modular, incrementally adoptable architecture — relevant if "can we adopt pieces without a full migration?" is on the table.
• Dependency and supply-chain governance. With zero dependents, this is a decision about acceptable risk in the dependency graph, not about feature fit. It informs the dependency-approval policy for early-stage, pre-1.0 packages.
• Content and translation operations. Choosing an i18n layer constrains how translators, TMS platforms, and content authors interact with the product — a workflow and ops decision as much as an engineering one.
• Feature scoping for international UX. Whether locale-aware formatting (currency, dates, plural forms) is a v1 requirement or a v2 nice-to-have — often the difference between "usable in Germany" and "technically translated."

When to Consider This Package

Consider it when all of the following hold:

• The team is already on, or actively prototyping with, the Tempest framework. This is a read-only subtree split of the parent monorepo's intl component — it exists for Composer distribution, not as an independent product. Its value is entirely derived from the parent framework.
• You want incremental adoption — pulling in i18n without committing to a full framework migration.
• The MIT license and small surface area fit your dependency policy, and you are comfortable that issues, docs, and releases route to the monorepo, not this repo.

Look elsewhere when:

• You are on Laravel or Symfony. Laravel already ships a coherent i18n stack (Lang, __()/@lang, Pluralizer, Number, Carbon, and ext-intl beneath), all wired into the container, validation, mail, and Blade. A Tempest component sits outside that pipeline, cannot inherit it transparently, and would require a custom service provider plus hand-bound value objects. For a Laravel codebase the integration friction buys you no benefit over symfony/intl or native intl.
• You need production-grade guarantees. Zero stars and zero dependents are not a quality verdict — a read-only mirror never accumulates stars — but they do mean zero ecosystem validation, zero third-party battle-testing, and no community support channel. You would be among the first adopters.
• You need to fork or patch independently. Read-only means contributions must go upstream; an emergency fix becomes a privately maintained fork — a permanent tax.
• Your i18n needs are deep (complex plural/gender rules, translation memory integration, RTL layout, locale-aware sorting). Verify coverage explicitly rather than assuming parity with established libraries.

Bottom line: treat this as a watch, not an adopt, unless Tempest is already in the stack — in which case it is the natural default.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated tempest/intl, a small MIT-licensed internationalization component distributed as a read-only split of the Tempest PHP framework's monorepo. It is a technical enabler for multi-language and locale-aware formatting — currency, dates, pluralization — a prerequisite for the market-expansion work on our roadmap. It is not a strategic bet or a vendor relationship: it is a low-cost, low-commitment building block with no adoption outside its parent framework and no commercial backing. My recommendation is to keep it on the radar and revisit only if we pursue the Tempest evaluation; it should not, on its own, influence roadmap timing. Localization can proceed on the established Laravel/Symfony path without it.

For engineering: Single-purpose, Composer-installable, MIT-licensed i18n component — a thin, ergonomic wrapper over PHP's intl extension. Versioned in lockstep with the Tempest monorepo; this repo is a distribution mirror, so file issues and read docs upstream, and expect split lag between an upstream fix and its appearance here. Zero dependents means no community validation — budget for reading the source and writing our own tests around locale negotiation and formatting edge cases. If we are not on Tempest, the switching cost of adopting a foreign-framework component likely exceeds the cost of using symfony/intl or calling ext-intl/Laravel's Number directly. On a Laravel codebase specifically, the realistic fit is narrow: use it at most as a typed value-object layer for currency/number/locale formatting inside a bounded module, behind our own CurrencyFormatter/LocaleResolver interfaces, never as the translation layer — the blast radius across validation, mail, and Blade is disproportionate to any gain.

Ask: No decision required today. Confirm whether Tempest is a live candidate for Q3/Q4 stack work. If yes, I will scope a one-sprint spike covering locale coverage, formatting correctness versus native intl, and LOC saved; the default is the incumbent unless the spike shows a material, measurable advantage. If no, we close this and proceed with the established Laravel/Symfony i18n path for the localization initiative.