Concrete5 Translation Library Laravel Package

Product Decisions This Supports

• Build vs. buy for the localization layer. This library is a small, dependency-light PHP translation primitive rather than a full i18n platform. It supports the decision to not build a translation store/loader from scratch, and to not buy a heavyweight TMS, when the product only needs message lookup with swappable translation sources (files, DB, etc.).
• Runtime baseline / platform modernization. The 1.11.0 release raises the minimum PHP from 5.3 to 7.2. This is a direct input to your minimum-supported-PHP policy and to any legacy-environment support commitments (hosting requirements, customer upgrade notices, LTS promises). If your roadmap already targets PHP 7.2+ (or 8.x), this release is a green light; if you still ship on 5.x/7.0/7.1, this release is the forcing function to schedule that migration.
• Template-engine compatibility in the roadmap. Optional Twig support widens the addressable integration surface: Twig-based stacks (Symfony-flavored apps, many CMS themes) can now use the same translation source without a bespoke bridge. That informs roadmap items like "support customer-preferred templating" and reduces the cost of multi-stack or white-label deployments.
• CMS/legacy-ecosystem feature bets. The package's concrete5 lineage signals a fit for CMS-adjacent products with theme/plugin translation needs. Useful when scoping features like theme-level string overrides, per-site locales, or admin-editable translations.
• Risk and maintenance posture. A release that drops PHP 5.3 support and adds a contributor-driven Twig integration is a signal about upstream's direction (modernization, incremental integrations) — relevant to vendor/supply-chain review and to whether you pin, fork, or wrap.

When to Consider This Package

Consider adoption when:

• You need basic message translation (key → localized string) in a PHP codebase and want a thin library rather than a framework-coupled solution.
• Your runtime floor is PHP 7.2 or higher and you have a credible path off 5.x–7.1. Pre-1.11.0 versions are the only option for older runtimes, and pinning them means accepting an unsupported baseline.
• You need multiple translation sources (flat files, database, custom loaders) behind one interface, or you expect to swap sources later.
• You are in or adjacent to the concrete5 ecosystem, or need Twig-based templates to consume the same translation catalog as your PHP views.
• You want an escape hatch: a small surface area you can wrap behind your own Translator abstraction so a future move to Symfony Translation, Laravel's localizer, or gettext is a swap, not a rewrite.

Look elsewhere when:

• You need a full localization platform: pluralization rules across many locales, ICU MessageFormat, contextual/gender variants, translation memory, translator workflows, or TMS integrations. This library is not that.
• You are on Laravel specifically and want framework-native integration — Laravel's own translation component (and lang files, @lang, pluralization helpers) already covers this, and adding a second translation system creates two sources of truth. Treat this package as a replacement for the framework layer only if you have a concrete reason to bypass it.
• You require enterprise support, SLAs, or a guaranteed release cadence. This is community-maintained; plan for a fork-and-own contingency.
• You need PHP 8.x-only features or strict typed APIs — check compatibility rather than assuming modernization goes beyond the stated 7.2 floor.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost open-source PHP component for translating user-facing text. The new release modernizes its baseline — it now requires PHP 7.2 instead of 5.3, which matches where most of our estate already sits — and adds optional support for Twig templates, so it works with more of the templating setups our customers and partners use. It reduces the amount of translation plumbing we'd otherwise build ourselves, and its limited scope keeps switching costs low. The main caveat is that it's community-maintained and not a full localization platform: no translator workflows, no advanced locale rules. Recommendation: adopt as an internal utility where we need simple message lookup, wrap it behind our own interface, and treat the PHP 7.2 floor as confirmation of — or a prompt for — our runtime baseline decision.

For engineering: Minimal dependency footprint, straightforward API, swappable translation sources. 1.11.0 is effectively two changes: a breaking runtime requirement (PHP ≥ 7.2) and an additive, optional Twig integration. Nothing else in the public surface is signposted as changed, so the upgrade risk is concentrated entirely in the PHP version — verify CI matrices drop 5.x–7.1 before bumping, and confirm the Twig adapter is opt-in (no new hard dependency). We should consume it through a thin internal adapter so the choice stays reversible.