Twig I18N Extension Laravel Package

Product Decisions This Supports

• Localization expansion (new locales/markets): if any part of the product renders through Twig (TwigBridge in Laravel, October/Winter CMS, or a standalone Twig-rendered marketing/CMS surface), this package is a candidate for wiring translations directly into templates so copy changes ship without touching controllers or PHP.
• Build vs. buy for a narrow capability: the decision here is not "adopt a framework" but "write ~100 lines of Twig glue ourselves, or take an MIT-licensed dependency." Useful as the low-effort option in that comparison, especially for a spike or MVP.
• Content-authoring workflow: decides whether translators/marketers can use trans-style filters in templates versus hardcoded strings — a meaningful input to how fast you can ship locale variants.
• Vendor and dependency-governance decisions: with 1 star, 0 dependents, and a near-zero score, this is a data point for your dependency-risk policy — specifically whether single-maintainer, low-visibility packages are acceptable as leaf dependencies in production.
• Roadmap scoping: it should sit in the "i18n enablement" workstream as a tactic, not as a platform bet. It does not justify roadmap sequencing on its own; the real roadmap item is locale coverage, translation pipeline, and fallback behavior.
• Not supported: pricing, checkout, or any decision requiring vendor SLAs, security attestations, or long-term support commitments.

When to Consider This Package

Consider it when:

• You already render with Twig in a PHP/Laravel stack and want translation tags/filters available inside .twig templates.
• Your i18n needs are simple: key lookup and interpolation, no ICU MessageFormat, no pluralization rules, no locale-aware date/number formatting.
• You are comfortable vendoring or forking a small MIT package and pinning it, rather than relying on upstream releases.
• It is a leaf dependency whose failure mode is "templates show raw keys," not "checkout breaks."
• You want to prototype a template-level localization flow cheaply before committing to a fuller stack.

Look elsewhere when:

• You are on standard Laravel/Blade — use the native __() / @lang helpers; adding Twig solely for this is unjustified.
• You are on Symfony or already use symfony/twig-bridge — the built-in trans filter and {% trans %} tag cover this with maintained backing.
• You are on October/Winter CMS — the built-in {{ 'key'|_ }} filter already exists.
• You need ICU message format, plural/gender selection, or locale-aware number and date formatting — pair symfony/translation with the ICU message formatter instead.
• Your governance requires active maintenance, CVE response, or a support contact. One star and zero dependents are strong signals that no one is watching this repo.
• Your templates are user-editable or sandboxed — audit the extension's surface before exposing it.

Caveat: this assessment is based on package metadata only. Before adoption, read the source, confirm the filter/tag API, check the last commit date, and confirm compatibility with your Twig version.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed template helper that lets translated strings live inside Twig templates. It is not a platform or vendor decision — the cost of adopting it is near zero and the cost of replacing it is near zero. The real decision it supports is how quickly we can ship a new locale, and it removes a small amount of engineering friction toward that. Recommendation: allow it as a scoped, pinned dependency in the localization workstream, with a one-day budgeted fallback to an in-house equivalent. Do not list it as a strategic dependency.

For engineering: Single-purpose Twig extension adding i18n filters/functions to templates. Treat it as untrusted-for-longevity: pin the version, vendor it or be prepared to fork, and wrap access behind our own extension so a swap is a one-file change. Write tests asserting fallback behavior for missing keys before wiring real copy through it. Note the maintenance risk explicitly — 1 star, 0 dependents, low activity — and confirm Twig version compatibility. If we are on Blade, this is moot; if we are on Symfony's Twig bridge, we almost certainly already have this capability.

Bottom line: viable as a tactical, low-blast-radius dependency; not viable as a foundation. Decide on the localization capability, then let this package be one implementation detail of it.