Laminas Translator Laravel Package

Product Decisions This Supports

• Build-vs-buy for i18n: This package is a contract-only artifact — it ships nothing but TranslatorInterface (plus a DEFAULT_TEXT_DOMAIN constant and native parameter/return types as of 2.0.0). It informs the decision whether to standardize on a shared translation contract versus adopting a full translator implementation. It does not itself deliver pluralization, adapters, or caching — those live in laminas-i18n and sibling packages.
• Decoupling strategy in polyglot/mixed PHP stacks: If the product ships multiple PHP services or components (Laminas MVC, Mezzio, or legacy Laminas code) that all need to type-hint on a translator without dragging in the full laminas-i18n dependency tree, this abstract interface is the intended decoupling lever. That is the only real product value it offers.
• Informs Laravel-specific decisions: For a Laravel-first product, this package does not change any i18n roadmap decision. Laravel’s trans(), Translator binding, and TranslatorInterface are already in place; adding laminas/laminas-translator would introduce a parallel translator contract with no Laravel-native service provider, facade, or bridge. The decision this package supports in a Laravel context is usually “do not adopt.”
• Where it could earn a slot on a roadmap:
  • A Laravel app that also vendors Laminas components (e.g., an acquired codebase or a shared package). Here the contract keeps that package from forcing a full Laminas dependency on the Laravel side.
  • A monorepo of PHP packages where you want a framework-agnostic translator interface shared between Laminas and non-Laminas consumers.
• Use cases it explicitly does not support: end-user multilingual rollout, locale switching, pluralization, message catalogs (CSV/XLIFF/Gettext), caching — all out of scope. Roadmap items requiring those must be satisfied by an actual translator implementation.

When to Consider This Package

Consider adopting when:

• The consuming codebase is Laminas/Mezzio-based and you want type-hintable translator contracts without full laminas-i18n coupling.
• You maintain a shared PHP library that needs to type-hint on a translator but must not pull in any specific implementation (this is the documented purpose).
• You are on modern PHP (8.2+) — 2.0.0 adds native parameter/return types and drops 8.1; 1.2.0 targeted PHP up to 8.5.
• You need a narrow, stable contract as a seam between first-party code and whichever translator you actually deploy.

Look elsewhere when (the common case):

• Laravel-first project — use Laravel’s built-in translator; wiring this package in would mean a custom service provider plus an adapter layer that duplicates native functionality.
• Symfony project — use symfony/translation; no official bridge exists.
• You are actually shipping i18n features — you need laminas-i18n (implementations, adapters) or mezzio-translator, not just this interface.
• You need confidence in vendor viability — this is a 3-star, 0-dependent, 2-contributor (1 bot) micro-package with no production-scale evidence. It is low-risk technically (so small it can be forked or replaced), but it is not a place to anchor an i18n strategy.
• You cannot absorb the 2.0.0 breaking change (typed interface) in a codebase that previously called translators dynamically.

How to Pitch It (Stakeholders)

Executives: “This package is a tiny interface extraction, not a translation product. It exists so PHP components can depend on a translator contract without depending on any specific translator engine. It supports architectural decoupling and long-term maintainability for our Laminas-based services — it does not deliver any user-visible i18n capability on its own, and it is not a Laravel solution. Our recommendation is to adopt it only where a shared, framework-agnostic translator contract already makes sense, and to keep the actual translation engine choice (Laravel’s built-in, laminas-i18n, or Symfony’s) as the real i18n investment. Cost is effectively zero and reversibility is high because the package is small enough to fork or replace.”

Engineering: “laminas/laminas-translator gives us TranslatorInterface (with native parameter/return types as of 2.0.0) and a DEFAULT_TEXT_DOMAIN constant — nothing else. It’s the Laminas team’s move to let packages type-hint on a translator without requiring laminas-i18n. In a Laravel app, we should not adopt this: it duplicates Laravel’s translator contract and would require a custom service provider and adapter just to reach parity with trans(). It’s a reasonable dependency only inside Laminas-aligned code or in a shared library that must stay implementation-agnostic. Risks to flag: 3 stars, 0 dependents, single-maintainer-plus-bot activity, no security review, and a 2.0.0 breaking change in the interface signatures. Mitigation is straightforward — the surface is so small we can vendor or reimplement the interface if the package is abandoned. Treat it as a contract seam, not a strategy.”