Gettext Bundle Laravel Package

Product Decisions This Supports

• Translation format strategy — the expensive, long-tailed one. Whether gettext .po/.mo becomes the canonical source of truth versus Laravel's lang/*.php + JSON keys (or Symfony's XLIFF/YAML). This decides what translators touch, what CI validates, what your TMS imports/exports, and what your keys look like in three years. It is cheap to reverse in a spike and expensive to reverse after a vendor contract and a 12-locale catalog are built on it.
• Build vs. buy vs. vendor. This package makes the third option concrete. Three paths: (a) a custom Laravel translation Loader wrapping gettext/gettext (~150–250 LOC, owned in-house), (b) a TMS that exports Laravel-native files, (c) this bundle. Note (c) is a Symfony bundle, not a Laravel package — no kernel/DI seam exists in Laravel, so the honest reading is "fork and own the code" or "use it as a reference implementation." That reframes the decision from procurement to a small, bounded engineering investment.
• International launch scoping for plural-heavy markets. gettext's ngettext plural rules and msgctxt disambiguation are materially better than Laravel's trans_choice pipe syntax for Polish, Russian, Czech, Arabic, and Welsh. If those locales are on the roadmap, a spike here is the cheapest way to prove or kill the requirement before committing sprint capacity.
• Agency / vendor handoff model. .po is the lingua franca of translation agencies and tools (Poedit, Crowdin, Weblate, memoQ). Adopting it lowers per-word cost, preserves translator comments and context, and gives you stable msgid keys that survive refactors — a procurement and vendor-management decision, not just a technical one.
• Legacy catalog reuse. If you already own .po files from an acquired product, a CMS, or a pre-Laravel app, this informs whether you re-key everything into Laravel arrays or reuse what exists.
• Runtime model gating. gettext is process-global (setlocale, putenv, textdomain). It is fine under PHP-FPM, but Laravel Octane / Swoole / RoadRunner would bleed locale across requests. If scale-out via Octane is on the roadmap, that is a decision that must be made now, not after adoption.
• Maintenance ownership. Zero dependents means no community backstop. Adopting forces an explicit answer to: who owns the fork, who reviews upstream PRs, and what the exit criteria are.

The scores are the story: opportunity 4.52 against a ~0.71 maturity score. That gap is the signal — genuine unmet need in the PHP ecosystem, served by an unmaintained artifact. Treat it as a design reference and a fast spike, not a dependency.

When to Consider This Package

Consider it (as a reference implementation or tightly-scoped trial) when:

• You have existing .po catalogs, an agency delivering .po, or Poedit in the translation loop — the format decision is effectively already made, and this tells you how thin the glue code is.
• You need real plural rules, msgctxt, or translator comments and Laravel's native formats (or Symfony's catalogue formats) are forcing awkward workarounds.
• You're running a time-boxed spike (1–2 days) to validate gettext before investing in a custom loader or a TMS contract.
• You're comfortable reading, vendoring, and pinning the source — that is a precondition, not a nice-to-have.
• The blast radius is small: one low-risk locale, behind a config toggle, reversible in a release cycle.
• Your runtime is PHP-FPM with request-scoped locale, not a long-running worker.

Look elsewhere when:

• You are on Laravel and want a production dependency. Laravel's Illuminate\Translation\Translator + FileLoader don't sit on symfony/translation, so there is no adapter seam — you'd end up discarding the bundle and using the underlying libraries directly. Default recommendation: don't install it; build a ~150–250 LOC custom Loader, or convert .po → lang/*.php in the build pipeline, keeping .po canonical.
• You need ICU MessageFormat (gender, nested select, number/date formatting). Laravel ships intl-backed helpers and Symfony has had native ICU since 4.2 — don't add a dependency to get less.
• You need runtime-editable translations (admin UI, DB-backed overrides, per-tenant customization). gettext is compile-and-deploy; you'd be fighting it.
• You need a maintenance SLA, security response, or bus factor >1. None of those exist here.
• Localization is a revenue-attached core differentiator — that justifies a TMS with a contract, not a 0-star bundle.
• You're on Octane / Swoole / RoadRunner, or the team would be surprised by the maintenance status after you ship it.

How to Pitch It (Stakeholders)

For executives (three sentences): This is a small, MIT-licensed Symfony bundle that lets an app use gettext — the industry-standard translation file format that agencies and translation tools already speak — instead of our current format. It is not a vendor we would rely on: no stars, no downstream users, effectively one maintainer, so the honest framing is "we'd copy roughly 200 lines into our codebase and own them," a bounded and reversible cost. Recommendation: a 1–2 day spike to validate gettext as our translation format, using this as the reference implementation — not a production dependency decision today.

For engineering: It is a thin shim — a Symfony DI extension, a gettext-backed translator, and console commands that compile .po to .mo (plus msgfmt) — sitting on PHP's native gettext/ngettext and symfony/translation. No runtime magic. For a Laravel target, we do not adopt it: no adapter seam exists. Instead we read it, then implement our own small Loader over gettext/gettext (or a build-time .po → lang/*.php converter), keep .po as the canonical artifact, and add msgfmt --check to CI so missing or empty catalogs fail the build instead of silently rendering English in production. Pin the commit, mirror it internally if we take any code, and write down why it's there and what would make us remove it.

The risk to state plainly, once: 0 stars, 0 dependents, one maintainer, and a maturity score of ~0.71 mean there is no community to catch a regression and no one to call. The high opportunity score (4.52) says the need is real; the low maturity says this artifact isn't the answer. Use it to learn fast and to size the build, then own the outcome — and put "translations showing English" in the runbook with its three usual causes: missing .mo, missing system locale, stale build artifact.